iOS Views are Dead. Long Live iOS Views.

Design Development iOS

In the beginning of iOS development things were easy when it came to size. There was only one iOS device screen size you had to account for, and for years it seemed that was the way it would stay. Now app creators have shed their screen size and orientation mentality to think deeper about how their custom view elements fit together on the screen.

Follow along as we tour the history of iOS apps through the perspective of size and nail down a new app design paradigm brought about by iOS 9 with Multitasking.

iPhone OS 2.0 to iPad

When Apple first allowed third party app developers in 2008, the layout options were quite limited. The iPhone app was 320 x 480 unless you wanted to get all crazy and build a landscape 480 x 320 app. Design was simple, you only needed one mockup for a screen. In those days, the screen was usually just a simple Table View Controller that could handle tapping, scrolling, and cell sizing in a beautiful and easy way. The programming was efficient: I need this view to start halfway across the screen, so I'll just set its x-axis value to 160 because Apple would never make another screen size! Seeing a piece of code like

myShinyView.frame = CGRectMake(0,0,320,50);

was terribly common because it was easy and people knew they could get away with it. There was no need for complex math or redrawing views based on differing boundaries because everything was static. Or worse, there was a need for complex math and it heavily relied on the assumption that the iPhone was always 320 pixels wide and 480 pixels tall.

The years went on and Apple would introduce a fancy new device much larger than 320 x 480 named the iPad. Secretly, us developers were freaking out, wondering what this new big screen meant for all our lines of

view.frame.width = 320;

How are we going to fill up all that space? How will we ever account for two different form factors!? Well, Apple gave us the tools we needed and we adapted quickly. We now had a compelling reason to use both orientations of a device. The iPad was huge (compared to what we were used to at the time) and filling that blank space with content became easy as we realized all the neat new things we could do with the real estate.

The new ideas came with more work, of course, but we were so excited to implement that it didn't matter. Design and development now took almost twice the time when working on both iPhone and iPad apps. You could take the lazy route and just scale up your iPhone views to iPad dimensions, but users didn't want that. Users wanted to explore the new dimensions and form factor as much as we did, so we went along happily for another year or two and fell into our old ways. Our simple frame setting code didn't change much but certainly grew in complexity:

UIDevice* currentDevice = [UIDevice currentDevice];
if (currentDevice.userInterfaceIdiom == UIUserInterfaceIdiomPad) {
 //It's an iPad
    if (currentDevice.orientation ==  UIDeviceOrientationPortrait || currentDevice.orientation ==  UIDeviceOrientationPortraitUpsideDown) {
        myShinyView.frame = CGRectMake(0,0,768, 1024);  
    } else {
        myShinyView.frame = CGRectMake(0,0,1024,768);
} else {
  //It's an iPhone!
    myShinyView.frame = CGRectMake(0,0,320,480);

Overwriting the View Controller method


became a necessary way to learn of orientation changes and alter the layout on the screen. At this point though everything was still pixel by pixel frame manipulation. We set every view to a specific location on the screen with specific coordinates. We had some control with springs and struts, allowing subviews to stay fixed or grow/shrink when parent frames were changed. But overall, it was a real pain to dynamically size more than a couple views on the screen.

Obviously, this was not a scalable approach to setting up your UIViews and designing your iOS apps. You could get smart with UIViewController subclasses for each device, custom loading of your .nib files, and other tricks, but even then implementation of multiple designs to run on multiple devices was painful. Designers had to spend time thinking about how each device would look on every screen in every orientation and create wireframes or design mockups for each of those cases. Meanwhile, developers struggled with implementing each design to display properly in each view size and orientation.

Auto Layout and iPhone 5

The game was changed again with the introduction of the iPhone 5 in 2012. Coming in at 320 x 568, it added yet another complete set of design and implementation screens to worry about. Apple was taking us way out of our comfort zone but again came to the rescue with Auto Layout. Many of us were skeptical and/or frustrated with it and remained in the world of springs and struts a little while longer.

Auto Layout allowed developers to keep up with the designers in implementation of all the various screen sizes. View elements didn't have to be stuck at certain coordinates or manually recalculated every time the content grew or shrank in size. It wasn't the coordinates of the UIView that were important anymore, it was the relation between views that drove the look. Auto Layout could do this work for us (as long as we learned to wield it responsibly). If we set up the constraints properly (no small task in some cases), Auto Layout could handle nearly any screen size and device orientation with very little manual labor on our part.

As the majority of developers adopted Auto Layout, Apple introduced another feature (rather quietly) with Size Classes. Size Classes let us change our design dynamically depending on a UIViewController's new feature called trait collections. These new traits tell us if a View Controller has access to a “regular” or “compact” dimension (height or width). By removing, creating, and tweaking constraints of views (or even the views themselves) for each Size Class, we can achieve the layout we want for those dimensions. Initially, we see another round of skepticism and questions such as “Well, what do I need this for?” ensue once again.

The Size Classes available on iOS 9 iPads.

What to Expect with Multitasking in iOS 9

After some much needed discussion (and Xcode/iOS updates) regarding the increased efficiency of Auto Layout, we learn to love it. We grow comfortable with constraints and developing UIViews that look perfect from the now repulsive-looking iPhone 4S screen size to the iPad Air 2. And with iOS 9 now right around the corner, another “Ah-Ha!” moment is to be had. Multitasking on the iPad.

Multitasking means iPad users will have the ability to swipe from the side of the screen to bring another app to the foreground, partially covering the previous app. The new app in the foreground will only have access to a fraction of the screen's width, and it still has to look great! Only the iPad Air 2 will also have the ability to “lock” that new app in place on the screen, allowing two different apps to run in the foreground simultaneously while sharing the screen real estate. The iPad Air 2 can only lock two apps on screen in just a few positions, but I have a hunch this will change with time. This would be devastating if your iPad apps still include the numbers “768”, “1024” or any hard-coded point value anywhere in your View Controllers. (I hope by now, you've learned.) But this is also a whole new dimension to explore the possibilities with your app.

With iPad Multitasking, developers and designers have to answer the tough question “How do I shrink all of this beautiful content built for the full iPad screen size to this tiny sliver of a view that Slide Over gives us on the right hand side?” We also come to find out that the crutches we used previously no longer work. We cannot rely on the device orientation nor its size to determine what size or constraint to use. The UIViewController orientation methods are deprecated, so what are we supposed to do now? Ahh, wait a minute, I see what you did there, Apple. Size Classes help us to overcome this very issue. For example, when using Slide Over on an iOS 9 iPad, the app on the right will be running in the foreground with a compact width and regular height regardless of whether the device is in portrait or landscape. This is a major change in how we've traditionally thought about design.

A New Way to Look at App Design

Multitasking expects your views to shrink and grow not just to static pixel values anymore, but a dynamic and shifting spectrum of sizes on the whim of the user. Hard coded sizes of views, images, and text have been a thing of the past for years now, but this should now make it abundantly clear that our design paradigm needs to change as well. We cannot design apps with just portrait and landscape in mind anymore. Portrait and landscape should be dropped from your vocabulary. Not to get all meta on you, but your app just needs to be, no matter how the user holds the device, no matter what device it's on, no matter what Size Class it's currently displayed in. It needs to flow effortlessly between every size transition you can think of, and then some.

You need to start prioritizing views instead of placing them, and fitting views together like puzzle pieces without any edge pieces. What views should remain even when only a small portion of the screen is dedicated to your app? What elements need to scroll? How will views change if the screen is pinched or stretched? If your current content can't be condensed any more, how can you redefine your layout to still look familiar and provide value with the smaller real estate?

Concluding Note

Moving forward in iOS design with Size Classes means dropping the screen size and orientation mentality and thinking deeper about how your custom view elements fit together on the screen to make your apps come alive. As history indicates, it's safe to expect app screen sizes to only get more dynamic and fluid as time passes. It's certainly going to be a challenge to redefine our perspective, coming from a single app with a fixed screen size to an app that users will expect to flow dynamically from a variety of sizes at their command. But with a little creativity, our apps will soon flawlessly handle shrinking to a third of their original sizes and our users will love it.. It will allow us to explore new uses and create brilliant apps in very untraditional ways.

Matthew Tea is an iOS developer with a passion for quality, tested code. He's a team player with a strong desire to learn new and upcoming technologies.

You made it this far so...