YesTonite - Shipping an Android dating app to Google Play
How we took the YesTonite dating app from a working web product to a Google Play release: billing, sign-in, push, app links, a 14-day closed test and a release pipeline a small team can run.
Part 4 of the YesTonite series. New here? Start with the main case study: YesTonite - Building a casual dating app for web and Android.
Project snapshot
|
Field |
Detail |
|---|---|
|
Project |
YesTonite Android app |
|
Type |
Client project · Android app and Google Play release |
|
Client |
City Dev, the Netherlands (operator of YesTonite) |
|
Industry |
Online dating and social discovery (18+) |
|
Built |
2026 |
|
Timeline |
About one week to the live web app · Android in Google Play closed testing from mid-October 2026 · closed testing of at least 14 days before production access |
|
Started |
6 October 2026 |
|
Team |
1 CTO, 1 developer, 1 designer |
|
Delivery |
Built end to end by techlead.fit, including the store listing and the tester program |
|
Status |
In Google Play closed testing · public Android launch planned end of October 2026 · iPhone app planned for mid to end of November 2026 |
|
Stack |
Expo SDK 57 · React Native · Expo Router · EAS Build and EAS Update · Google Play Billing · Google sign-in · Firebase Cloud Messaging · Android App Links · Directus 12 backend |
The situation
YesTonite went live on the web first. People could join, chat and go to events at yestonite.com without waiting for any store review.
But a dating app for tonight lives on the phone. Members need a notification when someone writes, a quick way back into the app, and payment the way they are used to on their device.
The next step was Android, with the same features and the same texts as the web app, and a release through Google Play.
The challenge
Building the app was only half of the work. Getting it into Google Play is a project of its own:
-
In-app purchases must go through Google Play Billing, with its own products, prices and subscription rules.
-
Purchases have to be verified on the server, and the same member can also buy on the web.
-
Links in e-mails and invites should open the app, not a browser.
-
A new developer account needs a closed test with at least 12 testers for 14 days before it can publish to everyone.
-
Dating apps go through extra policy review, including child safety.
Decisions before code
Expo and React Native. One TypeScript codebase for Android now and iPhone next, with managed native builds. The team did not need separate Android and iOS specialists.
Same backend, same texts. The app talks to the same Directus backend as the web app and uses the same locale files in 44 languages.
The server decides what a purchase is. The app sends Google's purchase token to the backend. The backend asks Google what was bought and only then credits it. Nothing the app reports is trusted on its own.
Only the permissions the product needs. Approximate location for the feed. No background location, no camera and no microphone permission.
Start the closed test early. The 14-day test was planned as part of the schedule, with a tester program built for it, not left to the week before launch.
How it works
1. Sign in
Members sign in with Google or with e-mail and password. Session tokens are kept in the device's secure storage.
2. Get notified
New messages and event updates arrive as push notifications through Firebase Cloud Messaging. Members can choose whether a notification shows the message or just says there is a new one.
3. Open links in the app
Invite links, confirmation links and partner links on yestonite.com open straight in the app through Android App Links. The website publishes the app's signing fingerprints, for both the Google Play app signing key and the upload key, so Android can verify that the app and the domain belong together.
4. Buy an extra
Chat packs and 24 hours of unlimited new chats are one-time products. Hide my profile is a weekly or monthly subscription. Prices per country match the website, kept in line by a sync script described in part 2 of this series.
5. Stay in sync
Google sends real-time developer notifications through Pub/Sub when a subscription renews, is cancelled or has a payment problem. The backend applies them, and a job every 10 minutes catches anything missed.
The build
Billing. Play purchases go through the same fulfilment path as Stripe payments on the web. Allowances, hidden time, receipts, referral rewards and partner commissions work the same, whichever store the member used. Each purchase carries the member's account ID, so a token bought for one account cannot be redeemed by another. Chat packs are consumed after verification so they can be bought again. Purchases by license testers are recorded at zero, so test runs never show up as revenue.
Builds and updates. EAS builds the app in the cloud with three profiles: development, preview and production. Production builds increase the version code automatically. Over-the-air updates ship JavaScript fixes to installed apps through channels, tied to the app version so an update never lands on a binary it was not built for. A separate development variant installs next to the store app.
Store listing. The eight Play Store screenshots, the feature graphic and the launch images are rendered from code in headless Chrome, using the app's own design tokens, fonts and photos. A change to the listing is a change to a script, not a design file.
Privacy on the device. Screenshots and screen recording are blocked on screens that show other members.
Tester program. A public testers page at yestonite.com collects sign-ups. Each tester gets a short, personal e-mail series:
-
a welcome right after signing up;
-
an invitation with install steps once they are added in Play Console;
-
a reminder after 2 days if they have not created an account yet;
-
a halfway check-in after 7 days;
-
a thank-you after 15 days, with a gift.
Each e-mail is sent once. A tester's status moves from invited to testing automatically when their e-mail shows up as an account. Testers also came through Testers Community, to reach the required number in time.
Release and validation
The release followed Google Play's tracks: internal testing for the team, then closed testing with outside testers for at least 14 days.
-
Purchases and subscriptions were tested with Google Play license testers, through the same server-side verification as real purchases.
-
App Links are verified by Android against the fingerprints the website publishes for both signing keys.
-
Push, Google sign-in and the new-country sign-in check run in the closed test build on testers' own phones.
-
The store listing includes the child safety declaration that Google Play requires for dating apps.
Outcome
The YesTonite Android app is in Google Play closed testing. The public launch is planned for the end of October 2026.
The same codebase is the starting point for the iPhone app, planned for mid to end of November 2026.
What we learned
Plan the closed test like a feature. Fourteen days with at least 12 active testers is a fixed part of the schedule for a new account. A testers page and an automated e-mail series made it predictable.
Verify every purchase on the server. Trusting the app's word about a purchase is the easiest way to give paid features away. Routing Play and Stripe through one fulfilment path also kept the business rules in one place.
App Links need both fingerprints. With Google Play app signing, the key that signs the installed app is not the key you upload with. Publishing both avoids links that work in testing and fail in production.
Web first made Android easier. By the time the app went to testers, the backend, texts and prices had already been used by real people on the web.
Why this is a techlead.fit case study
Many app projects treat the store release as the last step. In practice it has its own requirements, its own review and its own calendar.
For YesTonite we planned those from the start: server-side purchase checks, one fulfilment path for both stores, App Links, a release pipeline with over-the-air updates, and a tester program that fits Google's rules.
Plan the release, not just the build.
Verify on the server.
Automate what repeats.
Test with real people before launch.
The YesTonite series
-
Part 1: YesTonite - Building a casual dating app for web and Android
-
Part 2: Global from day one: 44 languages and regional pricing in 63 countries
-
Part 4: Shipping an Android dating app to Google Play (this post)
-
Part 6: A growth engine without an ad budget, and the first round
Planning a mobile app release?
If you are taking a product into Google Play or the App Store, billing, store policies and testing requirements shape the timeline as much as the code does.
At techlead.fit, we plan the release with you, build the app and the backend it needs, and take it through store review.
Relevant services: CTO Sprint · MVP Build