A few days ago we saw the launch of the new iPhone 6, 6+ and of course the reveal of the Apple Watch.

These are all very exciting, both to the consumer market and to the teams of designers, developers and agencies working on innovative and forward thinking tech.

As those of you in the industry can attest to, the past few months have been all about the rumours and chatter of possible device size options, resolution changes, varied screen ratios and so on.

To Commit, or Not to Commit.

Rumors lead to discussions and meetings about the best strategy for handling such radical changes if A happens, or if B is correct... and then on launch day, we find half the rumors to be true, and the other half to be bogus, meaning more discussions and meetings!

As a company in the mobile app field, new product launches and software updates affect so many teams and departments. From initial sales, project management and scheduling, through to the creation of final assets and most importantly our clients and their expectations.

“What needs to change to make my app work on the iPhoneX? Will my app work on the iPhoneY? Do I need a new app to work on the iPhoneZ?”

All valid questions. Some clients are proactive and have already asked the questions while keeping up to speed with the build up, some will be reactive to the event and panic.

Before, during or after the event we always seem to go through the same cyclic experiences. How do we continue to cater for such innovations which may or may not affect projects being planned, in production or pending launch, and at what stage do we look for alternative solutions to the current process?

In Preparation

Before this particular Apple event, the design team at Fueled started thinking about our current design process, the steps we go through, and what changes we may need to implement in order to cater for the next batch of proposed updates. We came up with the following forethought's:

1. With the introduction of a supposed @3x resolution we would likely need to adjust all our UI design output to be fully handled through Sketch, cutting out Photoshop all together. (Currently ~ 80% of our UI design work is now handled through Sketch.)

2. Instead of starting with @2x assets and down-sampling, we would revert back to @1x assets and Upscale. Primary reasons being that up-scaling @2x assets to @3x would cause 1/3 pixels, whereas up-scaling @1x to @2x and @3x would allow us to keep the crisp edges on all our artwork.

3. We would likely have to consider treating the UI/UX of the largest of the devices (Now known as 6+) differently to the smaller (Now known as 6).The reason being, if plans hold true the amount of pixels available on the width of the 6+ would be close to or as much as what is currently available on the height of the current iPhone 5, 5C and 5S. With this extra height and difficulty in operating the 6+ with one hand, we believe there’s a much higher chance of users orienting their phone in landscape mode.

After the event, most of the above holds true.

Point 2 is a little different as no matter what approach we take, the auto down-scaling from 1242 x 2208 to 1080 x 1920 on @3x assets means we are not going to have a crisp result anyway. However initial reports state that the PPI is so high users will not notice.

With Apple putting emphasis on the larger screens being a benefit for improved visible real estate, this immediately altered our views on simply having to create 3 sets of assets. It is not just about up-scaling and handling larger assets and viewing the same layouts on bigger screens, it is about increasing space for more content to be seen on screen at once.

What Does This Mean?

Take a simple graphical button as an example. It is a single .png asset, with dimensions of 60px high and 300px wide @1x. This would make it 120px high and 600px wide @2x.

Setting the iPhone 6+ aside for the moment, the iPhone 6 screen resolution being the same as the 5 but the screen size being larger, the fixed size button would simply increase in size (height and width) like so:

 This approach should ‘just work’. To most users your assets will look pretty sharp and your layouts won’t be affected. More about pixel pushing here. But notice the increased size and position means there is no gain in screen real estate.

In order to address this we actually need to apply different ratios for our assets based on the space available. So our button @2x on an iPhone 5 would be 600px W x 120px H, but on the iPhone 6 (Same 326ppi retina screen as the 5) the button would be wider to cater for the additional width stopping it looking out of place on the wider viewport, while keeping the same 120px height to the button. This will improve vertical real estate.

So What Do We End Up With?

Multiple resolution assets that need to be responsive…

RWD (Responsive Web Design) Has been around for quite some time now, and the methodology of designing a website to be device agnostic has become common practice.

So why is this not the case form designing on native iOS apps?

Is it because in every product launch, Apple convince us that the devices they are producing this year are the best yet? The perfect companion to your hand? Therefore to design specifically for this device must mean any other size or scale is inferior.

Or is it because we know that if we are designing for a specific device we can make it exactly how we want it? Sized and positioned to perfection.

Enter RAD

Responsive App Design — RAD is not a brand new concept (although the coined abbreviation in this article might be!)

With the addition of AutoLayout since iOS6 we have the capability to develop responsively for native iOS apps, yet we still design assets for specific devices…

Designing for devices restricts and guides us by whatever device gets released next. If we take a RAD approach, we could be more proactive, creating a single set of assets that can be coded rather than sliced, in turn reducing efforts in formulating raw visual designs, then (as in-browser designing has done for web design) shift our design efforts in to manipulating our interfaces via collaborating designers with front end development and prototyping.

So in our above example, instead of providing a number of different graphical assets for our rounded corner button, we should be considering designing assets that can be coded, therefore only ever needing to provide visual guidance rather than a range of scaled graphics.

Taking this approach with coded elements using AutoLayout we can easily increase content real estate by simply adjusting the ratios of certain cells as seen in this visual of the native Clock App by Glenn Hitchcock.

RAD will not be suitable for every app, as RWD is not suitable for every website. Lets look at a couple of examples where RAD may and may not be appropriate.

Tinder has minimal content, and utilizes the whole screen with custom UI graphics designed specifically to fit all desired interactivity on to the initial viewport. It uses a swiping UX for liking and disliking matches, and is a perfect example of where perhaps additional real estate may not be needed.

Tinder may benefit from only up-scaling its interface. It would mean larger ✗ and ♥ call to actions and larger photography. They may also opt to alter their UX completely for iPhone 6 and 6+.

Twitter however, along with other apps that require an overflow of content will definitely benefit from the increased flexibility of allowing a greater real estate for content, and also adjusting content layouts based on orientation and screen size.

Looping the 6+ back in, for apps like Twitter and Facebook we are most likely going to see split column or alternative layouts as per the current iPad apps. The fact that we know this further promotes the benefits of RAD, as all extended assets if handled programmatically should condense or adjust without the need for additional sliced assets.

Limits and Extreme Cases

We had a glimpse of the new Watch which I know we are all itching to get our hands on and start designing for, but Apple stated clearly in the keynote that certain gestures and interface elements would simply not transition down well, and would not work on a screen the size of the one on the Watch. This makes a lot of sense.

RAD approach is of course going to be somewhat guided by the constraints of specific device limitations. It will never be a case that one responsive design fits all and that is not what this article is proposing.

Size Classes

Apple want us to stop thinking about specific devices with set screen sizes, but instead use Size Classes. Size classes were introduced in the iOS8 SDK. As Designers we must start taking the approach of making appropriate UI decisions based around what size class our device is defined within.

There are presently 4 size classes.

• Horizontal Regular

• Horizontal Compact

• Vertical Regular

• Vertical Compact

So where does the current Apple device line up fall within?

• iPad, iPad Air, iPad Mini — Portrait = Horizontal Regular

• iPad, iPad Air, iPad Mini — Landscape = Vertical Regular

• iPhone 4s, iPhone 5, iPhone 5C/S — Portrait = Horizontal Compact

• iPhone 4s, iPhone 5, iPhone 5C/S — Landscape = Vertical Compact

Here is where I believe the new devices should fall within:

• iPad, iPad Air, iPad Mini, iPhone 6+ — Portrait = Horizontal Regular

• iPad, iPad Air, iPad Mini, iPhone 6+ — Landscape = Vertical Regular

• iPhone 4s, 5, 5C, 5S, iPhone 6 — Portrait = Horizontal Compact

• iPhone 4s, 5, 5C, 5S, iPhone 6 — Landscape = Vertical Compact

• Watch — New Size Class = Super Compact/ Micro?

I think there is a high chance that when the Watch is introduced we will be seeing a new size class.

Any device has a horizontal size class and a vertical size class. Knowing this we can then decide the best way to treat the UI. It is my opinion that iPhone 6+ should be treat as Regular rather than Compact, as I believe layouts designed for Regular size classes will be more appropriate for the 6+ than Compact layouts.

As devices all fall within a boundary of size classes it means our design approach can be streamlined to produce less assets for more devices, rather than the immediate view of having to create more assets to suit a limited list of devices.

RAD is the future, it will play a large part in improving our process for designing for multiple devices. It will hopefully introduce more flexibility in our designs process meaning we will be more proactive with our decision making on what future proof interface choices are best for the end user, rather than reactive amendments to fixed screen size limitations.

Special thanks to the @glennui and @metatheoretic for contributing to this article.

This article was originally posted on Medium.