How To Communicate Hidden Gestures in Mobile Apps

09. January 2017 blog 0

Nick Babich wrote a nice article about different ways of teaching gestures to the users of your Apps. Communicating non-obvious usage of an application is always difficult and many times results in long, tutorial-style launchscreens in apps. Nick makes a good case for ditching these kinds of methods and instead educating your users on-the-fly with inline hints.

If you have to give your app an instruction manual, then you’re not doing a good job of communicating with your users because users cannot be expected to read a manual before using your app.

Read the full article here:

Tadaa! a design test library

07. January 2017 blog 0

“Tadaa” is a tiny library I built that allos you to quickly overlay a design over a UIViewController in an app. This allows you to check margins, colors and other UI aspects against the original design of the screen.

Check it out on my GitHub page

Simple animations with UIImageView

07. January 2017 blog 0

Our website has gotten a bit make-over the last few years. We started to focus more on the visual aspects of the site. One part of that is the use of illustrations. We wanted to give our new apps the same care and attention but sometimes it is not so easy to use branding or visuals on a relatively small screen. Nevertheless, we did some small things that make a big difference and might even make our users smile a bit. An example of this is the animation we added to indicate that you have reached the bottom of our result list.

For this animation we used a simple UIImageView with 4 separate image frames of a cyclist. The frames in this imageview are animated and the imageview itself is also animated from left to right. This results in a pretty decent animation that was made within an hour or so. Not a bad investment for a little fun!

Here’s the relevant code to animate the frames:

Download the complete Xcode playground here: AnimatedImageView.playground (42KB .zip file)

Low risk update tactics for Apps

05. January 2017 blog 0

Consider the following situation. You have had an App in the App Store for a few years and it is used by quite some people. At some point you decide to rebuild the app or refactor it in a significant way. You rebuild the app, test it thoroughly and release it to your (undoubtedly super-happy) userbase.


On the first day of your release, your enormous userbase finds a terrible bug. The backlash is terrible and any credit you had with your users goes out the window.

The first part of this story is where we found ourselves 2 years ago. We were not afraid to update our app in a significant way but we were aware of the dangers of rebuilding an entire app from scratch and putting it in the hands of hundreds of thousands of users from day 1. We decided to come up with a more low-risk tactic for the development and release of our apps. Here’s how we did it (until now):


While developing the app, we tried to get the app in the hands of as many people as possible, but only people we knew could handle an unstable and ever-changing product. This first alpha group consisted mostly of colleagues and family members. This was our first line of defence for any huge bugs we potentially introduced in our product. Our Apps were distributed via TestFlight and the Google Play store but were not publicly available. We tried to release as often as possible to keep our test users engaged and up-to-date on our progress.

Internal Beta

Next, we recruited a beta group of of about 200-300 real users who were excited to test our unfinished product and give feedback. This feedback was given through an in-app feedback form (powered by ZenDesk) as well as through several to-the-point questionnaires we sent via email. We added screens to our apps that made it clear which functionality should be considered “finished” and which functionality was not available yet. This was done to further manage the test user’s expectations.

External Beta

When we felt comfortable with the stability of our apps and the most basic functionality was implemented, we took the plunge and put our app in the App Store. However! We took a slightly different route than companies normally take. We decided to put our new fancy App in the store as a second app. The original app, with a lot of users, remained in the store. Our intent was to let the userbase of our new app gradually migrate to this new app and not “scare” them with an app that was not only radically different, but also not feature-complete yet. We originally called this app “<appname> beta” but when we tried to update this app (not on the original submit unfortunately 😉 we were notified by Apple that this naming was not allowed. We opted to go for “<appname> vernieuwt (renewed)”. We made sure to properly communicate in the App Store as well as in the App itself that this App was in a state of flux and that it could still contain some bugs. Also we encourage users to give us feedback or to report any problems in the app.


Migration our users in our “old” apps to the new apps was not going to be easy. Even though the original “organic” traffic to the new app was pretty steady we still wanted to encourage existing users to use our new product. We did (and still do) this by showing banners in our old apps. Because we know exactly which functionality people use in our apps through analytics we are able to target these banners only to people who do not use any functionality that is not available in the new app yet. As we add features to the new app and the two apps are more in-sync, we can target more and more users via these banners.

This is where we are now.


Since we already have our new app in the store and more and more people are using it. The actual action of “releasing” changes slightly. Instead we focus on migration of users to the new app until we reach a point where we can safely “turn off” our old app and remove it from the store.


Sure, it’s nice to push a big red button and launch a new version of your app. But considering the risks of updating an app with a huge userbase, isn’t it also nice to slowly introduce these people to your new product and not scare them off?

Currently we cannot determine yet if this tactic will pay off and if it does result in a more stable, robust and user-friendly app. I will keep you updated on our progress. In the mean time, why not consider your own low-risk release tactics?

Non-nested appending of optionals to an Array

05. January 2017 blog 0

I like to prevent nested code as much as possible. In some cases though, it might not be very easy to do this. Consider the following code that adds a String to an Array:

this simple unwrapping of an optional seems trivial but wouldn’t a non-nested version look even nicer? That’s why I wrote a tiny Array extension that allow you to write it like this:

This moves the unwrapping of the optional to the append function itself. I also added a function that takes a second optional array as a parameter and a function that takes a condition which must be fulfilled before the element is added to the Array.

Here is the full code of this extension: