1

In my app, most of the views have major UI design differences when used on a small device (e.g. iPhone portrait) vs a large one (e.g. iPad fullscreen.) The basic architecture remains the same, but each View Controller needs to display a very different set of UI elements.

I could respond to size changes in Interface Builder, by Installing and Uninstalling elements and Auto Layout Constraints according to size class, but this would be extremely unwieldy and fragile.

In ye olden days (~2014), Apple's advice was:

If you want to present the same data differently based on whether a device is in a portrait or landscape orientation, the way to do so is using two separate view controllers. One view controller should manage the display of the data in the primary orientation (typically portrait), while the other manages the display of the data in the alternate orientation.

Despite the advent of Size Classes, this strikes me as still the best solution for my particular design (remembering to take size classes and split-view, slide-in to account.)

Question 1: at what point in my app should I detect the trait changes?

Question 2: (presuming that I have loaded an alternate view controller from a storyboard) in response to the trait change, how should I best transition/present the alternate view controller?

I am asking the same question asked here: Adaptive swapping of View Controllers in response to Size Class Trait changes iOS 9

Because nobody answered the original question.

Community
  • 1
  • 1

1 Answers1

1

If you're talking about trait changes during runtime, for example device rotation and iPad multitasking, you can use viewWillTransitionToSize (see this question for sample code) and adjust the view hierarchy (with animations, if you like) within this method. Just use the normal view and view controller presentation methods to add / remove presented controllers, or child controllers and their views.

If you're talking about trait changes at launch time (iPad vs. iPhone), just create a different storyboard or root view controller for those two devices and set it in your app delegate. This approach will have the downside of not offering an iPad-like experience for the plus-sized iPhones in landscape without additional work on your part, though.


I want to challenge something you said, though:

I could respond to size changes in Interface Builder, by Installing and Uninstalling elements and Auto Layout Constraints according to size class, but this would be extremely unwieldy and fragile.

Xcode 6 and later support "unified storyboards" which the docs describe like so:

A storyboard can add or remove views and layout constraints based on the size class that the view controller is displayed in. Rather than maintaining two separate (but similar) storyboards, you can make a single storyboard for multiple size classes. First, design your storyboard with a common interface and then customize it for different size classes, adapting the interface to the strengths of each form factor.

Xcode 8 makes it especially easy to design these highly adaptive views. You can switch into an editing mode for a particular size trait, and even preview how a view controller will look on a variety of devices. Before continuing further down your current path, I encourage you to dig in to the improvements in Xcode 8 if you haven't already and see if you can make unified storyboards work for your use case.

Community
  • 1
  • 1
Aaron Brager
  • 65,323
  • 19
  • 161
  • 287
  • Thanks for your answer Aaron. I forgot to mention one thing. My view on iPad vs the same view on iPhone do not share any common UI elements. Its a completely different view. – Ankit Goyal Sep 09 '16 at 18:40
  • In that case it sounds like unified storyboards won't work. But it also sounds like it might be a confusing app :) – Aaron Brager Sep 09 '16 at 21:34