How do I update an iPhone app guide when the screens change?

Fix what stops the reader, not every changed pixel

A new icon colour rarely needs a rewrite. A button that moved into a menu does, because the old instruction stops working. Start by following the guide in the current app and sorting what you find.

What changed	What to do
Colour, spacing or decoration	Check the control is still easy to recognize. Update the picture only if it confuses.
A control was renamed or moved	Replace the screenshot, fix the instruction and move its marker.
A new permission or confirmation	Add the step or prerequisite, and say what the reader should choose.
The task follows a new order	Record it again and rebuild that part of the guide.
Only some account roles see it	Name the role, or keep separate instructions for each.

A guide is current when someone can follow it, not when every screenshot is recent.

Keep a short record for each guide

Put a note like this in the guide, or wherever your team keeps guides.

Example:

Task: Change the delivery instructions on an existing order
Audience: Customer account, iPhone
App/version checked: [app name and version, if available]
Guide owner: [person or team]
Last tested: [date]
Review trigger: Checkout, order-details or delivery settings change

A specific trigger beats assuming every release breaks every guide. Add a calendar review too, to catch changes nobody told you about. Set how often by how often the app changes. A tip block at the top of the guide is a good place for this note.

Take screenshots that survive the next update

Technical writers who look after hundreds of screenshots often use fewer of them and crop the ones they keep. A full-screen picture goes stale when any part of the app changes. A picture cropped to the part the step is about survives a new tab bar or header.

• Crop to the part that matters, but keep enough for the reader to recognize the screen. Walkthru’s per-step crop keeps the original, so you can widen it later.
• Keep a list of which guide uses which screen. When the app changes, the list tells you which guides to check. That is the hard part of keeping screenshots current.
• Skip pictures of screens readers can already see, such as a settings list they can read for themselves. Keep pictures where they need help finding something.

If you document your own app, your developers may already capture screenshots in automated UI tests. Those can refresh a help centre’s pictures, but a person still writes the instructions and places the markers.

Replace the picture, then fix everything on it

Say the old instruction reads “Tap Edit at the top right”, but the app now hides Edit delivery instructions inside a menu. A new picture alone leaves two problems: the instruction points to the wrong place, and the old tap marker may land on the wrong control.

So replace the screenshot, rewrite the instruction with the new label, and add a step for opening the menu if needed. Then check the crop, markers, text labels and redactions. Walkthru keeps accepted redactions when you replace a picture, but it can’t tell whether the private field moved. Review any new redaction offers too.

If the new picture has a different shape, the crop resets to show all of it. Choose a new crop on purpose. In the video, that step shows the new picture instead of footage that no longer matches.

Test the whole task, even after a small change

A new button may appear only after a permission is granted or an earlier field is filled in. So even a one-step edit deserves a full run-through.

Ask someone to start where the guide says, with the reader’s account role. Have them mark the first place they need help the guide doesn’t give. Fix that before touching anything else. At the end, check that the promised result really appears.

If the last step commits something real, test with sample data or a training account.

Replace the copy people actually use

An updated file on your phone doesn’t help someone opening last month’s attachment. Find where the guide lives: a help-centre article, a shared folder, an onboarding page or a saved support reply. Replace the file there, update its revision label and check links from other documents.

Example file name: delivery-instructions-v2-2026-09-27.pdf. Keep one clearly marked current version in the shared location, and archive the old one.

Before you finish, confirm:

• The starting screen, account role and permissions still match.
• Every named control exists, and every marker points at it.
• Private details are covered in the exported file.
• The final screen matches the promised result.
• The shared copy has the new content and revision note.

Walkthru doesn’t track versions, host a guide at a fixed link or update copies people have already downloaded. Keep the record yourself, and replace shared copies by hand. If the guide is part of a formal procedure, keep its owner and review date with the mobile SOP template.