Aug 29 2013

How App Developers Should Prepare for iOS 7

You’ve heard the rumors. iOS 7 is coming.

The initial reactions to the bold new look from Apple were predictable. There were criticisms and, of coursedefenses. I chimed in with some positive thoughts during WWDC.

By now, though, nearly everyone has embraced the inevitable. And many developers have had hands-on time with iOS 7, so the initial reaction to mere screenshots has been tempered by actual use.

So, with release imminent, it’s time to offer some suggestions to app developers awaiting iOS 7. But first, a quick debate is in order:

Should i update my app for ios 7?

Point: Apple carefully sets the stage for what is coming next. They introduced auto-layout, then the larger screen. When they double down on a technology, you can bet there’s good reason to pay attention. What if you simply made sure your app isn’t broken on iOS 7? You could get away with it—for about a year. Come iOS 8 though, Apple is going to build on things they introduced this year, leaving you with two years’ of advances to catch up on. And if you don’t update, you might be ceding the market to your hungrier competitors.

Counterpoint: It is challenging to build a business solely on apps. Your business case might not support updating existing apps for Apple’s latest software, and starting a new app may offer more opportunity. Your competitors are weighing the same tradeoffs, and your customers mainly care about something that solves their problems. Customers might not care if you’re late to the party, as long as your software keeps doing what they need.

How do I prepare for ios 7?

If you decide against iOS 7 support, I suppose your work is done. But that’s boring, so let’s assume you decide to support Apple’s latest release. What should you do for existing apps?

  • Figure out where your app stands. If you haven’t identified what issues your app will have in the upcoming release, you are already way behind. Get a device with the beta version of iOS 7 and start using it daily so you can get a feel for the new platform and find out where your app doesn’t fit in. Here’s a hint: Look at the colors of both text and standard navigation controls. Check any popup dialogs or overlays. Look carefully at your table views, including around the edges.
  • Get your app compatible with Apple’s upcoming software. You can’t ship until Apple does, but you won’t have much time when they announce the release. You should be working on a compatible build shortly, if you aren’t doing so already. In fact, we’re doing this for our own products over the next two weeks. I have good news: Simple compatibility shouldn’t require too much work on your part.
  • Identify if there are any big wins for your app from the new APIs and features. What counts as a win for your app? It’s a bit hard to explain, but it could be something that would make a compelling use case. A beautiful, elegant, innovative solution to a real problem. Something novel but familiar. Something that Apple might want to feature, and that your customers might delight in.This is where you decide how much you really want to invest in iOS 7. (Sidenote: I can’t wait until we can tell you about some of the great new tools and APIs!)
  • Understand that there will be some glitches along the way. Example: I’m not convinced that removing all indication of tappable regions (i.e., button edges) is best for users, but it may just demand more of us as developers. We may need to spend less time getting assets from our designers, and more time working with our designers to make sure that every element responds as the user expects it to. We may need to get more comfortable with animations and 3D transformations. We may need to push past our comfort levels and explore brave new ideas.

So get ready. It’ll be fun.


  1. Alex the Ukrainian

    Nice post! I think bordered buttons will be back in style in no time. I don’t expect third-party devs to embrace all the changes to the degree that Apple has. Just like pretty much all third-party apps went flatter (and prettier) after the initial “whoaaa” wore off. Busy changing my app – it will be iOS 7-only! Lots of under-the-hood changes that break the little things…

    • Gregory Hill

      I think we’re going to see a balancing act for a short while. Some apps will migrate, and some will stay pre-iOS 7. Maintaining an app as both will be problematic, especially for the one-man or small shops. Once an app goes to iOS 7, it will very quickly become exclusively 7. So there will be a decided split between pre- and post-, while developers decide on the best course of action to take.

      But I’m willing to be that within 6 months (if not significantly sooner), none of the popular apps will be available for both, which may easily be too generous a timeframe. And if the LaF of 7 takes hold, then pre-7 apps will essentially disappear.

      Given the history of how quickly users upgrade iOS on their devices, this will not be a problem, though. And I think Apple is very much counting on that fact. They certainly pushed it during WWDC.

  2. Leo

    Yeah, I installed ios7 beta just today, looked at my app in simulator and was frustrated from what I saw. The UI is all broken and ugly…

    • Leo – check your build target (if you haven’t already). If you switch back to iOS 6 it might not be so bad. Also make sure you’re not running multiple versions of Xcode at the same time. That can cause problems too.

  3. David

    Dear Step,

    thank you for the interesting post. I was looking for info on this and could not find much.
    I would like to ask you your opinion. I am planning to start to work on new app in some weeks. The app is region specific. We think users will be not that fast to migrate to iOS7 in our region. Now, I am basically in the hurdle of deciding these two options:

    1) Write the app using Xcode 4.6 and 6.1 SDK and ensure it works also for iOS7. Then after some time (maybe couple of months) update the app for iOS7 also. After how long do you think it will be reasonable to think updating the app written in such a way also for iOS7??

    2) Wait for Xcode 5. Write an iOS7 app using 5 Xcode and make sure it is backward compatible (e.g., using code branching where needed etc.) such that users of iOS6 (maybe also iOS 5 can use it).

    Which approach do you think is preferable? Which is more easy to implement? Thank you in advance!!

    ps. I am big fan of BNR, finishing a book about iOS development from your authors.

    • Hi David,

      Thanks for using our book. I hope it’s helpful!

      It’s going to be more work writing an app to support iOS 6, then adding in iOS 7. If you’re only talking months before the users are on iOS 7, well, it may take you longer to ship the app than for them to upgrade. My initial reaction is, if you are starting a new app, it is best to go iOS 7 and (where necessary) make it backwards compatible. So option #2.

      That said, I don’t know your target market and audience. Will they update if your app requires it, to get your app? Do they care about UI or UX? How big of a market is it, and how much do you need to reach immediately?

      Take a look at Apple’s transition guide for more information.

      • David

        Dear Step,

        Indeed book is helpful.

        I thought in your post you said: “if one could make sure app is not broken on iOS7 then he/she could get away with it for an year”. You meant like one could not bother to update the iOS6 app to iOS7 right for an year right? This is basically my option #1 right?? (Yes, I plan to start a new app indeed).

        About #2 the only thing that worries me, I am not sure exactly how to do it, I mean I do know – not to use iOS7 specific methods and use code branching when needed, just I am not sure if it is more complicated than #1 option?? (I am not very experienced iOS dev yet and that’s why).

        I also looked at the transition doc, but didn’t notice much there, apart from it saying that I could preview my iOS7 app in XCode 5 how it would look on iOS6. Is there something I missed?

        • David, we can talk more after iOS 7 comes out, as we can be a little more specific. But starting a new app is much different than fixing an existing one. If you are starting a new app, and are not very experienced, I think you should use the latest API. Figure out iOS 7, don’t try to also figure out iOS 6, and also have to figure out how to handle both versions.

          • DAVID

            Step, so do you advise against option #1 is this is a new app?

            >>”Figure out iOS 7, don’t try to also figure out iOS 6, and also have to figure out how to handle both versions.”

            Well, I am already more or less familiar with iOS5 SDK since this is the book I used to learn: (6 should not be too different right?).

            Dear Step, about handling both versions, can you tell me which
            resources should I read in order to learn how to support both versions?

            I know I might need to use respondsToSelector, etc. What else must be done?

            I didn’t find transition doc very useful, I think it just said I could preview in Xcode 5 how my app looked in iOS6 – was there anything else I had to pay attention to?

            If I support backward compatibility like this, does it mean I have to read HIG (human interface guidelines) for bot iOS6 and iOS7? Thank you for your time.

    • Dan

      One thing that should be pointed out is that Apple began rejecting apps within 1 week of the release of iOS 6 if the app was not built with the iOS 6 SDK. Given the imminent release of iOS 7, everyone should be using Xcode 5 with the iOS 7 SDK to build there apps at this point. If you don’t, there is a good chance your app won’t be accepted by Apple if you submit after iOS 7 is released.

      • Thanks Dan. I’m hearing a lot of devs saying they’ve had apps in review for over 10 days now, so we probably are close to (or past) that point.

        The (now confirmed) event on Sept 10th should answer some of our questions!

Leave a Comment

Join the discussion. Do not worry, your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>