I’ve been developing iOS apps and games since 2009. It’s an excellent experience. My apps were featured several times by Apple (App of The Week, Apps for Travelers, etc.).

Creating apps is fun overall. Not every aspect of app development is that great. Sometimes you encounter shady bugs in the SDK itself, other times things that should “just” work simply do not  (like e.g. uploading your binary to iTunesConnect), etc.

This time I’d like to talk about the issues I encountered when updating my apps. Ok, so here we go.

  1. Enhancing the Data Model
    When you release the very first version of your app, it comes with a predefined data scheme. However, chances are you will have to make changes to this data model due to several reasons, like e.g. requests for enhancements, added functionality, etc.
    And every change or addition means potential trouble.

    Your app is already being actively used by happy Apple device owners, and the least you want is data loss. People can live with an app that is slow or crashes occasionally (it won’t get raving reviews, though); however, they won’t tolerate that well if their data collected over time vanishes suddenly.

    So you have to ensure that data is preserved across updates.
    Although there are proven techniques for database versioning and migration (see https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html), yet the task is not simple.
    You have to carefully take care of all the aspects of database migration. Say you’ve submitted three updates to your app, and every update also brought data model changes.

    That means that you have migrated data across versions:
    v1 -> v2
    v2 -> v3
    Since some users might be still stuck with v1, you also need this:
    v1 -> v3

    Now imagine an app which has say 10 or more updates. Things get complicated.

    Eventually, you’ll reach the level of complexity which makes you ask the question: should I maintain this app further? Releasing a completely new version may be a better idea; this way you throw away all the legacy issues and backward compatibility concerns. Besides, nobody expects us to maintain a $2.99 app for decades.

  2. Depending on 3rd party code/frameworks
    It’s tempting to use some open source frameworks instead of re-inventing the wheel and implementing your own solution. There are several useful, high-quality projects on Github that will do the job. Also, companies over ready made frameworks and libraries that you can easily integrate into your project.
    However, be careful. I burnt myself several times by relying on 3rd party solutions. Back in 2009 when I released my first iOS games, Apple did not offer any solution for social gaming – GameCenter first appeared in September 2010.

    Back then there was not even a standard way to for keeping players’ scores on the device itself. Developers either created their solutions or relied on third parties like OpenFeintPlus+AGON Online or Scoreloop.

    My choice was AGON, and it worked well: it offered everything I needed in my game. It was easy to set up, and it had a nice user interface. Besides, it was free. (I was wondering what’s the business model behind it – they had some plans, but they never made it, unfortunately.) I did not replace AGON with GameCenter once it became available. AGON was working fine, and the early versions of GameCenter were not that great, to say the least.

    But every good thing comes to an end: the guys at AGON announced that their service would be discontinued. I assume they run out of funds, or their business model did not work out as expected. Also, the appearance of GameCenter must have thrown
    So my players eventually ended up in losing all their online scores; hundreds of other games were also affected. Lesson learned: use official frameworks whenever possible.

  3. Evolution
    As technology evolves, updating your app becomes more and more tedious (especially if you insist on keeping your app’s compatibility with older iOS versions.) Which is btw not paying out: according to Apple, less than 2% of devices are using pre-iOS7 (see https://developer.apple.com/support/app-store/ ).

    Even a year ago, I was fully against putting together the user interface using interface builder. I truly believed that a UI that is defined in code is superior to one made with your mouse. And back then, this was probably true.
    Then came the iPhone 5 with its taller screen. My apps looked crappy on this shiny new device. By using some unorthodox tricks, I managed to resize my UIs to use the entire screen. But that wasn’t a future-proof solution.

    With iOS7 everything changed. An app that had UIs written and placed programmatically had issues when migrating to the completely revamped iOS version. Auto-layout, constraints, then later storyboards made it way simpler to build a UI. Not only was it quicker and less error-prone, but it also led to adaptive UIs.

I try to maintain my apps for about two-three years. When abrupt changes happen (in the SDK or UI paradigms – like e.g. the transition to the “flat” iOS7) that heavily affect their functionality, I carefully analyze whether the current version should be maintained further.
Three years means lots of changes nowadays. Creating a new, revamped version every 2-3 years seems to be the way to go.

Leave A Comment