Contrary to popular belief, iOS app development is not a process whereby a great idea is distilled into a robust set of instructions followed by instant approval resulting in long-term acceptance. Actually, the first part is true. There are many useful and innovative iOS apps available for users to download and enjoy. The iOS apps with the longest shelf life, however, are the ones that evolve to remain compatible with the latest releases of hardware and software.

Fortunately, it is not necessary to alter, edit, recompile, and resubmit your iOS app every time a new iOS version is released. To date, there have been forty-nine iOS version releases spanning the original iOS 1.0 thru the most current iOS 6.1. Here is the breakdown:

  • iOS 1.0 – Introduced July 29, 2007 (9 subsequent releases in one year)
  • iOS 2.0 – Introduced July 11, 2008 (5 subsequent releases in six months)
  • iOS 3.0 – Introduced June 17, 2009 (7 subsequent releases in fourteen months)
  • iOS 4.0 – Introduced June 21, 2010 (18 subsequent releases in thirteen months)
  • iOS 5.0 – Introduced October 12, 2011 (3 subsequent releases in seven months)
  • iOS 6.0 – Introduced September 19, 2012 (1 subsequent release in two months)

Each major release seems to blaze a trail with new capabilities and features. Developers are tasked with the decision on whether or not to leverage these new features. At the same time, however, developers are faced with a decision on how to handle depreciated methods and parameters. There is no black and white answer to influence the decision. Apple’s recommendation (taken directly from the iPhone Development Documentation (PDF)) is “update as soon as you can, considering the iOS versions you want your app to run on.”

If developers were forced to eliminate depreciated code from their projects, there would be a constant pipeline of revised apps passing through the “app approval gauntlet.” Based on the number of iOS releases over the past five years, under the above scenario, an app would need to be updated and resubmitted every six weeks.

Apps are not rejected as often as before for including depreciated methods or parameters. Apple code reviewers seem to be more sensitive to the challenges associated with maintaining and updating apps at the rate of iOS version releases. The challenge of every developer is to find a balance between supporting older iOS versions and leveraging the capabilities of new iOS versions.

A good rule of thumb

The main objective of a developer should always be to guarantee compatibility with the latest device(s). At the same time, however, it is important to release a new version of an app for the purposes of (1) increasing security, (2) fixing major bugs, and (3) improving performance. The longer you wait to revise your code, the more cumbersome and time-consuming it becomes. With each new iOS version announcement, read the developer documentation – specifically, the list of depreciated methods and bug fixes – to determine if it affects your current release. The release notes for iOS 6.0 can be found here.

A list of new features and functions along with accompanying release notes and known issues can be overwhelming. Apple Xcode does a great job of flagging potential problems – such as depreciated methods. You should always plan a new release of your app under the following circumstances:

  • Each time a new iOS device is released.
  • Each time a major iOS version is released.
  • Each time a sub-version includes critical security patches.
  • Each time a sub-version includes a capability that would enhance your app.

This would reduce the average release cycle from 10 times to 2-4 times per year. If you are responsible for managing and updating multiple apps, the effort to keep up with the fast pace of technology is much more manageable.

When is a complete rewrite a better solution?

It is a pretty safe bet to assume that any iOS app developed for earlier iOS versions, and still in existence, has gone through at least one major rewrite. The introduction of storyboards, for example, was a good reason to rebuild an app from the bottom up. The introduction of the iPad created an opportunity for developers to create “universal” apps. A complete rewrite of an existing iPhone app was necessary to create an app that would run on both the iPhone and the iPad.

A complete rewrite is a judgment call. Sometimes a rewrite is necessary to take advantage of new development methodologies – as with the introduction of storyboards. In other cases, a rewrite is necessary to leverage a new user-interface design – such as the Master-Detail design. Regardless the reason, sometimes an app has been through so many revisions and updates, it is difficult to add new features and functions. The most important thing to remember is to not go too long between updates. Your app will constantly evolve.

Also read: