A Standard to Guide AI: Lessons from Apple’s iPhone Duo

2.1 State the result before the steps

Apple opens with the experience the app should provide: continuity as the phone opens and closes. That gives the later rules a shared purpose. For an AI guide, an opening like this provides a way to judge choices that the detailed instructions may not cover.

Start with a result people can notice. For example: “People should be able to finish this form without losing anything they entered when the layout changes.” AI then has a reason to preserve entered text while adjusting the page. You also have a clear outcome to check.

2.2 Define the terms before using them in rules

Apple explains the displays, hinge and cameras before giving detailed layout instructions. Later rules can use those names without explaining them again. This creates a shared vocabulary and gives each instruction a clear target, which helps AI connect a requirement to the right part of the work.

In your guide, define names that could mean different things: “A card is one item in the results list. The detail page opens after selecting a card.” Then “change the card title” is a much clearer request. Include background that affects the work, so the definitions stay easy to find.

2.3 Group changing situations under a shared rule

Apple names several ways to use the device, then brings them back to a small set of layout categories. This connects many visible cases to a reusable way of deciding what to do. For AI, that can be more useful than a growing list of one-off answers that leaves the next case unexplained.

Before writing a rule, list the changes it must handle: a longer title, another language or a narrower window. Then write what they have in common, such as keeping the full title readable and actions available. Use the cases to check the rule, and add an exception when one really needs different treatment.

2.4 Put the instruction first, then explain it

Apple’s main recommendations start with short, bold instructions. Reasons, examples and links follow them. The structure makes the action easy to find while keeping the explanation close by. An AI agent consulting one part of a long guide can get both the instruction and the context for using it.

Write one clear requirement first: “Keep entered information when the layout changes.” Then explain why it matters and give a case to check, such as resizing a partly completed form. Keep extra detail below the rule so readers can find the instruction again without rereading the whole explanation.

2.5 Write rules that work when conditions change

Apple describes spacing in relation to the available area. That makes the rule useful as the screen changes. This is a useful way to write instructions for AI: explain what must stay true across different situations, so one example does not become a fixed answer for every case.

For a card layout, you could write: “Let the card fit its container. Keep the button fully visible when the text wraps.” AI can work out the layout for each width, and you can check both narrow and wide versions against the same rule.

2.6 Write the condition beside the action

The phrase “only present when the camera is active” gives the following instruction a clear condition. Apple also separates adjustments the system handles from work needed for custom components. Together, these details help a reader decide whether an action is needed before making a change.

Use the same pattern in your guide: “When the list is empty, show an explanation and an Add button.” State the condition, then the action. Check both an empty list and a populated one to see whether AI applied the rule in the right place.

2.7 Name the tools AI can use

Apple puts the expected behavior and links to the standard components together. The reader gets a route from the design rule to its implementation. For an AI agent, a named component and an exact reference can reduce the choices it has to make and the details it might otherwise guess.

Your guide might say: “Use buttons from our component library, with its existing sizes and colors. If none fits, explain what is missing before proposing a new one.” This gives AI a starting point and a clear next step when that starting point is not enough.

2.8 Define how far each instruction reaches

Apple defines the job of an arrangement view, then says where navigation belongs. That boundary matters: a reader can see which part should handle each responsibility. In instructions for AI, this helps keep a request to change one part from spreading into nearby behavior.

For example: “Adjust the card layout. Keep its link destinations and button actions unchanged.” The first sentence names the work; the second sets its limits. The result is easier to review because everyone knows what the change was meant to cover.

2.9 Make the default and its exceptions easy to find

Apple introduces the usual position of the controls and gives an exception alongside it. It then explains cases such as two apps sharing the screen. This order gives readers a starting rule and a way to decide when it changes. It also makes exceptions easier to find when AI consults just this part of the guide.

For a form, write: “Place the label above the field by default. Put checkbox labels beside the checkbox.” Keep both sentences together, then ask AI to check one example of each. That makes a broad instruction less likely to be applied to the wrong case.

2.10 Say which requirement wins when they compete

Keeping every control visible becomes impossible when space runs out. Apple gives an order of importance and lets that order be refined for groups and individual items. The useful writing choice is to explain how to make a trade-off before the reader has to make one.

A short summary needs the same kind of rule: “Keep decisions, owners and deadlines. Shorten background discussion first.” Now AI has a basis for cutting the text, and you can judge the result against an agreed order instead of deciding after each rewrite.

2.11 Turn a broad goal into something you can check

Apple follows its advice about control placement with a reason and a Mail example. The example shows how a control’s position tells people what it affects. This connects the rule to a visible result, so readers have more to work with than a general request for a clear interface.

Use that structure in your own design guide: “Put each error message beside the field that needs fixing, so people know where to act.” You have named the action, its purpose and a visible check. AI can use those details while making the page and reviewing its work.

2.12 Give a fallback and a reason to choose it

Apple explains what to preserve when space runs short by asking whether the screen is mainly for browsing or completing a task. It also points to one shared place for the remaining actions. The instruction covers both the choice and what happens to anything that no longer fits.

A report guide could say: “If the summary exceeds one page, keep the decisions in the main text and move supporting detail to an appendix.” AI has a clear fallback, and the detail still has a home. Add what to flag for you if the limit cannot be met without losing something essential.

2.13 Use examples and references to resolve uncertainty

A diagram can make a spatial relationship clearer than another paragraph. A precise reference lets readers check an implementation detail without making the main rule longer. Apple uses both. For an AI guide, the useful lesson is to give each supporting item a job: show the intended result or answer a specific question.

Attach a sample screen with a note about what to notice, or link to the exact component the task should use. Keep the key requirement in text too, and check whether the AI tool can open the image or link. An attachment only helps if the tool can actually use it.

The references Apple includes

These are the supporting links in the Markdown file. The developer names are kept as written so an AI coding tool can find the right reference.

2.14 Make the rules easy to review later

Apple’s change log and source footer give the guidance a date and an owner. These details serve a different purpose from the design rules: they help readers trace where the advice came from and whether it may need another look. Reusable AI instructions need that history as the product changes.

Record what changed, when it changed and where the decision came from. “14 September: error messages now appear beside fields; see the approved form example” is more useful than a date alone. It helps you and AI identify the rule to update when the design changes again.

Checked against the Markdown file supplied for this draft on 14 September 2026.