One of the major staples of Android development’s always been the operating system’s ability to automatically scale apps up and down in order to accommodate whichever form factor they’re being used on.

Apple’s approach to form factor fragmentation has traditionally been the opposite one. As in, Apple requires app developers to target each screen size with a pixel-perfect user interface. Though iPads can pixel-double tiny iPhone apps, Apple wouldn’t degrade user experience by letting iOS stretch apps’ hard-coded interfaces.

It would appear that iOS 6 introduces a diametrically opposite approach, one letting developers construct interfaces that can intelligently adapt to different screen resolutions without looking plain fugly.

This is not just convenience, but a necessity given that rumored taller iPhone and an iPad mini, both allegedly due around September or October of this year…

As you can see in the above screenshot representing a bunch of new features provided by the iOS 6 software development kit (SDK), there’s something called Auto Layout.

Now, as other people pointed out before me, this isn’t terribly surprising.

When OS X Lion came out, Apple introduced a new way to build interfaces by specifying relative positioning of various interface elements.

This new Interface Builder feature became the default positioning method for new Cocoa projects in Xcode.

By all accounts, and this is only speculation, Auto Layout is coming to iOS 6 and it’ll make developers’ life a lot easier.

TechCrunch explains:

Auto Layout allows developers to create a set of constraints that define how UI elements are displayed on-screen. Instead of using the standard “springs and struts” positioning method, Auto Layout allows those elements to shift and move depending on a prioritized list of rules — think “the left side of one button should always be 30 away from the right side of another button.”

This approach takes best practices from both Google’s ‘OS-scales-things-up-and-down’ approach and current iOS scheme where universal binaries contain separate assets for different screen resolutions (legacy, Retina, iPhone, iPad), which includes bitmaps, interface elements and their absolute positioning in user interfaces.

While Google’s approach offloads much of the work on the developers’ side, end results are not aesthetically pleasing. Tim Cook noted as much during March’s iPad 3 introduction.


Apple’s boss illustrating how Android’s UI scaling produces less than stellar results

The executive ran a few slides comparing several Android and iOS apps side-to-side, making a point of how the official Twitter for Android client wastes screen real estate, leading to a sub-par experience.

Google hopes these woes will fix themselves over time as Ice Cream Sandwich-driven smartphones and tablets typically begin at 1280-by-800 pixel resolution, which kinda establishes the minimum requirements interface-wise.

Back to Apple and iOS 6.

I am convinced that Auto Layouts will solve the iOS form factor fragmentation in a typical Apple fashion: elegantly and with future compatibility in mind.

If Apple provides tools to facilitate the creation of layouts that intelligently auto-adapt to different screen sizes, then Cupertino will free programers once and for all of worry over how their apps will look on whatever future Apple hardware is looming on the horizon.

The benefits, clearly, are plentiful.

Plus, as additional iOS devices come into full view, the benefits will multiply (think a five-inch iOS gadget and a full-blown television set, to name a few).

This isn’t even debatable.

Simply put, it’s a necessity if Apple’s to prevent platform fragmentation on a form factor basis.

Surprisingly, a survey of a hundred WWDC attendees has revealed that programmers are not too concerned about the introduction of new screen sizes affecting the success or availability of the apps on iOS.

So instead of updating existing apps for the extra pixels on that taller iPhone, programmers using the new iOS 6 SDK tools would effectively spend a little bit more time upfront drawing their app’s interfaces via Auto Layout.

As a result, developers would rest assured knowing their software would look just as perfect on a smallish iPhone screen as it would on a bad ass Apple television set.

Am I stretching it here (pun intended)?

  • this would be relatively easy for apps like twitter, where the added screen space could be used to display more of the scrolling text and keep the UI elements at the top and bottom of the screen.

    • This is already how things are done in iOS apps.

  • selcukcura

    So, the auto layout is pretty much like fluid html layouts as opposed to fixed ones. Seems like a good move.

    • Not exactly.

    • Things like scroll views can actually size up while things like toolbars and buttons remain the same size. Apple encourages devs to make separate interfaces for iPad but it can be skipped at times. It only breaks down when developers set static images with fixed resolutions as backgrounds or images within a view object. Games usually have factors for upscaling character texture maps, which, if done correctly should permit larger or taller iOS form factors.

  • This is incredible! It just amazes me how technology has evolved so fast.

    • You’re kidding, right? Google already does this as part of their Fragment API, and Microsoft Windows Presentation Foundation was already capable of the same thing as early as several years ago.

      • You’re kidding, right? iOS was able to do the same roughly when the WPF was introduced and YEARS before Google came up with Framents. Google’s Fragments are fallend UIViewControllers and are built right into the core of iOS since version 1. AutoLayout is more than that – which is the new thing.

      • “When” WPF was introduced? Microsoft’s WPF was released as a major component of .Net 3 back in 2006 whereas the first iPhone was only unveiled in 2007.

        The claim that the first release of iOS then contained any support of not only multiple resolutions, but also adaptive layout, resize and reflow capabilities (that is prevalent in WPF) is also highly suspect; there was only 1 device with 1 resolution to actually code for.

        Not only that, if iOS had built-in support for the above from the beginning, iPhone apps would not have had the weird “stretched” look when used on an iPad. The fact was that the different aspect ratios between the iPhone/iPod Touch and iPad did not translate well if you did not code two distinct versions; Apple’s iOS graphics framework did not contain inherent resolution-adaptive support. Every project we did we had to provide separate assets and UI code for the early low-res iPhones, then the higher-res iPhone and later-gen iPod touches, and then again for the iPad. Apple is only releasing AutoLayouts now because people are realizing that iOS IS fragmented, and they need to start building proper support if they ever intend to introduce more devices with different resolutions and aspect ratios – likely in the upcoming iPhone 5 – or be prepared to lose cross-developers developers like us.

        (I’m not even going to start on how “the same OS” may “run on all devices”, but functions may work differently or nerfed completely when you have an older device, not to mention bugs and lags introduced to previously working devices on an older iOS version. Just go to the official Apple support forums to see for yourself.)

        On the other hand, (although not as robust as in later versions with the availability of Fragment in API 11), Android already had built-in support for multiple resolutions within a year of its release – simply because it was required. You could include multiple layout variants from the get-go, programatically and dynamically size views (what they call their controls/UI components) according to current display resolution and density settings. Since there is multiple resolution and layout support by default, an app developer can choose to use a single set of assets just layout and sized differently for different device, or simply provide different sets of assets that and use scaled layouts the same way as iOS does. Fragment support made it easier for developers to release a single app that caters to multiple devices with different specs – but the existing framework was already well capable of doing that, it just takes more work.

      • vik

        Hi… bro

        Can u please tell me how to implement Grid Layout using AutoLayout Feature in iOS6?

  • If only I could understand

    • javierE186

      I laughed so hard I spit out my Welch’s grape juice -_-

  • Remember this, iOS 6 runs on a Phone. And that phone just happens to be a book a music player a game console and pretty much anything you can think of.

    • maurid

      Yeah, umm, what does this all have to do with anything?

  • I appreciate that you specify that the hardware fragmentation issues on Android lie in the hands of the developers. In the iOS vs Android battles people always bring up device fragmentation and blame poor app adaptation on Google when in reality its the developer. In the instance of Twitter’s app, there are tools in place to make it easy for an Android developer to write 1 application that adjusts based on screen size, and orientation but the Twitter developers simply have not taken advantage of those tools. And that reflects poorly on the Android ecosystem even though it is completely out of their control.

    • vik

      Can u please tell me how to implement Grid Layout using AutoLayout Feature in iOS6?