How to Rewrite a Live Dating App Without Losing Members or Subscriptions

You can replace the code behind a live dating app without a reset, as long as members find their profiles, credits and subscriptions waiting when they open the new version. Four rules get you there. Rebuild what exists before adding anything new. Replace the billing system instead of patching it. Move members in bulk before launch, with clear first-login rules. And treat app store review as part of the plan, not the last step.

We did this for HealthyNikah, a UK Muslim marriage app. It ran on an old Ionic and Angular codebase with billing bugs. We rebuilt it in Flutter, moved more than 3,200 members with their profiles and match credits, and relaunched it on the App Store and Google Play on 2 June 2026 (HealthyNikah case study).

When to rewrite instead of patching

A rewrite is expensive, so it needs a clear reason. HealthyNikah had several:

• No tests, so every fix could break something else.
• No monitoring, so errors weren’t tracked.
• No automated releases, so every update was manual work.
• No safe place for keys and secrets.
• A custom subscription system that kept breaking and charged some members twice.

Any one of these can be fixed in place. All of them together, on a product that takes payments, made a rebuild the better choice.

If you’re not sure which side you’re on, start with a code audit. An outside team reads the code and tells you what can be saved. That’s how our software project rescue work starts, and it’s a cheap way to avoid a rewrite you don’t need. If your current team is leaving, read what you need to know when replacing your development team first.

Rule 1: rebuild what exists, and park new ideas

The first decision on HealthyNikah was to rebuild the current app properly before anything else. New ideas waited until after the relaunch.

This sounds obvious and is hard to stick to. A rewrite feels like the moment to add the features you’ve wanted for a year. But every new feature adds unknowns to a project that already has plenty, and members judge the relaunch on whether their app still works. Keep a list of new ideas and open it the week after launch.

Choose a stack you can hire for and test

HealthyNikah moved from Ionic and Angular to a single Flutter codebase for iPhone and Android. The two tools work differently. Ionic apps are built with web technology (HTML, CSS and JavaScript) and shown inside the phone’s web view (Ionic docs). Flutter apps are written in Dart, compiled to machine code for release, and Flutter draws its own interface instead of using the system’s controls (Flutter docs).

Both can work. What matters in a rewrite is that the new stack has tests, monitoring and automated releases from the first week, and that you can hire people for it later. React Native is the other common choice. We used it for Traza’s booking app, and we compare the two in adding a mobile app to a web marketplace.

The backend moved too. HealthyNikah now runs on NestJS and MongoDB in the client’s own AWS account, and we fixed what a security audit found. If your backend sits in a contractor’s cloud account, a rewrite is the time to move it to yours.

Rule 2: replace the billing system, don’t patch it

Billing needs the most care in a rewrite, because a mistake takes members’ money. HealthyNikah’s custom subscription system had broken more than once, so we stopped patching it. Payments moved to RevenueCat, connected to Apple and Google in-app purchases, with Stripe for payments outside the stores. That ended the recurring billing bugs. The new subscription flow was tested and worked at launch.

How to move existing subscribers to RevenueCat

RevenueCat’s docs describe two ways to bring existing subscribers over (RevenueCat, migrating existing subscriptions):

• Server-side import. You send the store receipts or purchase tokens you already have to RevenueCat, and it creates each customer and keeps the subscription up to date. RevenueCat prefers this whenever possible, because it records subscribers even if they never open the new app.
• Client-side sync. The new app version syncs a member’s purchases when they open it. This is the fallback when you don’t have stored receipts. Its weak spot: RevenueCat only sees members who open the latest version.

Set up forwarding of new purchases first, then import the old ones. RevenueCat removes duplicates. Note that Google Play receipts that expired more than 60 days ago can’t be imported, so old history may have gaps.

Keep the store side the same

Ship the rewrite as an update to the same App Store and Google Play listings, with the same product IDs. Store subscriptions are set up per app in App Store Connect and Google Play Console, so a brand-new listing starts with no subscribers. If you also take payments on the web through Stripe, those subscriptions live in your Stripe account, and you match them to members by account.

Then test the paths members will hit in the first week: renewals, upgrades, downgrades, cancellations, refunds and “restore purchases”, on real devices.

Rule 3: move members without a reset

The relaunch had to feel like an upgrade. HealthyNikah’s members were kept in spreadsheets, so we moved them over in bulk and set four rules for their first login:

Rule	What members saw	Why it helps
Profiles filled in	Their details already in place	Nobody has to sign up again
Credits kept	Unused match credits moved with them	Nobody loses money they already spent
First month free	For members who were already paying	A thank-you while the new billing takes over
Log in to activate	A moved profile stays out of the feed until its owner signs in	Nobody sends a request to someone who hasn’t seen the new app yet

The last rule is the easiest to forget. Without it, active members would see profiles that look live but have nobody behind them yet.

Tell members before launch what’s changing, what stays the same and what they need to do, so the first day isn’t spent answering “where’s my profile?”

Rule 4: plan for app review from day one

A rewritten app goes through review like a new one, and the rules may have changed since your last release. HealthyNikah hit this. Apple first rejected the new build as one more dating app in a crowded category, even though an earlier version had passed. Guideline 4.3(b) names dating among app types Apple won’t accept more of unless they offer “a meaningfully different or improved experience” (Apple App Review Guidelines).

We removed the dating language, appealed to Apple and sent a new build. The guardian consent feature passed review on the way, and the app was approved on 29 May 2026, four days before the public relaunch. Before launch we also held separate sessions with the client on payments and on store approval.

Apple reviews 90% of submissions within 48 hours (Apple App Review). A rejection and an appeal take longer. Submit early.

How the work ran

We worked in sprints and ended each one with a live demo, so the client watched the app grow and could change priorities as we went. Design had its own calls. We reworked profile screens into clearer sections, moved search and filters into the main feed, and rewrote onboarding and privacy text with the client. The board lived in Jira, designs and user flows in Figma and Miro.

After launch, we moved to fixed support blocks, so the client pays for fixes and growth one step at a time. Work goes on: activation, pricing, promo codes, referrals and product analytics.

A checklist for your rewrite

1. Get a code audit and decide: fix, partly rebuild, or rewrite.
2. Freeze new features until after the relaunch.
3. Choose a stack with tests, monitoring and automated releases from week one.
4. Move the backend and keys to accounts you own.
5. Replace billing with a proven service and import existing subscribers.
6. Keep the same store listings and product IDs.
7. Move members in bulk with filled profiles, kept credits and a log-in-to-activate rule.
8. Tell members what’s changing before launch.
9. Submit to app review early and plan for a rejection.
10. Agree on how support works after launch.

What a rewrite costs

The old code and the number of members decide the work, so we price rewrites after an audit, not from a feature list. Our rate is $39 to $55 an hour. For comparison, a brand-new focused first version with us costs $5,000 to $15,000 and takes 2 to 4 weeks. Our post on what a dating app costs breaks down where that money goes, and our dating app development page shows the apps we’ve shipped.

FAQ

Can you rewrite an app without losing subscribers?

Yes. Ship the new code as an update to the same store listings with the same product IDs, and import existing purchases into your billing service before launch. RevenueCat prefers a server-side import of stored receipts, because it records subscribers even if they never open the new version.

Should I rewrite my dating app or fix the old code?

Get a code audit first. Rewrite when several problems stack up on code that handles money: no tests, no monitoring, manual releases, exposed keys and billing bugs. HealthyNikah had all of them. If the problems are few and local, fixing in place is cheaper.

How do you move users to a new version of an app?

Move them in bulk before launch so their profiles arrive filled in. Keep anything they paid for, like credits. Hide moved profiles from the feed until their owners log in, so the app doesn’t look full of inactive people. Tell members what’s changing before the switch.

Is Flutter better than Ionic for a dating app?

They work differently. Ionic shows web code inside the phone’s web view, while Flutter compiles to machine code and draws its own interface. HealthyNikah moved from Ionic and Angular to Flutter to get one current codebase for both platforms. Pick the stack your team can test, release and hire for.

What is RevenueCat and why use it in a dating app?

RevenueCat sits between your app and Apple’s and Google’s billing systems. It tracks who paid for what, handles renewals, and can also work with Stripe. HealthyNikah replaced a custom subscription system that charged some members twice with RevenueCat, which ended the recurring billing bugs.

Does a rewritten app go through App Store review again?

Yes, every new build is reviewed, and rules may have changed since your last release. HealthyNikah’s rebuilt app was first rejected under Apple’s dating-category rule, even though an earlier version had passed. It was approved after new positioning, an appeal and a new build.

Find out what your rewrite involves

Tell us what your app does and what’s breaking. Our AI estimate turns it into a scope, a budget range and a timeline in about four minutes.

Estimate my project