iOS 7: tale of two developments
Turns out developing for iOS 7 takes on a rather different feel, depending on your app’s legacy. It goes something like this. If you’re building a brand new iOS 7-only app, then it’s absolute dream to develop. Super simple. However, if you’re adding iOS 7 support to an existing app, then you’ve got some work ahead; not all of it fun.
New app, iOS 7-Only. For those apps which will come into being explicitly for iOS 7, the development cycle has never been smoother. For your shiny new version 1, you no longer feel compelled to add custom drop shadows, custom buttons, and fancy table styles to set your app apart. Why? Because the users of iOS 7 (most of them) are going to enjoy your app even if it’s composed of simple, clean looking, iOS 7 controls. Furthermore, fancy adornments, like drop shadows, feel decidedly out of place in iOS 7. Instead, you’ll be building clean, light, user interfaces where default styles feel new again. You’ll be building UI at light speed. It’s truly fun. Bask in the glory of spending 100% of your time delivering real value to your customers instead of toiling in custom UI so your app feels differentiated. Ok, some of these comments are a little over the top, but the point is that building for iOS 7-exclusively is a pleasure that was long since lost in the world where every app was trying to outdo its predecessor in ‘drop-shadow-green-felt’ realism.
Existing App, iOS 6 & 7 Support. So you launched your app before iOS 7 came on the scene and now you’re stuck supporting at least two OS versions (until enough people upgrade to iOS 7, of course). As in all cases, legacy support of an older OS saddles development effort. Despite best efforts and smart refactoring, you’ll surely end up with code that handles each OS on a case by case basis. In the best possible scenario, you’ll be supporting iOS 6 and 7. However, even in this best case, the OS differences will definitely eat into the fun you could be having with a brand new app that’s iOS 7-only. You’ll probably find yourself loving Apple’s handy little guide to iOS 7 Transition. In this guide, Apple makes some important points:
First, focus on redesigning the app for iOS 7
Worry about supporting older iOS versions as a secondary task. First, think about the changes your users should see when they upgrade your app on their newly updated iOS 7 device. Focus on adopting the new style, and making your app feel at home in iOS 7.
If your app uses Auto Layout, your job is easier
Might be a little too late for this piece of advice, however the writing has been on the wall for a while. Auto Layout is the future. At every opportunity, Apple has been strongly hinting that the new world, is one designed with auto-layout. A magical world in which your app looks incredible, regardless of screen size.
If you didn’t use Auto Layout, now may be the perfect time to start
And there we are. Yet another strongly worded hint.
don’t restyle the iOS 6 version of the app to use iOS 7 design elements, such as translucent bars or borderless bar buttons
This is a great point. Unless necessary because the change impacts the navigational structure on an older iOS version, avoid trying to back port iOS 7 design feature to previous versions. The idea here is that you want to minimize the development effort for the older OS, as it seems pretty clear that users are quick to adopt iOS 7. Just weeks after launch, 80% of our app’s users are now on iOS 7. Incredible uptake.
We spent some quality time with the Apple Transition guide and found that it helped a lot as we moved through our own app transition. Beyond the guide, there were also things that we discovered as we dug through our own code - a legacy of OS versions left behind.
Lessons Learned.
The big learning from the iOS 7 transition exercise is that we had too much user interface customization in our app. Although it looked great, it really took more time than it was worth to initially create the custom look and was certainly slowing our velocity greatly during the transition. Granted, an OS transition at this scale isn’t likely to happen again for a while (5 years?), but it still showed us the pain of heavy UI customization. The question is, does the user care enough about a ‘drop shadow’, or custom button style, to pay the cost. The cost being that instead of the drop shadow, we could have delivered a new feature. It’s all about priorities, and my priorities are shifting from UI adornment further toward real user value.
Custom Controls.
First, ask yourself if the custom UIBarButton or UINavigationBar is really worth it to your customers. If not, just don’t build it. If it is, then I implore you to avoid any customization which has you looping through the subViews of an iOS standard control and overriding the intended design (as an example). Not that we ever did such a thing.
Custom Table Views.
Again, why? Basic customizations like line separator colors and background colors offer a lot flexibility in design without having to dive deeper into the customization of a UITableView. Not that any one custom effort takes that long, but if you have 5-10 different table styles in your application you’ll be sure to pay a velocity price when you want to apply a new design to the app. Keep things simple; move fast.
Decentralized Style.
Even though we had central management for the app’s design (colors, fonts, etc.) we still could have done better - a single file where all styles can be set. Couple this with push back on the amount of customization and you’ll end up with an app that’s super simple to change.
Lacking Auto-Layout.
Much of our app was without auto-layout love because we dropped iOS 5 support a only few months back. That said, we now know the cost of being stuck in a springs and struts world… it’s not a lot of fun. We’ll be working hard to move auto-layout throughout our app. We’ll be ready when our app is running on a 27" monitor via Apple TV. Auto-layout makes transitions like this much simpler.
Our iOS 7 transition retrospective has been valuable to us. We now see more clearly that our focus should be on user value, first, and design niceties, second - previously, it was a blend. Of course, having an attractive app has real user value, but it’s always possible to go too far. We’re hoping that next time iOS gets an upgrade like it did in iOS 7, our experience will be smooth and we’ll feel less pain from legacy design choices.
Thanks for reading. Hope this helps.
Andrew