How should a bank release a redesigned mobile app without a new wave of bad reviews?

The redesign fixes what the old reviews complained about. It goes out to every customer on a Sunday. By Monday the new reviews say: “Where are my saved beneficiaries?” “It logged me out and now I have to register again.” “Forced me to update before I could pay a bill.” None of them is about the design; every one is about the release. This scenario is illustrative.

Turning old complaints into a brief is covered in our guide to diagnosing bad bank app reviews before a redesign. This guide, published by Humbleteam, a product design agency, starts once the new app is built. The short answer: release to a small share of customers on both stores, make sure sign-in and saved data survive the upgrade, show people where features moved, ask for ratings only after a task succeeds, answer reviews fast, and agree before launch which numbers make you stop.

What do the App Store and Google Play let you control?

Sources: Apple’s phased release and Google’s staged rollouts.

Neither store can move a customer back to the old version. A pause or halt only protects people who have not updated yet, so the real fallback is a fixed build, and on iOS it goes through review again. Apple says it typically reviews 50% of submissions in under 24 hours and 90% in under 48. Plan a hotfix in days. On Google Play, a new release rolled out before the previous one completes goes to the same group of users, so the fix reaches the affected customers first.

Should you force customers onto the new version?

Not for a redesign. Google’s in-app updates offer a flexible flow that downloads in the background and an immediate flow that blocks the app until the customer updates. Google’s example strategy keeps the immediate flow for critical security fixes. Each release carries a priority from 0 to 5 that cannot be changed after rollout, so set it before you submit. On iOS, a forced update is something the app builds itself, usually a minimum-version check.

Keep the old version and its server endpoints working through the whole rollout, because many customers stay on it for days. Announce a retirement date inside the app later, and use a flexible prompt first.

What has to survive the upgrade?

Test sign-in on an upgrade, not a fresh install: install today’s store version, sign in, set up biometrics, then update and open the new build. A new login system or a new way of storing tokens can turn an update into a full re-registration, which for some customers means a call or a branch visit.

Then list everything customers have set up: saved payees, favorites, default account, language, notifications, card controls. For each item, note where it lives (bank servers or the phone), who migrates it and how you will check it. Data kept only on the phone survives only if the new build reads it. A customer who chose Arabic and wakes up to an English app has lost something too.

How do you tell customers what moved?

Apple requires “What’s New in This Version” text for every update and lets you localize it. Google Play takes localized release notes and asks that they inform rather than promote. Write plain facts: “Transfers are now on the home screen. Saved beneficiaries are under Payees.” Inside the app, point to a moved feature where it now sits, the first time someone looks for it, instead of a tour on launch.

Write the Arabic and English versions as two texts, not one text and its translation. In a mirrored Arabic layout, “top right” is on the other side of the screen.

When should the app ask for a rating?

Apple’s review request appears at most three times in 365 days, and guideline 5.6.1 disallows custom review prompts. The Human Interface Guidelines say to ask after people show engagement, not on first launch or mid-task, and Apple says not to trigger the prompt from a button. Google’s In-App Review API has an unpublished quota and forbids asking “Do you like the app?” before the card. Google Play policy bans rewards for ratings.

For a bank, a good moment is the confirmation screen after a payment goes through. Bad moments: right after sign-in, after an error or a failed code, and the first launch after the update.

Timing matters more after a redesign. Google says its displayed rating is weighted toward recent ratings and does not start over with a new version. Apple keeps a separate rating per country storefront, so the UAE rating moves only with UAE ratings. Apple also lets you reset the overview rating when a version ships, in every country at once and with no undo; written reviews stay. Apple recommends doing it sparingly. Reset only if this version fixes what drove the old rating and enough customers will rate soon.

How should the team reply to reviews?

Both stores support developer replies and notify the reviewer, who can then update the review. Apple suggests starting with the lowest ratings and with technical problems in the current version. Google holds new reviews for about 24 hours before they go public, but you can answer them during that time. Its Play Console page says replying to a negative review can raise that rating by 0.7 stars on average. That is Google’s figure, not a forecast.

Replies are public, so never ask for account or card details; Apple says replies must not include personal information. Before launch, approve replies in Arabic and English for the problems you expect: a moved feature, a forced sign-in, a missing payee. Tag each review by app version, and use Play Console’s ratings breakdown by language to see whether Arabic and English users react differently.

A rollout plan with go and no-go points

This is a planning model. Apple’s percentages are fixed; the Google Play ones are an example. Compare every number with the old version’s own figures from the weeks before launch.

The Android vitals thresholds are Google’s outer limit for store visibility, averaged over 28 days. The old version’s numbers are the stricter test.

Agree in advance which trigger leads to which response, and who can decide on a weekend. A pause or halt stops new customers getting the build. A server-side switch, if the new screens were built behind one, returns customers to the old flow without a store release. A fixed build removes the cause but waits for review.

An illustrative example

A bank in the UAE releases its redesign on both stores. On day 3, support hears from customers whose saved payee list is empty. Payees the old version kept only on the phone were never read by the new build. The team pauses the phased release and halts the Google Play rollout, which keeps the problem to the small share already updated. A build that reads the old storage passes review, both rollouts resume, and the team notes the fix in the release notes and replies to each review about missing payees, as Apple suggests. The bank and the details are invented.

Where this plan breaks

A smaller bank may see too few customers in the first 1% to spot a pattern; hold the early stage longer. Apple’s phased release covers automatic updates only, so manual updaters skip the queue. Google’s 24-hour hold puts reviews behind support contacts, which makes support the earlier signal. And a store rating mixes every cause, so it cannot show whether one redesigned journey worked.

What you can decide before you submit

Four decisions fit in a week: the list of data that must survive, with an owner for each; go and no-go numbers from the old version’s baseline; the forced-update policy and the App Store rating reset; and approved replies in both languages. If the redesign team is still being chosen, our comparison of agencies that have redesigned a bank’s live mobile app shows which cases to ask about.