(with Pekka Pulli)
One of the first new things I saw on the Xcode 6 beta was the Resizable simulator. Obvious jokes about an upcoming stretchable iPhone aside, trying it out revealed a simulator where you can set the size of the screen and also set either horizontal or vertical dimension into Regular or Compact.
Of course I had to play around with the size settings, and noticed the app I was working on at the time promptly broke completely when the size changed… And the same thing seems to happen to other apps too, as exemplified by the Ruisrock app here. This is all related to the new way of adapting to different screen sizes on iOS 8.
Screen shot showing how an existing app's layout breaks when using the resizing features of the Resizable simulator
Interface orientation and interface idiom are replaced by traits, a collection of which contains the view’s size class in both dimensions, the interface idiom (which doesn’t go away, just moves to being attached to a view), and the display scale (2.0 for Retina displays).
Views keep having sizes, but there are also some new methods to notify of view size changes on a view controller. For designers, adaptive views signify a more complex world than the one we had. We used to be able to make a design for a constant 640 pixel width design for iPhone and another one for iPad, with some modifications to support landscape orientation. Now we have to support a range of screen sizes the way we would on Android apps or even responsive web sites.
The good news is, the regular and compact size classes provide a set of readily available breakpoints to guide the designs. Devices have default size classes they adhere to as seen in the graph. To adapt your design process to these changes, make sure you have a layout plan the relevant size classes to your app and prepare for stretching and shrinking the design as needed with fluid changes to layout, typography and image assets. As always with varying size platforms, stick close to the developers (easier if you are one) and design the fluid parts of the layout with them for the best result.
For developers, this change will definitely mean the end of any hard-coded dimensions in the app. View layout and dimensions need to be determined only by the area given to them by the system, not by any preconceived notions of screen size. Auto Layout will be useful here, but it is possible to compute all dimensions properly also in handwritten code.
What is then the point of all these changes? Apart from replacing
interfaceOrientation with a more general way of answering “Portrait or landscape?”, that is. Seems like Apple is trying to get app developers to unify the iPad and iPhone versions of their apps while still being able to take advantage of the bigger screen of the iPad. Apple itself is definitely moving in this direction, bringing classes like
UISplitViewController to the iPhone as well, with the traditional split view behavior on iPad and navigation to the detail view on the iPhone. App developers may also be expected to mimic this by making view controllers that adjust at run time based on the size class instead of implementing separate view controllers for iPhone and iPad.
Another obvious-seeming conclusion would be having multiple apps sharing the screen on iPad. Microsoft has it in Windows 8, Samsung has it in some devices, so why not the iPad as well? Looking at the new available methods, this could be a fully flexible size setting for each app, with a minimum required size and a threshold below which a dimension is considered Compact. Or the initial version could be limited to a set of predefined snapping points, with the APIs still designed to support the more general mode, so that there is no need to change them later, as Microsoft had to do with Windows 8.1.
Considering this addition, along with other changes that already came with iOS 7, I do recommend using Auto Layout for all your layout needs. The new functionality in iOS 8 knows how to handle layout when the size changes if Auto Layout constraints are in place, so no changes to the app should be needed. Mind, a properly-overridden
layoutSubviews can do the same thing, but that would appear to require more care in not making assumptions about screen sizes.
In summary, this new system is probably going to bring some headaches, as designers and developers need to adapt to a larger class of sizes and resizable apps. But I at least have a mostly positive feeling, as the new system also encourages using a more general layout code, with less hardcoding of specific dimensions. One concern I have comes from looking at the new
UISplitViewController header: A number of new properties and methods, all in service of adaptive layout. Does this mean the same increase in complexity for custom view controllers that need something different on a compact screen? Will it be worth it to write in the general way, or will it be better to just use separate classes for iPhone and iPad? Time will tell, I suppose, along with the actual devices that will need to be supported.
Futu Connect is our semi-regular roundup of all things Futurice. Be in the know about career-changing events, industry-leading content, non-profit passion projects, and an ever-changing job board.
Enter your email address below.