iPhone Duo tutorials
Design the controls, not just the canvas
Use Apple’s toolbar session to plan control groups, ordering and overflow, then turn those questions into a design-review worksheet.
On this page
Begin with the actions your user needs, not with a rotated toolbar mockup. Watch the selected parts of Apple’s session, then document action priority, grouping and reduced-space behavior in your own design. The worksheet below is Plurigent’s suggested process, not an SDK test.
Raise the bar with iPhone Duo
Six chapter links and selected Apple transcript text rechecked October 4, 2026. The existing YouTube association is retained, not newly playback-tested. Design exercises are by Plurigent.
- Publisher
- Apple
- Source checked
- Verification
- Source page checked
Selected chapters
Times follow the publisher’s chapter index. The prompts below are Plurigent’s suggested exercises.
- Understand the space being shared
Name the main user task before choosing where to place controls.
- Separate the bar from the surrounding layout
Mark the content area and the proposed action groups in your own sketch.
- Review the action order
Compare how a reviewer finds the way back and the task completion action.
- Inspect the representation of each action
Write a plain-language meaning beside any ambiguous symbol.
- Plan for less available space
Sketch a second arrangement and explain your action priorities.
- Discuss what should remain easy to find
List open questions for native implementation rather than guessing system output.
What the session contributes
Apple explains how navigation, toolbar and tab controls can share a vertical region. The session treats ordering, item representations and overflow as connected decisions; inner portrait layouts and some containers differ. Do not interpret it as a rule to rotate every control in every view.
Start with an action inventory
Choose one screen from your own work. Write down every action before drawing the bar: returning, completing the task, editing, sharing, changing a mode, or opening secondary options. Include disabled and destructive actions so the tidy first state does not hide the difficult cases.
Next to each action, record its purpose and how often your target user needs it. Do not assume that an icon-only rendering means the meaning is obvious. Ask a reviewer to explain each action without seeing your layer names.
Use the chapter links as review checkpoints
At each checkpoint, pause and annotate your own screen rather than reproducing Apple’s example. Make a second arrangement with less room. Keep a question mark beside any behavior you have not seen in your actual implementation.
For a freelance review, bring both arrangements to the same conversation. Ask the client to choose which task must remain obvious, rather than inviting a vote about which screenshot feels cleaner.
| Decision | Review prompt | Useful handoff artifact |
|---|---|---|
| Grouping | Which actions complete the current task, and which navigate elsewhere? | A named group for each action, including a reason. |
| Ordering | Can the reviewer find the way back and the main action in both compositions? | Two annotated arrangements with the same task and content. |
| Representation | Can each symbol be understood without your explanation? | Labels and accessibility-intent notes beside ambiguous icons. |
| Reduced space | Which lower-priority actions could move out of the primary view? | A proposed priority order and an example overflow state. |
Sketch the unavailable-space state deliberately
A full toolbar is only one state. Add an example where less space is available and ask what the user can still discover. Treat the priority order as a proposal to review with the developer, not a claim about exactly which item the system will hide.
Record actions that must remain easy to locate and actions that are reasonable to find in a secondary menu. Keep the menu understandable on its own; the user may not remember the original toolbar order.
Keep design intent separate from implementation proof
The Online Simulator can help you discuss composition and presentation of your prototype. It does not implement native toolbar adaptation or overflow for the embedded content. Write unresolved system behavior into the implementation notes, and use native testing for confirmation.
Developers can continue through the complete original session for its API discussion. This viewing route intentionally emphasizes design decisions rather than reproducing code samples.
Specify whether the design uses system navigation containers or a custom bar. Built-in adaptation is not automatically inherited by custom controls. Treat a system app’s individual arrangement as an example rather than a universal rule; review the intended horizontal/vertical choice and unresolved behavior with the implementer.
Scope and review details · v1.0.1
Scope: official sources and practical guidance. Runtime measurements and hands-on observations are labeled separately and should be rechecked against the stated versions.
- Last reviewed
- Applies to
- Designers and freelancers preparing iPhone Duo designs
- Verification status
- Apple’s chapter list and selected toolbar transcript text reviewed October 4, 2026. Playback, subtitles, API sample execution and native-device behavior were not tested.
Sources & review scope
Official six-chapter index and selected toolbar transcript reviewed October 4. No playback, subtitle, compiled sample or native behavior check.
Apple Developer · Sources checked Oct 4, 2026