I’ve always been interested in how codebases change over time: as teams grow, more code gets added, but it also makes the system more complex and more difficult for a new starter to understand. As engineers we strive to build our systems in a way that makes it easy to extend and add new features (without breaking existing functionality). In recent years, one of the ways to help teams move fast is to move people into “vertical”/feature teams and have them focus on specific domains of the business.

Dynamic cell heights in UITableView have put a big spanner in the works in terms of performance. You can’t simply return an arbitrary height under heightForRowAtIndexPath and assume everything will work. If you have text in your cell that could be 1 line or 10 lines, your cells need to have a dynamic height. There are a couple of ways to measure this height. I’ll get into that shortly. Measuring cell heights can also be a relatively slow process, so I’ll also go into optimisation techniques to achieve the all-important 60 frames-per-second that everyone strives for.

I released a small app called Intimacy a short time ago. It took me a whole 8 hours to complete, including design, development, and the submission process. Why? I haven’t released anything under my name for a long time. That’s not because I haven’t been building, but I have that problem of doing 80% of a project and then stopping. So instead, I decided to build something small - something that would take me a single day (just about) to complete.

Spotify is, without a doubt, my most used app. I listen to music constantly throughout the day - on my phone or the desktop application. Obviously my commute is strictly on the phone. I have had a premium subscription to Spotify for about 4 years, so I think Spotify in general is great (I wouldn’t be using it for so long otherwise!); however, as you are about to find out, I do have a few qualms with the iPhone app.

I use Evernote for almost all of my note taking - especially on desktop. I find the Mac app to be really great: it’s well designed, easy-to-use, and I’ve had few to no bugs with it. With that said, I find the iOS app to be lacking in a number of areas that the Mac app just happens to excel at. On the Mac app there is a sidebar with all of your shortcuts, and a vertical list for access to Notes, Notesbooks, Tags etc.

I use CityMapper at least twice a day, every weekday. Once in the morning to check my journey is all good and no delays. Second, in the evening, on the way home from work, to check there are no delays! It’s an invaluable tool, and while not perfect, every time I’ve e-mailed the developers with a suggestion they have been extremely polite and taken it on-board. CityMapper takes every bit of data they can get their hands on and then uses it to provide the user with information on how to get from A to B - whether it’s fastest to take a single tube, a bus and a tube, or simply just to walk.

I was recently thinking about the apps I use. I found it interesting to think that I have a go-to app for a particular interest, need, or desire. I don’t use two weather apps, or two note-taking apps. That’d be redundant; instead, I have one app that I like the most of the ones I have tried and stick with it. This probably sounds quite straightforward - and it really is - but it lead me to think about why I use these apps.

I made a post over a month ago about Diving Buddy going freemium - it took a long time, but Diving Buddy Lite is now officially released in the app store. I ended up releasing an entirely new app for the lite version - this is because it would’ve been difficult adding in the In-App Purchases to an app that has already been selling on the app store. This way, a user can either purchase the full version of Diving Buddy, or download the lite (free) version and unlock some of the calculators to get the same features - for the same price.

I really like how Apple have implemented parameter names in Swift. In Objective-C you’re very much tied in to type out every parameter as they’re part of the method identifier. Methods are very verbose, and I have actually come to like that (from a C# background, it took some time to get used to at first). In Swift, parameters have their internal name - i.e., what you call the parameter within the method itself.

Optionals are a concept that isn’t in Objective-C, which makes them instantly cool already (and that’s disregarding the usefulness of these, as I’ll go into shortly). What are optionals? An optional is a variable with a question-mark (?) on the end of it. It means that the variable has a value, and it’s X, or that there isn’t a value at all. If you’re from a C# background, you’ll know of the Nullable concept - I believe it’s pretty similar to that.