Units convert is one of those apps I thought I could write in few weeks, publish it and all would be fine. As is usual in real world, it took two major versions and over 4 months of work to make it as good as I expected it to be after those few weeks.

I spent some evenings in past few weeks to write a very extensive article about the design process for version 2. I went back through the source code and recorded lots of movies (25 or so) of the app in various stages of development. I explain the issues, options I considered and the reasons behind every decision.

Read the article: Design process of Units convert 2

I always learn a lot from articles like this and I hope this will be useful to many of you as well.

I consider pre-iOS 7 keyboard design to be the best looking and affordably designed on-screen keyboard ever. The colors (subtle gradients) and animations when a key is activated were just perfect. When iOS 7 came, I was pretty annoyed how much uglier it looked like and consequently how it “felt” during use.

Which is why I casually followed the hubbub over the many changes during the 7.1 beta and the final result we were all given. Lots of people discussed it, mostly lamenting the result but I didn’t find any actual proposal for the better apart from Stefan Laketa’s colored button approach. Granted, I did not look much as I already said, but if there was something it would’ve blip on my twitter timeline (I follow over a hundred iOS devs and designers).

Here’s my proposal for the visual change but also a discussion about a larger issue with the keyboard behavior I did not notice before.

I have no idea how many weeks I have wasted debugging issues that come down to this problem. I am pretty mad at myself for forgetting this, but oh boy, it’s not gonna happen anymore. Oh no.

Ok, so you have NSFetchedResultsController driving either a collection view or table view. And when customer is looking at those views, you want the changes to animate in/out, as Apple has ask us to do since the days when iOS was called iPhone OS. To do that, you need to implement the four horsemen of NSFetchedResultsControllerDelegate methods.

However - and this is the trick - you don’t need to do that when those views are not visible. You only need to call reloadData on end of changes. However, I guarantee you that 95% of iOS devs leave those four methods as they are. And experience hair-pulling mind-cracking EXC_BAD_ACCESS crashes all over the place, in darn background threads that cause postNotification:..:... and what not. And you have questions about this on StackOverflow being answered with

oh, just set self.fetchedResultsController.delegate to nil in viewWillDisappear and problem goes away. Re-set it on viewWillAppear

You don’t say! Well, it sure goes away, but you also lose all the changes and your views do not reflect the current state of data source. And then when you try to animate, more crashes ensue…

oh, that’s easy to fix. Just add [self.collectionView reloadData] in viewWillAppear…

AAARRGGHHH!

No. Do not do any of that crap.

My little experiment measuring the influence of downloads to the search ranking gave me an interesting look at current state of iPhone devices in the wild. While 60k is far cry from hundreds of millions of estimated target base, it offers good glimpse into what people that actively look for apps are using as devices.

It also exemplifies how important localization is, which I’ll address first.