Dating App Development Company: The 2026 Compliance Floor, Costs and Build Plan

Summary. A dating app is no longer a matching algorithm with a chat screen attached. Google Play's Age-Restricted Content and Functionality policy requires any app whose core function is dating or matchmaking to switch on Restrict Minor Access in Play Console, and from 26 August 2026 that same policy extends to anonymous and random chat apps. Turning the switch on has a revenue consequence most founders discover late: users Google determines to be under 18 keep the installed app but cannot renew an existing subscription or make a new purchase. Apple moved in parallel, blocking 18+ downloads in Australia, Brazil and Singapore from 24 February 2026 unless the buyer is confirmed as an adult. In the UK, Ofcom's guidance rules out self-declared age entirely, with penalties up to £18 million or 10% of global revenue. The economics are equally unforgiving: Match Group reported $853 million of Q2 2026 revenue against 13.25 million payers, and store and payment costs sit inside a cost of revenue line running at 24% of sales. Build the age, moderation and billing layers first. Everything else is a feature.

The compliance floor you have to clear before the first screen

Most dating app briefs start with the swipe mechanic. That is the wrong order. Both stores now gate distribution on a set of controls that touch identity, payments and content storage, and none of them can be bolted on after launch without a re-architecture.

Google Play's Age-Restricted Content and Functionality policy names two categories that must use Play Console's tools to block minors: real-money gambling apps, and apps whose core functionality is to facilitate matchmaking or dating. The July 2026 policy preview adds two more from 26 August 2026: apps that randomly connect strangers, and apps built for anonymous communication where a user's identity is deliberately hidden. If your product roadmap includes an anonymous icebreaker mode or a roulette-style discovery feature, it lands in the same bucket as the dating core.

The distinction that matters commercially is core versus incidental. Google's guidance for apps with incidental dating or matchmaking features says the policy may not apply where dating is not the core function, provided the app implements age-gating safeguards for those specific features. Google does not mandate a technology. It does say the mechanism must reasonably prevent minors from reaching the age-restricted functionality, and that simple age gates which are easily circumvented may not be considered reasonable. That sentence is the whole engineering brief for a marketplace, gaming or community app that wants a matchmaking feature without becoming a dating app in policy terms.

Restrict Minor Access itself is blunt. Play Console's target audience documentation explains that you enable it by selecting "18 and over" as your app's only target age group, then checking the restriction box. Minors are determined from the age on the Google Account or when Google's systems indicate a user may be under 18. Users already on the app keep using it, but cannot renew existing subscriptions or make new purchases. For a subscription business, a false positive on age classification is silent churn, not a support ticket. Google also warns that certain developer accounts and app categories face extended reviews of seven days or longer, so a release train that assumes a two-day review will slip.

Apple's route is different and, for a global launch, additive rather than alternative. On 24 February 2026 Apple announced that it will block users in Australia, Brazil and Singapore from downloading 18+ apps unless they have been confirmed as adults, with the App Store performing that check automatically. Apple was explicit that developers may still have separate obligations to confirm adulthood independently, and pointed at the Declared Age Range API, now in beta on iOS, iPadOS and macOS, which returns an age category plus a signal about the method of age assurance used. For new Apple Accounts, age categories are shared with the developer's app on request from 6 May 2026 in Utah and 1 July 2026 in Louisiana.

Then there is Apple's content rule. App Review Guideline 1.2 requires any app with user-generated content to ship four things: a filter for objectionable material, a reporting mechanism with timely responses, the ability to block abusive users, and published contact information. The same guideline states that apps used primarily for pornographic content, Chatroulette-style experiences, random or anonymous chat, or the objectification of real people through hot-or-not voting do not belong on the App Store and may be removed without notice. A "rate this profile" leaderboard is a product idea that reads well in a pitch deck and gets an app pulled.

The UK sets the accuracy bar, and self-declaration fails it

Ofcom's industry guidance, published 16 January 2025, defines what counts as highly effective age assurance under the Online Safety Act 2023. Four criteria apply: the method must be technically accurate, reliable, fair and hard to work around. Ofcom lists methods capable of meeting that bar, including open banking, photo ID matching, facial age estimation, mobile network operator age checks, credit card checks, digital identity services and email-based age estimation. It then rules out two things by name: self-declaration of age, and online payments that do not require the payer to be 18.

That second exclusion catches a pattern a lot of apps rely on. If your only adult signal is that someone completed a purchase, you do not have an age check. Ofcom's Chief Executive Melanie Dawes put the pre-2025 status quo plainly: "For too long, many online services which allow porn and other harmful material have ignored the fact that children are accessing their services. Either they don't ask or, when they do, the checks are minimal and easy to avoid."

Dating apps are classified as user-to-user services under the Act, which is why the July 2025 deadline applied to them alongside social platforms, with maximum penalties of £18 million or 10% of qualifying worldwide revenue, whichever is greater, as reported by Global Dating Insights. For an early-stage app the £18 million floor is the operative number, not the percentage.

The design consequence is that age assurance becomes a vendor integration with a fallback chain, not a form field. You will run at least two methods, because facial age estimation degrades near the 18 boundary and document checks fail for users without ID. You will store the outcome, not the evidence. And you will need a re-verification policy, because an age signal captured at signup ages with the account.

What a dating app actually costs to run

Store fees and moderation are the two line items founders underestimate. The fee side changed materially in 2026. Google separated its service fee from its billing fee starting 30 June 2026 in the United States, the European Economic Area and the United Kingdom. The service fee starts at 10% on the first $1 million of annual earnings and applies to all auto-renewing subscriptions regardless of which billing system you use. Where you use Google Play's billing, an additional 5% billing fee applies in those three regions, which lands most subscription apps at an effective 15%. Route the payment through alternative billing or an external web link and the billing fee does not apply, though you take on tax, chargeback and dunning yourself across the markets you serve. We covered the arithmetic in detail in our breakdown of the Google Play service fee split.

The revenue side is where the category's difficulty shows. Match Group's Q2 2026 results, published 4 August 2026, report total revenue of $853 million, down 1% year over year, on 13.25 million payers, down 6%. Revenue per payer rose 6% to $21.13. Cost of revenue was $204.3 million, or 24% of revenue, improved from 28% a year earlier. Product development ran at 13% of revenue and selling and marketing at 19%.

Read those four percentages together and the model is clear. Roughly a quarter of every subscription rupee or dollar leaves before engineering is paid, and paid acquisition costs more than the product team. A dating app that cannot grow organically does not have a cost problem, it has a distribution problem.

Tinder's daily active users fell 4% year over year in Q2 2026, which Match Group described as its best result in ten quarters. Hinge grew revenue 22% year over year with monthly active users up 13%, and Match Group expects it to reach $1 billion of revenue in 2027. During the Tinder Events pilot in Los Angeles, 71% of eligible active users aged 18 to 24 engaged with the in-app Events tab. The pattern across both brands is that engagement now comes from structured, real-world formats rather than more matching throughput.

What we build

We build dating, matchmaking and community products as a compliance-shaped system rather than a feature list. In practice that means five subsystems, each with its own data boundary.

Identity and age assurance sits first: signup, a multi-method age check with a documented fallback chain, storage of outcomes rather than raw documents, and a re-verification schedule. Matching and discovery comes second, built as a ranked retrieval service so the ranking logic can change without touching the app. Messaging is third, with delivery guarantees, media scanning before a photo ever reaches another user, and rate limits that make bulk harassment expensive. Trust and safety is fourth, and it is a product with its own interface: report intake, queue triage, reviewer tooling, appeal handling and an audit log. Billing is fifth, abstracted behind one interface so a market can move between store billing and alternative billing without a rewrite.

We also build the operational surface most briefs leave out. Account deletion that genuinely removes matched-pair data. Export tooling for data subject requests. A moderation dashboard your safety team can actually staff. Region-aware feature flags, because the store rules now differ by country and you will need to turn a feature off in one market without shipping a new binary.

How we run the build

One, a discovery sprint that ends in a policy map. We work through the store policies and the regulatory regimes for your launch markets and produce a written map of which rules bind you, which are advisory, and which features they eliminate. This is where a hot-or-not leaderboard or an anonymous mode gets caught, while it is still a slide.

Two, architecture and threat modelling. Data boundaries, retention schedules, the age assurance vendor shortlist and the abuse cases. Dating products attract catfishing, sextortion and coordinated harassment, and each needs a detection path before launch, not after the first incident.

Three, build in vertical slices. Each slice ships identity, matching, messaging, safety and billing far enough to be exercised end to end. Safety tooling is built alongside the feature it moderates, never in a later phase.

Four, store readiness. Age rating questionnaires, target audience declarations, data safety forms and the Restrict Minor Access decision, plus a submission dry run that assumes a seven-day extended review rather than a two-day one.

Five, launch and operate. Moderation runbooks, on-call for safety incidents, a monthly policy watch against both stores' announcement feeds, and instrumentation that separates age-restriction churn from ordinary churn so you can see the difference.

The stack

Flutter or React Native where one team should serve both platforms and the interface is largely standard; native Swift and Kotlin where camera, liveness and background delivery behaviour matter enough to justify two codebases. Our comparison of React Native app development and Flutter app development covers the trade-off in more depth.

On the server: a ranked retrieval service for discovery, an event-driven messaging tier, object storage with pre-delivery media scanning, and a separate moderation service so safety tooling can be deployed on its own cadence. We design the data layer around regional residency from the start rather than retrofitting it, which is the change most teams find expensive later.

India-specific considerations

Indian dating products face the same store rules on the same dates. Restrict Minor Access is a store-wide setting, not a per-market one, so a decision taken for a UK or Australian launch propagates to your Indian users too.

The Digital Personal Data Protection Act 2023 is the local overlay, and a dating app is close to the worst case for it: the data is sensitive, the processing is consent-based, and deletion requests involve records that describe two people at once. Our DPDP Act engineering playbook sets out how consent capture, retention and erasure translate into schema decisions. The practical point for a matching product is that a match record, a conversation and a shared photo cannot all be deleted on one party's request without a rule about whose data it is, and that rule belongs in the design, not in a support macro.

Payments are the other divergence. Google's separated service and billing fee structure launched first in the United States, the EEA and the United Kingdom, with other markets on a staggered schedule, so an India-first app should model store billing at the standard rate and treat any reduction as upside rather than plan. Pricing also behaves differently: Indian subscription products generally convert on shorter durations and lower price points than the $21.13 monthly revenue per payer Match Group reports globally, which changes the payback maths on paid acquisition rather than the cost structure.

Why eCorpIT

eCorp Information Technologies Private Limited has built mobile and platform products from Gurugram since 2021. We are CMMI Level 5 appraised, MSME certified and ISO 27001:2022 certified, and we hold partnerships with AWS, Microsoft, Google, Shopify and Kaspersky. Teams are senior-led and multi-disciplinary, so the person deciding your age assurance fallback chain is the person who will implement it.

On engagement, we work three ways. A fixed-scope discovery and architecture engagement, delivered in weeks, produces the policy map, the threat model and a costed build plan, and is deliberately separable so you can take it elsewhere. A dedicated squad on a monthly retainer covers the build and the first operating quarter. An outcome-based arrangement covers a defined milestone such as store approval in a named set of markets. We quote after discovery, because a dating app's cost is set by how many age assurance methods and how many jurisdictions you need, and no honest number exists before those are known.

We also design against frameworks rather than claiming certification we do not hold. We build applications aligned with DPDP, GDPR and Online Safety Act requirements. The audits are yours; the architecture that makes them survivable is ours.

FAQ

Does every dating app have to enable Restrict Minor Access on Google Play?

Apps whose core functionality is to facilitate matchmaking or dating must use Play Console's tools to block minors. Apps where dating is only an incidental feature are exempt, provided they implement age-gating safeguards that reasonably prevent minors from reaching those specific features rather than a gate that is easily circumvented.

What happens to existing subscribers when Restrict Minor Access is switched on?

Users Google determines to be under 18 keep the app they already installed and can continue using it. They cannot renew an existing subscription or make a new purchase, and they cannot search for or download the app. For a subscription business this shows up as silent churn rather than as support tickets.

Is a birthday field enough to meet UK age assurance rules?

No. Ofcom's guidance states that self-declaration of age is not capable of being highly effective, and neither are online payments that do not require the payer to be 18. Methods Ofcom lists as capable include open banking, photo ID matching, facial age estimation, mobile network operator checks and digital identity services.

How does Apple's Declared Age Range API change the build?

The API, in beta on iOS, iPadOS and macOS, returns a user's age category plus a signal about the method of age assurance used, subject to user or guardian consent. It gives you an age signal without handling birthdates. Apple states developers may still hold separate obligations to confirm adulthood independently.

What does a dating app pay Google Play on subscriptions?

From 30 June 2026 in the United States, the EEA and the United Kingdom, Google's service fee starts at 10% on the first $1 million of annual earnings and applies to all auto-renewing subscriptions. Using Google Play's billing adds a 5% billing fee, giving most subscription apps an effective 15%.

Which features get a dating app removed from the App Store?

Apple's Guideline 1.2 states that apps used primarily for pornographic content, Chatroulette-style experiences, random or anonymous chat, objectification of real people through hot-or-not voting, physical threats or bullying may be removed without notice. Apps must also ship content filtering, reporting, user blocking and published contact information.

How long should we budget for store review?

Google warns that certain developer accounts and app categories face extended reviews that can take seven days or longer in exceptional cases, and recommends planning around it. Dating apps sit in a category that draws extra scrutiny, so a release schedule assuming a two-day turnaround will slip at the worst possible moment.

Does DPDP change how a matching product stores data?

It changes deletion and retention more than collection. A match record, a conversation and shared media describe two people at once, so an erasure request needs a documented rule about whose data each artefact is. That rule belongs in the schema and the retention policy, not in a support process written after launch.

How eCorpIT can help

We build dating, matchmaking and community products where the age assurance, moderation and billing layers are designed first and the matching experience is built on top of them. That order is what keeps an app in the stores after the 26 August 2026 policy change and through the UK and Australian regimes already in force. If you are scoping a new product or repairing one that failed review, our discovery engagement produces a policy map, a threat model and a costed build plan you can act on with or without us. Tell us your launch markets and your timeline at /contact-us/ and we will tell you what the rules eliminate before you spend a sprint on it.

For related builds, see our work on on-demand app development and fintech app development, or start from the mobile app development company in India overview.

References

1. Age-Restricted Content and Functionality, Play Console Help, Google.
2. Preview: Age-Restricted Content and Functionality, Play Console Help, Google, effective 26 August 2026.
3. Requirements for apps with incidental dating or matchmaking features, Play Console Help, Google.
4. Manage target audience and app content settings, Play Console Help, Google.
5. Age requirements for apps distributed in Brazil, Australia, Singapore, Utah, and Louisiana, Apple Developer News, 24 February 2026.
6. App Review Guidelines, Apple Developer, Guideline 1.2 on user-generated content.
7. Age checks to protect children online, Ofcom, 16 January 2025.
8. Ofcom Mandates Stricter Age Verification for Dating Apps, Global Dating Insights, 17 January 2025.
9. Match Group Announces Second Quarter Results, Match Group investor relations, 4 August 2026.
10. Expanded billing choice and lower fees on Google Play, Android Developers Blog, 24 June 2026.
11. Google Play 2026 fees: what your app actually pays, eCorpIT.
12. DPDP Act engineering playbook for Indian startups, eCorpIT.

Last updated: 15 August 2026.