We ship a mature document viewer (PDF) written mostly in Objective-C with UIKit. It runs on iPhone and iPad and supports multiple scenes. We're planning support for iPhone Duo and would like advice on the right architectural approach before we start. Current structure (simplified) One root viewer view controller (a UIViewController subclass, large and long-lived) owns the document view, search, bookmarks, text-to-speech, presentation mode and similar features. Most of these live in categories and helper modules. Chrome is swapped by size class. A factory picks one of two "toolbars controller" classes based on the trait collection: one for compact, one for regular. The regular one also hosts a tab strip and a sidebar built on the system sidebar UI. When the class it would pick changes, traitCollectionDidChange: tears down the current chrome controller, builds the other one, re-parents the document view into the new container, and then restores tool and presentation state. We skip this while the app isn't active, because UIKit sends trait changes during backgrounding. Geometry changes go through viewWillTransitionToSize:withTransitionCoordinator:, which forwards to the chrome controller, the document view and a zoomed handwriting helper. When the transition completes we recompute content insets and re-render the output for an external display. The document view is a custom scroll-based view (not PDFKit). It has display modes for continuous, single page, two-page spread and two-page spread with a cover page. It calculates its own insets from safe areas and whatever chrome is visible. We still use traitCollectionDidChange: and haven't moved to registerForTraitChanges:. Questions Posture changes and size-class flips. When the device folds or unfolds, should we expect a normal viewWillTransitionToSize: plus a trait change (compact ↔ regular) that our existing swap handles? Or is there a posture/display-configuration signal we should observe instead? Swapping the whole chrome hierarchy in the middle of a fold animation seems costly. Is there a recommended way to defer or coordinate that with the transition coordinator? Hinge or seam area. Is the fold region exposed through safe-area insets, layout guides or a new API? A custom scroll view that lays out two-page spreads needs to keep content out of that region, or line the spread up with it. What's the recommended way to get this geometry from Objective-C? Two-page spread tied to posture. Showing a two-page spread automatically when the device is unfolded (like an open book) seems natural. Does Apple recommend deciding this from traits/posture or from bounds, and is there a trait we can override per view controller? Trait registration. For this form factor, is it effectively required to move from traitCollectionDidChange: to registerForTraitChanges: (for example to get notified about new traits), or will the legacy callback still fire reliably? Scenes and external displays. Does iPhone Duo change anything about scene activation, window geometry or UIScreen handling that a multi-scene app with external-display output should plan for? Incremental adoption. Can we adopt this step by step in Objective-C, or do some of the APIs only exist in Swift and push us toward Swift wrappers? Any pointers to WWDC sessions, sample code or documentation for adapting existing UIKit apps would be very helpful. Thanks!

We have a mature Objective-C/UIKit PDF editor. Its editing UI uses two custom toolbar views that we build and lay out ourselves, so they aren't UINavigationBar or UIToolbar items: a tool-selection bar (annotate, edit, sign and so on), and a tools bar that shows the tools for the selected mode, with contextual options. They hold custom controls, selection state and popovers that can't be expressed as bar button items, so moving to UINavigationBar or UIToolbar isn't realistic for us. Right now we swap between a compact and a regular toolbar layout on size-class changes (traitCollectionDidChange:), and handle geometry in viewWillTransitionToSize:withTransitionCoordinator:. Questions: Posture changes: When the device folds or unfolds, what's the recommended way for custom toolbar views to adapt? Should we rely on size-class and size transitions only, or is there a posture signal we should observe? Fold region: How should custom bars avoid the fold? Is it exposed through safe areas or a layout guide, or should we split a bar across both halves? Placement: In a partially folded (tabletop) posture, is there guidance on moving tool bars to the lower half, the way the system does for its own bars? Workarounds: If the system bar behavior for fold postures isn't available to custom views, what have others done? For example, hosting our custom views inside system bars, or mirroring system bar positioning manually. Suggestions or pointers to docs, sample code or WWDC sessions would be much appreciated. Thanks!