April 28, 2015 // By Adam Stener
A few weeks ago at WWDC 2014, two of the many things that Apple announced were universal storyboards and the eventual elimination (“deprecation”) of the APIs used to detect device rotation. Now, this may seem very straightforward and a non-event, but we think it has much wider implications. (Magenic generally keeps speculation out of its blogs, but in this case there’s enough compelling evidence that we thought it interesting enough to distribute to an enterprise audience.)
What Apple didn’t introduce at WWDC was an iWatch or a new iPhone, although the leaked images and mockups are all over the Internet now.
In the newest beta version of XCode, Apple introduced universal Storyboards. In the past, storyboards were tied to either an iPhone-sized shape or an iPad-sized shape, and it was clunky (at best) to try to use them on the other device size, respectively. The new universal storyboards, however, allow developers to create a single UI that is size agnostic, and can be tailored to specific device size ranges through the introduction of size classes. We think this is a harbinger of new products to come, and its in every iOS development project’s best interest to think about repurposing your views to devices of every size.
Designing an enterprise app to handle device rotation has always been a bugaboo for project teams. If the UX designers and UI developers weren’t thinking about it early in the project, it became an albatross around their necks as soon as someone tried using the app on a landscape-oriented iPhone. Apple had already simplified the API once, but it still left the team with many decisions to make.
All of the screens and UI controls have to look good in portrait and landscape mode. Generally speaking, making this decision up front is much less work, as trying to adapt your application to support both orientations at a later point becomes a mess of subtle bugs. Apple tries to help you make this decision at the time of creating a project by giving you a prompt. Currently, this is a core concern, and requires planning and discussions very early on in the development lifecycle. But with the deprecation of the rotation APIs, Apple is now saying that there is a bigger problem we should focus on instead.
This is where the paradigm shift comes in. If we are no longer worried about device rotation, which was such a big discussion previously, why is this point of contention suddenly taking a back seat? What changes are coming that device orientation needs to be thought of in a different way and what should we be thinking about if not orientation?
In one of the WWDC presentations, it was suggested that developers think of rotation not as a consequence of physically rotating the device, but instead to think about what is really happening in the UI when someone does this. Yes, a device is rotated but, analyzing at larger scale, what really happens is that the display area changed size. What was once skinny from side to side and tall from top to bottom, is now the opposite.
But why is this important? Why should we focus now on size changes instead of orientation changes?
Clearly, one or two larger iPhone 6’s would be a good reason to have your storyboards react to size changes, but that would be only one benefactor of the whole story, which may include completely new devices and possibly a split-screen iPad workflow.
In addition to the iPhone 6, Apple could introduce two or more new lines of products, according to many rumors. These products may include something television related, and something wearable (an “iWatch”). If these devices or peripherals were to include their own completely separate SDK with their own API’s and be a separate target for developers, the adoption rate might not be as high as if they were more tightly integrated into developers’ current workflow.
If Apple were to introduce a wearable, say a watch, there is a good chance that the UI will not have but a single orientation. So determining what orientation the device is being held at might not be a factor. Or, it could also be possible that the watch face would continually rotate, so as to always have the correct orientation to the user in a round interface setting. In either case, a developer would not need to worry about rotation. I can’t imagine that most people would have large enough gorilla arms, capable of grabbing their enormous flat screen TV’s and flipping them to portrait mode either. So suddenly we’re faced with a different problem than yesterday. Now, the biggest issue we have is creating a UI that can be individually tailored to different sizes, yet universal enough to be produced within the same file. No longer are we worried about how you’re holding your phone, but instead what size device you are on. This is true not only of the different versions of the iPhone that are sure to come, but what scale device are you using in the range from tiny wearable, to humongous plasma on the wall.
Oh, and One More Thing. There has been speculation about a “split screen iPad” where, much like in Windows 8 and the Samsung flavor of Android, two apps could be displayed side-by-side on an iPad, running at the same time. Think about how your app would have to react if it were a full screen app and it were asked by the OS to shrink to half the screen. There’s no rotation, but it does need to resize. Likewise, if the OS asks your app to go from running in the background to showing up on half the screen, how would your UI have to change?
The iOS development world has changed. UX designers, iOS architects, and enterprise developers used to be able to relish in the simplicity of the iOS universe: a single iPhone every year in a single size meant that UI’s could be crafted to be pixel perfect. As new sizes of iPhones were introduced, and then the introduction of the iPad created a whole new category of size, Apple provided developers with tools to manage this complexity.
Well now it’s clear that with a deprecated device rotation API, universal storyboards, size classes, and auto layout, Apple is giving project teams all the tools they need to craft user experiences that adapt to different kinds of devices and different surroundings.
Gone are the days of thinking of apps as being a series of static, unchanging views of content. Instead, apps will need to be developed and designed in a more granular fashion, with reuse in mind. “How can this little bit of functionality be used on a watch or an a giant iPhone 6 or an iPad, or in a split-screen view?”
Apple has given us the tools, it’s up to us to create the great experiences.
To read about mobile application development from Magenic, check out our Mobile Strategy white paper. If you’d like to talk to us directly, email us or call us at 877-277-1044.