Mobile app redesign services

Gradual release tools

Switching new screens on gradually

Feature flags let the app contain both old and new versions of a screen, with the server deciding which each user sees. That allows a redesign to reach a small group first, be compared with the old design and be switched off quickly if something goes wrong, without shipping a new build for each step, as long as the new screens were included and described when the app was reviewed. Flags need tidying once the redesign is fully rolled out, so old code does not linger.

Combined with store rollouts, they give fine control over who sees what.

Protecting users' data and settings

Telling users what changed

• Release notes

  Plain-language notes in the store listing.

• In-app highlights

  A short, skippable tour of what moved.

• Help content

  Updated guides and screenshots.

• Support briefing

  Customer service ready for common questions.

How a redesign engagement runs

1. 01

   Audit

   Ratings, crashes, usage and code health reviewed.

   Output: Priorities

2. 02

   Design and test

   New journeys tested with real users.

   Output: Validated design

3. 03

   Foundations

   Framework and library updates where needed.

   Output: Healthy base

4. 04

   Build behind flags

   New screens built alongside old ones.

   Output: Controlled release

5. 05

   Gradual release

   Rollouts and flags widened as results confirm.

   Output: Redesign live

Supporting users who do not update

Not everyone updates promptly. For a period after release, the backend must keep serving older app versions correctly, or those users will see errors. Decide how long old versions are supported and, where necessary, show a polite prompt to update once a version is too old to work safely. Forcing updates abruptly frustrates users, so use it sparingly and with notice.

Watching the first weeks

Monitor ratings, crash-free sessions, sign-in and sync errors, completion of key tasks and support requests daily during rollout. Compare users on the new design with those still on the old one. Clear evidence makes decisions about widening, adjusting or pausing the release straightforward.

Comparing old and new designs fairly

When some users see the new design and others the old, you can compare task completion, time to complete key tasks, errors and support requests between the groups. Make sure the groups are similar, for example randomly assigned rather than self-selected, and run the comparison long enough for the novelty of the new design to wear off. Early dips are common as users adjust; look at the trend over a few weeks before drawing conclusions.

Share the results with the team so design decisions rest on evidence.

Store review in the release plan

A large redesign is still subject to store review. Apple's guideline 2.3.1(a) says new features, functionality and product changes must be described specifically in the Notes for Review and be accessible for review, and guideline 2.5.19 rules out hidden or dormant features. If new screens sit behind feature flags, describe them in the review notes and make sure reviewers can reach them, rather than treating flags as a way to ship unreviewed changes. Submit early and keep the release date flexible enough to absorb one round of questions.