Test iPhone Duo apps by combining important customer journeys with changes in presentation, input and app state. A screenshot can demonstrate alignment; a completed journey demonstrates whether a customer can still use the product.
This checklist is a proposed QA workflow for product teams. Tailor it to your app’s actual capabilities and supported environments, and record unsupported or unavailable test conditions explicitly.
What should an iPhone Duo test matrix cover?
Start with the journeys that matter most: signing in, finding an item, creating or editing data, completing a transaction, and recovering from failure. Add presentation changes to those journeys instead of maintaining an unrelated gallery of screenshots.
Use the following as a starting matrix:
| Area | Test action | Expected result |
|---|---|---|
| Navigation | Change presentation while viewing a selected record | The same record remains identifiable |
| Forms | Enter text, change layout and continue | Values and validation remain correct |
| Keyboard | Focus the last field in a long form | The field and next action remain reachable |
| Media | Change layout during playback | Position and controls behave as specified |
| Errors | Interrupt a request and resize the app | The error remains visible and recovery works |
| Accessibility | Navigate the changed interface with assistive technology | Reading order and control names remain useful |
Attach build and runtime identifiers to the results. Without those details, a passing check cannot reliably support a release decision.
How should you test transitions?
Begin a task, change the presentation at a meaningful moment, then complete the task. Repeat in the reverse direction. Include intermediate states such as a loading indicator, open confirmation dialog or unsaved edit.
For a booking flow, an illustrative sequence is:
- Select a service and appointment.
- Enter a note without submitting.
- Change the app’s available presentation.
- Confirm the service, appointment and note are still correct.
- Submit once and verify that exactly one booking is created.
This last assertion matters. A visually correct screen can still submit twice or discard a field after a transition. Check the resulting data as well as the interface.
How do Split View and multiple windows differ in testing?
Test app resizing alongside another app separately from opening another instance of your own app. These scenarios exercise different state assumptions.
Apple’s multiple displays and scenes session describes side-by-side multitasking and multiple instances of an app’s UI. New windows are available on the inner display, and apps should handle scene-request failures. The same session explains that scene-accessory availability can change dynamically.
For an app that supports multiple windows, open different records in each window and edit one. Verify which changes should synchronize and which selections should remain independent. Close a window with unsaved work and confirm that the documented recovery behavior occurs.
For optional camera accessories, include appearance, disappearance and unavailable states in the relevant journey. Do not mark the entire app as covered simply because its main screen passed.
What accessibility checks belong in the release?
Use representative long labels and larger text settings. Check that primary actions retain useful names and that a changed visual arrangement still has a sensible reading order.
Run a complete priority journey using the accessibility features your product supports. Record any point where someone must guess what changed or cannot reach the next action. Include error recovery; an accessible success screen does not compensate for an unreachable validation message.
Keep these checks attached to the same release criteria as other functional requirements so they have an owner and a result.
How should defects be prioritized?
Classify defects by their effect on the customer, then record severity separately from engineering effort.
- Release blocker: lost work, duplicate submission, a crash in a priority journey, or an inaccessible essential action.
- High priority: a core task requires a confusing workaround or repeated navigation.
- Lower priority: cosmetic spacing or animation issues that do not obstruct the task.
These are proposed categories; agree on the actual release policy with the product owner. A small visual defect can be serious if it obscures the only confirmation button.
Frequently asked questions
Is simulator testing sufficient?
A simulator provides reproducible test conditions. Record which behaviors still need validation on available hardware, particularly camera interactions and physical ergonomics. Avoid claiming coverage for environments you have not tested.
How many combinations should we test?
Prioritize by task importance and known failure modes. Expand the matrix when a defect reveals a shared component or state-management problem affecting additional journeys.
What proves readiness?
A traceable report with the tested build, covered journeys, observed results, unresolved defects and an accountable release decision. A count of screenshots or test cases alone is insufficient.
Use the iPhone Duo product readiness plan to define the scope, or contact Comms to discuss the journeys and constraints in your app.