Preparing an app for iPhone Duo starts with an assessment of the current product, followed by a small, testable release scope. Identify which customer tasks must work, record existing behavior, and assign measurable acceptance criteria before estimating the update.
Apple has published an iPhone Duo developer resource hub covering design, app preparation, adaptive layouts, multiple displays and camera experiences. As checked on September 11, 2026, the hub lists Xcode 27.1 beta and the written preparation guide as coming later that month. Teams can begin discovery now while checking the hub for tooling availability.
The workflow below is our proposed delivery approach. It is a planning framework, not an Apple certification program or a promise of a particular delivery time.
What should an iPhone Duo readiness assessment include?
A useful assessment produces a list of affected journeys, reproducible issues, dependencies and release decisions. A presentation full of device screenshots is insufficient to estimate engineering work.
Start with five questions:
- Which journeys generate revenue or support the app’s main purpose?
- Which screens use custom navigation, fixed dimensions or embedded third-party interfaces?
- What user information must survive a layout change?
- Who owns each dependency that could block a fix?
- What evidence will show the release is ready?
For a booking app, the first journey might be selecting a service, choosing a time and completing confirmation. For an operations app, it might be opening an assigned job, editing a report and submitting it with attachments. These concrete paths keep the assessment connected to customer outcomes.
How should teams divide compatibility and feature work?
Create separate milestones for reliable task completion and additional product capabilities. This makes the first release easier to estimate and gives optional features an explicit business case.
| Milestone | Main question | Evidence to collect |
|---|---|---|
| Baseline | What does the current build do? | Build identifier, recordings and issue list |
| Essential update | Can customers complete priority journeys? | Repeatable acceptance results |
| Product improvement | Does the extra space improve a task? | Prototype feedback and task comparison |
| Release | Can the team support the shipped behavior? | Known issues, support notes and monitoring owner |
An expanded comparison workspace could be valuable for a purchasing app. A decorative animation may be less urgent. Evaluate both against a task: what becomes easier, what new complexity appears, and how will you measure the difference?
What can you prepare before the simulator is available?
Document the current implementation, reproduce existing defects and agree on acceptance criteria. Review the official sessions with the people who own design, engineering and QA, then capture unanswered questions in one shared document.
Apple’s hub also lists group labs and framework Q&A sessions. These are useful places to take a specific implementation question with a minimal example, rather than a broad request to review an entire app. Check the official event listings for current schedules.
Avoid attaching a fixed estimate to an unknown dependency. Instead, timebox the investigation and specify its output: a working sample, a vendor answer or a documented limitation.
How do you write acceptance criteria that prevent rework?
Describe a starting state, an action and an observable result. For example: a customer enters a booking note, changes the available layout, then continues with the same note and selected appointment intact.
Include failure states too. An expired session, unavailable network or rejected submission should remain understandable and recoverable. Assign someone to verify the behavior and record the tested build.
Our iPhone Duo testing checklist expands this approach into a practical QA matrix.
Frequently asked questions
Does every team need a complete rewrite?
A readiness plan should not assume a rewrite. First identify specific defects and architectural constraints. A rewrite needs its own evidence that targeted changes cannot meet the agreed requirements.
How long should the update take?
Estimate after inspecting representative journeys and dependencies. The number of affected screens, custom components and release constraints matters more than a universal number of weeks.
What should a readiness partner deliver?
Ask for a reproducible baseline, prioritized scope, acceptance criteria and a release recommendation with supporting evidence. These outputs make a proposal reviewable and help an internal team continue the work.
Plan the next release
Bring the current app, its most important journeys and known constraints to a Comms project discussion. A clear brief gives product and engineering teams a shared basis for deciding what to build first.