As an iOS developer myself, up until the official launch I still had doubts about what it really means to transition from iOS 5/6 to the new iOS 7. This blog post is an attempt to consolidate the important changes that are relevant to non-developers, such as designers, business folks and anyone who wants to know the implications of the shift. At the very least, it will help you in estimating how much work will be required to support both new and legacy platforms.
Can you make an app that supports iOS 5, 6 and iOS 7?
Short answer: Yes, but you should really be focusing only on iOS 6 & 7.
The new Xcode 5 still supports iOS 5. It means the app will have native interface for iOS 7 and older interface for iOS 5 & 6. Realistically, only supporting iOS 6 & 7 is a better approach. Given the rapid adoption rate of iOS 7 as well as the fact that iOS 5 is now less than 5% of the market share, I think the new baseline for any new app should be iOS 6. This shift may require extra effort but will definitely pay off in the long run. Unlike the gradual shift from iOS 3 to 4 to 5 to 6, the new iOS 7 is radically different and the effort to support both flat and skeuomorphic designs may not be worthwhile.
Should I care about 64-bit apps?
Not for now, move along.
The launch images
Size change : The old launch images did not include the 20px for the status bar, compiling with Xcode 5 will now require you to include this extra spacing. The important thing to note here; Xcode 5 now explicitly requires you to specify different launch images for each iOS version, even if the images are the same.
Style change: Since the two platforms have completely different native interfaces, and with Apple recommending us to use ‘fake’ screenshots of our apps as the launch image, it will mean having two sets of launch images.
The example below illustrates both the size and style changes that are now needed:
The app icons
Similarly, the set of icons need to go through transformation in both size and style.
iOS 7 uses a different set of icon size *and* different kind of rounded corner on its icons. Not only are you expected to create all previous icons, you now need to create a separate set for iOS 7 as well. I recommend using Iconify app, which does an excellent job of spitting out all these files with the correct naming conventions as per Apple guidelines. As I write this, Iconify has yet to support iOS 7 but is expected to do so in the next 2 weeks according to its author.
In addition, since iOS 7 does away with skeuomorphic designs, your app icons might need a design refresh as well. The “glossy” effect on the icon is now deprecated; there isn’t any option to turn on/off this setting. You will need to have BOTH sets of icons in your project unless you decide to stick to a single icon design.
The status bar
In iOS 6 and below, the status bar is not part of the application. iOS 6 does have a bit of colouring for the status bar but the 20 x 320 space is typically considered to be unusable. This has changed in iOS 7; your app now gains this extra space and the ‘frame’ of your application starts at the 0px corner and not at 20px. If your earlier project did not use the practices recommended by Apple – which many iOS developers are guilty of – moving to iOS 7 means these developers will need to fix their basic layout code before seeing to other changes.
To belabour the point, the ratio of your app has now changed from 320 x 460 (iOS 6) to 320 x 480 (iOS 7). You will most likely need to support both versions and here’s where non-developers can share in the frustration with us developers. We expect this to be a major
The translucent navigation bar & tab bar
For the first time, the top navigation bar and the bottom tab bar are translucent by default. Instead of having the main content start below the top navigation bar and end just above the tab bar, the main content area now occupies the entire screen. The images below illustrate this difference:
A good deal of customisation will be required to make apps work with iOS 7 correctly; simply compiling the old code in Xcode 5 will not suffice. Also, because of the colour change (see above, from blue to translucent white) pushing down the content using small tweaks in the code won’t be a very good idea. Instead of seeing this as extra work, we think this represents a new canvas for designers to come up with ideas to enhance their apps’ user interface.
The alert box & option picker
This is where things get slightly annoying and truly weird. Regardless of whether your app is old (already on App Store) or new (compiled with Xcode 5), in iOS 7 the alert box (UIAlertView) and the option picker (UIActionSheet) are the same. Gone are the old bluish alert boxes, even if you’re retaining the old skeuomorphic interface for your app on iOS 6. As a designer, you may find this change to violate your design and will need to review the entire design to ensure consistency under iOS 7. In Apple we trust eh?
Dealing with custom UI
If your app has custom UI, you’re set for more pain and messy code. In one of my experimental apps prior to iOS 7, I managed to replicate the dial pad using custom background images, which has the potential to make things harder when adapting this app for compatibility under iOS 7. Here’s what I managed to do with about 20 lines of code change:
Click here to see the lines of code corresponding to the UI hack above.
Fortunately, my hack worked out decently for this app, thanks to the fact that flat design is not too difficult to produce using only solid colors and the right typography techniques. My only peeve with it – it does not quite match the real iOS 7 native dialer.
Here are 2 strategies you might want to consider if your pre-iOS 7 app has a lot of custom UI elements and you decide to support both iOS 6 and 7:
Standardise UI components: Instead of having too many custom design elements, you could rethink how your app works and use only native components on both iOS 6 and 7. The rationale behind this: iOS 7 native UI are decent enough and very soon your iOS 6 user base will shrink to become the minority; as long as your app works well on iOS 6, the design should not be the focus for this version. Check out these samples for a better idea of what I mean.
Custom flat UI components: You may need to maintain a consistent app experience regardless of iOS version and user base, in which case you could aim to make your UI component “flatter” and make sure to test it well with iOS 7. There will be lots of work-arounds in your code, similar to how it was done in my app illustrated above. Once the design has been sorted out, the project will need solid refactoring/restructuring to maintain robustness and code quality.
Transitioning to iOS 7 does not mean you need to lose compatibility with older versions – your app could run on iOS 5 & 6 & 7 with 2 distinct set of native interfaces. There are major changes to the visible layout such as the app icons, launch images, navigation bar, status bar. Your app’s main content area are now subjected to a new aspect ratio and you will need to review your design approach to ensure consistency across iOS versions. The effort to do this could vary depending on your user base across iOS platforms and which versions you care to support.
Apple is clearly discouraging developers away from the old design style and enforcing a quick transition to iOS 7’s flatter design style. For all the pain to adapt existing apps to the new design language, I think this is actually a blessing in disguise. The majority of top apps this past year saw this coming and have already hopped onto the flat design bandwagon. With the introduction of iOS 7 and its quick adoption rate, designing and developing apps to support iOS 6 and lower may soon be a thing of the past.
You may also be interested in:
Love Silicon Straits and want to know more about our company culture, working environment or job vacancies?
Find out more at careers.siliconstraits.vn.
Be Challenged. Be Inspired. Be Different.