# iPhone Duo toolbar design: a video guide for designers > 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. Author: Plurigent Content version: 1.0.1 Source review: Oct 4, 2026 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. Original page: https://plurigent.com/tutorials/iphone-duo/toolbar-design-video Use Apple’s toolbar session to plan control groups, ordering and overflow, then turn those questions into a design-review worksheet. Scope: official sources and practical guidance. Runtime measurements and hands-on observations are labeled separately and should be rechecked against the stated versions. Reading scope: For Designers / For Developers Content formats: Video guide ## Original source [Apple](https://developer.apple.com/videos/play/tech-talks/111462/) 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. Source page checked Open the original source at its publisher for the complete material and access details. ### Selected chapters Times follow the publisher’s chapter index. The prompts below are Plurigent’s suggested exercises. - [0:28 · Understand the space being shared](https://developer.apple.com/videos/play/tech-talks/111462/?time=28) — Name the main user task before choosing where to place controls. - [3:09 · Separate the bar from the surrounding layout](https://developer.apple.com/videos/play/tech-talks/111462/?time=189) — Mark the content area and the proposed action groups in your own sketch. - [4:29 · Review the action order](https://developer.apple.com/videos/play/tech-talks/111462/?time=269) — Compare how a reviewer finds the way back and the task completion action. - [5:56 · Inspect the representation of each action](https://developer.apple.com/videos/play/tech-talks/111462/?time=356) — Write a plain-language meaning beside any ambiguous symbol. - [11:40 · Plan for less available space](https://developer.apple.com/videos/play/tech-talks/111462/?time=700) — Sketch a second arrangement and explain your action priorities. - [13:10 · Discuss what should remain easy to find](https://developer.apple.com/videos/play/tech-talks/111462/?time=790) — List open questions for native implementation rather than guessing system output. [Open Simulator](https://plurigent.com/simulator) Browser design preview · Native behavior requires separate testing ## What the session contributes Evidence type: Official information 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. [A17 · Raise the bar with iPhone Duo](https://developer.apple.com/videos/play/tech-talks/111462/) ## Start with an action inventory Evidence type: Practical guidance 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 Evidence type: Practical guidance 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 Evidence type: Practical guidance 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 Evidence type: Verification limits 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. [A17 · Raise the bar with iPhone Duo](https://developer.apple.com/videos/play/tech-talks/111462/) ## Sources & review scope - [A17 · Raise the bar with iPhone Duo](https://developer.apple.com/videos/play/tech-talks/111462/) — Oct 4, 2026; Official six-chapter index and selected toolbar transcript reviewed October 4. No playback, subtitle, compiled sample or native behavior check. ## Keep reading - [iPhone Duo design video: a designer’s viewing guide](https://plurigent.com/tutorials/iphone-duo/design-video) - [iPhone Duo Adaptive Layout: Design Across Displays](https://plurigent.com/tutorials/iphone-duo/adaptive-layout) - [Prepare a Figma prototype for an iPhone Duo online preview](https://plurigent.com/tutorials/iphone-duo/figma-prototype-preview) - [Preview an iPhone Duo design in your browser](https://plurigent.com/tutorials/iphone-duo/preview-your-design)