“We’ll keep the app, we’re just refreshing the interface.” On a mobile project, that sentence rarely survives the scoping phase. On a website, a reskin genuinely can stop at the theme and the stylesheets, because your visitors’ browser stayed backward compatible in the meantime. An app is a binary you compiled on one specific day, with the libraries available that day, and it has to keep running on phones whose operating system has changed four times since.
So behind “let’s redo the app” there are three possible projects, not one: an interface reskin, a framework migration, a full rebuild. They share the same name in a sales conversation, but they share neither the price, nor the timeline, nor the risks. Most of the ugly surprises on mobile redesigns start there: a reskin quote signed for something that was a rebuild from day one.
A mobile app doesn’t age the way a website does
Three clocks run in parallel without asking your opinion. Apple’s and Google’s, which regularly raise the minimum SDK version or the target API level required to ship an update, meaning an app that hasn’t been rebuilt in two years may simply no longer be publishable as it stands. The frameworks’ clock: a 2021 Flutter or React Native codebase is usually two or three major versions behind, with community packages abandoned along the way. And your technical vendors’ clock: payment gateway, push SDK, maps library, each pushing its own breaking changes.
An app with no updates for two years isn’t “stable”. It’s frozen, which is a different thing. Teams that held a real mobile app maintenance budget arrive at redesign time with a design project. The others arrive with a design project plus a full technical catch-up, and that is exactly where quotes double.
The signal that triggers the question, and what it actually says
Three symptoms keep showing up at Moroccan SMEs whose app is three to five years old: a store rating that slides and never recovers, a screen that renders badly since the latest Android release, and users who install, open once and vanish. They tend to arrive together, and that is not a calendar coincidence.
Before picking a redesign type, pull five numbers out of the consoles rather than out of a meeting:
- Crash-free session rate and ANR rate, in Play Console and in App Store Connect or your crash reporting tool. Google Play enforces bad behaviour thresholds, above which your listing’s visibility suffers.
- Reviews from the last twelve months, sorted by app version. The rating shown on Play weights recent ratings more heavily, so one bad release leaves a mark that fades slowly.
- Retention at day 1, day 7 and day 30, plus the uninstall rate. That is the difference between “the app looks dated” and “the app is no longer useful”.
- The real shape of your installed base: OS versions, device models, available memory. In Morocco, the share of entry-level Android is large enough that an animation-heavy screen becomes a retention problem, not a cosmetic detail.
- Store listing conversion, views to installs. That one depends on screenshots, icon and description, not on your code.
This takes two or three days of work. It then steers tens of thousands of dirhams of budget.
Reskin, migration, rebuild: three projects that get confused
The interface reskin
Same architecture, same business code, new design system: colours, typography, components, sometimes navigation. It assumes the current codebase compiles, ships, and sits on dependencies that are still maintained. Expect four to eight weeks on a fifteen to twenty screen app. This is the only one of the three scenarios where the word “reskin” is honest.
The framework migration
Two native codebases merged into one Flutter codebase, an old Cordova or Ionic project rebuilt in React Native, or a major version jump that forces an internal architecture rework. The backend stays, the business logic is rewritten, the UI gets redone along the way because reproducing the old one pixel for pixel would be absurd. Three to six months, with the risk concentrated on data and integrations, not on design.
The full rebuild
New data model, new APIs, often new authentication and a new payment flow. You keep the name, the users and the store listing; everything else changes. Five to nine months depending on scope. If someone offers this in six weeks, the scope was not read.
Mistake 1: redesigning before you know why people uninstall
A visual redesign is the easiest thing to sell and the easiest thing to approve in a steering committee, because everybody has an opinion about a mockup. The trouble is that the reason users leave is rarely visual. In the apps I have audited, it usually sat in login (an SMS OTP that arrives late or not at all), in startup time on a modest device, in behaviour on an unstable network, or in a payment that fails one time in five with no clear message.
The fix is cheap: read one to two hundred recent reviews by hand, group them by reason, and cross-check against your analytics funnel. Suppose an ordering app shows 62% of its one-star reviews on the theme “I never get the verification code”. A new brand guideline will not move that curve by a single point. Redesigning the interface is almost always defensible eventually. Doing it first, rarely.
Mistake 2: migrating to Flutter or React Native without auditing existing data
A technical migration gets prepared on the server side, and it breaks on the device side. Your users have things on their phone: a local SQLite, Room or Realm database, preferences, an auth token in the Keychain or Keystore, a queue of offline actions, downloaded files, an order history they can read without a connection.
If the new version ships with a different local schema and no migration path, the user who updates reopens the app logged out, with an empty history and a lost basket. What you get within forty-eight hours is a wave of one-star reviews on the release you just shipped, at the precise moment you needed a good rating.
Inventory this before anyone prices the work: local database schema and migration script, token format and session renewal, deep link and universal link configuration, push notification tokens, analytics identifiers, and the consents already collected. That last one is not cosmetic. If the migration changes the embedded SDKs, the permissions you request and the parties receiving the data change too, which brings you back to the duties covered in our piece on app permissions and SDKs under CNDP rules.
Acceptance testing has to follow the real upgrade path: install the published store version, use it, then install the new build on top. Testing the new build on a clean phone proves nothing. And if the target stack is still open, settle it before scoping rather than during, using the criteria in our native versus Flutter guide.
Mistake 3: changing the bundle ID or the developer account
This is the expensive one, because it cannot be undone. The bundle identifier on iOS and the applicationId on Android cannot be changed once the app is published. If your new provider ships under a new identifier, you have not updated your app: you have created a second one. Zero reviews, zero rating, no download history, no age signal for ranking, and your existing users keeping an app on their phone that nobody will ever update again. The deep links in your SMS and email campaigns still point at the old listing. Three years of accumulated ratings leave with it.
The same trap exists at account level. Plenty of Moroccan apps were published under the provider’s developer account, with the Android keystore kept on their side. As long as the relationship is good, nobody notices. On the day you switch, you discover the listing is not yours. Apple and Google both offer an official app transfer process between accounts, subject to conditions: that is the route to take, not a republication. We covered the mechanics of that kind of handover in our guide on switching IT provider without losing your code.
Check all of this before you sign anything: the Apple Developer account is in your company’s name, so is the Google Play account, you have access to app signing (or the keystore), and the quote states in writing that the bundle identifier stays unchanged. Also plan a minimum supported version and a forced-update screen, or you will maintain two APIs for two years.
What a mobile app redesign Morocco really costs in 2026
The ranges below reflect what the Casablanca and Rabat market looks like, before tax, for a team of two to four people and an app of average complexity (fifteen to twenty-five screens, authentication, business APIs, notifications). They move fast with scope, so treat them as a way to frame a conversation, not as a substitute for a quote.
- Pre-project audit (code, dependencies, local data, accounts and store listings, analytics): MAD 15,000 to 35,000, one to two weeks.
- Interface reskin on a healthy codebase: MAD 50,000 to 120,000.
- Framework migration including local data migration and integrations: MAD 180,000 to 450,000.
- Full mobile app rebuild, backend included: rarely below MAD 350,000, often MAD 500,000 to 900,000.
- After launch: 15% to 25% of the build cost per year simply to stay publishable, depending on the service level you expect.
A quote that prices “the redesign” without saying which of the three categories it covers is not a quote, it is an intention. The lines most often missing, and most expensive later: local data migration, the forced-update plan, testing on older Android devices, acceptance testing of the upgrade path, and carrying over the store listings. If you want to modernise a mobile app in Morocco without signing a blank cheque, ask for those five lines explicitly and compare the answers instead of the totals.
The three-question test before you start
First question: does the current codebase compile and publish today, with no workarounds? The way to find out is not to ask, it is to have a signed build produced and a minor update submitted to both stores. If it clears in a few days, your project is probably a reskin. If it jams on dependencies, you are in a migration and the budget moves category.
Second question: who owns the accounts, the signing keys and the bundle identifier? Until the answer is “we do”, no redesign should start.
Third question: what is actually driving users away, measured rather than assumed? If you cannot answer all three, what you need to buy is not a redesign but a two-week audit, which costs about one sprint and saves you from wasting six. It is also the right moment to decide who will own maintenance after delivery, because that choice shapes the architecture you pick.
At Arrowlancer we start mobile app work (iOS/Android, Flutter/React Native) with that audit, then price the project in its real category: reskin, migration or rebuild, with data migration and store listing preservation inside the scope rather than outside it. You can see the full range of our services, and if your app is three to five years old and the ratings are sliding, describe what exists today through the contact form: we will tell you which of the three projects you are holding before we talk about price.