Who assigns a Google Play content rating, and can I appeal it?

Separate rating authorities assign it and Google displays it. The page names ESRB for the Americas, PEGI for Europe and the Middle East, USK for Germany, the Australian Classification Board for games in Australia, ClassInd for Brazil, GRAC for games in South Korea, a Google Play Rating for apps in South Korea and for Russia, and an IARC generic rating elsewhere. You answer one questionnaire in Play Console and receive a rating from multiple authorities no matter where you are. Appeals do not go to Google. The page says that if you object to the rating assigned by a participating IARC rating authority, you appeal directly using the link provided in your certificate email. Read 17 October 2026.

Can I charge for a real world service without using the store's billing system?

Yes, and on this one the two stores agree, which is the opposite of what gets repeated. Apple's guideline 3.1.3(e) says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. It is an obligation, not a permission. Google's Payments page says Play's billing system must not be used where payment is primarily for the purchase or rental of physical goods, or for the purchase of physical services, and names transport, cleaning, airfare, gym memberships, food delivery and tickets for live events. Both read 17 October 2026. A booking app for a real appointment takes card payments on both platforms and neither store takes a cut of them.

Does a live one to one session have to use store billing?

Both stores exempt it, on conditions that are not the same. Apple's guideline 3.1.3(d) covers real-time person-to-person services between two individuals, giving tutoring, medical consultations, real estate tours and fitness training as examples, and says one-to-few and one-to-many real-time services must use in-app purchase. Apple's test is the shape of the audience. Google's answer on its own Payments help page adds a condition Apple does not state: a 1:1 online paid service is exempt if the service is between two individuals and the paid service is not available for replay afterwards in any Play-distributed app. Record the session and sell the replay and Google's exemption goes away. The words replay and record do not appear anywhere in Apple's guideline 3.1.3, checked by searching the page on 17 October 2026, so Apple's exemption is silent on recording rather than permissive about it.

What happens if I never update my app's target SDK?

On Google Play your audience shrinks. On the App Store nothing happens until you want to ship. Google's target API level page says that from 31 August 2026 new apps and app updates must target Android 16, API level 36, to be submitted, and separately that existing apps must target Android 15, API level 35, or higher to remain available to new users on devices running a newer Android version. Apps at API level 34 or lower will only be available on devices running Android at the same level or lower. Google says you will be able to request an extension to 1 November 2026, with the extension forms arriving in Play Console later in the year. Apple's Upcoming Requirements page frames its SDK rules as conditions on uploading: since 28 April 2026 apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26 or the matching OS, and since 9 September 2026 iOS and iPadOS uploads must target iOS 13 or later. That page lists no rule that pulls a published app for an old SDK, and Apple's App Store Improvements page, which does remove stale apps, keys on apps that have not been updated within the last three years and fail to meet a minimal download threshold, and names neither SDK nor target OS as a criterion. Both stores confirm that people who already installed the app keep it working. All three pages read 17 October 2026.

Articles · GuidesUpdated October 2026

Apple writes your age rating itself. Google does not, and that is the mildest of four disagreements.

Q: Does my app need a website to satisfy Google Play's account deletion rule?

Yes. Google's User Data policy says users must have a readily discoverable option to initiate app account deletion from within your app and outside of your app, that this must be available both in-app and on an external web resource, and that a link to this web resource must be entered in the designated URL form field within Play Console. Apple's requirement is different in shape. Guideline 5.1.1(v) says that if your app supports account creation you must also offer account deletion within the app, and Apple's account deletion reference page says people must be able to initiate deletion of their account within the app. A website may finish the job, but then the app has to include a link directly to the page where they complete it. That page says nothing about entering a deletion URL anywhere in App Store Connect. Both read 17 October 2026.

Q: Can my app collect donations for a charity?

This is the sharpest difference of the four, and it changes what you build. Apple's guideline 3.2.2(iv) lists, as unacceptable, collecting funds within the app for charities and fundraisers unless you are an approved nonprofit or otherwise permitted under 3.2.1(vi). It adds that apps seeking to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS. Guideline 3.2.1(vi) says approved nonprofits may fundraise directly within their own apps or third-party apps and must offer Apple Pay support. Google's Payments page takes aim at the billing method instead: Play's billing system must not be used where payments include peer-to-peer payments, online auctions and tax exempt donations. It does not push the collection out of the app. So on Android you build a donate screen with your own processor. On iOS you either get nonprofit approval or send people to a browser. Both read 17 October 2026.

One app, one set of honest answers, two different results. Apple generates the rating from your questionnaire. Google hands your answers to independent rating authorities and displays what they send back. The two stores also want different things built for account deletion, draw the line in different places for collecting money on behalf of a charity, and treat an old SDK as two different kinds of problem. Each of those is written down on a first-party page, and this guide quotes each store for its own side only, with the date it was read. Most of this surfaces late, while publishing to the App Store, when the build is already finished.

The fifth thing worth knowing is where they agree. Neither store lets you take its billing system near a real world service. That is the rule most often repeated wrongly, in both directions, and both stores are unusually clear about it.

Start here

The short version

Four rules that are not the same rule and one that is.

Age ratings come from different hands. Apple writes yours. Google passes your answers to outside bodies and shows you what they return. Account deletion needs a public web page on Google Play and does not on the App Store. Charity collection is barred inside an iOS app unless you are an approved nonprofit, while Google simply bars its own billing system from the transaction. And an app you never update loses new installs on Google Play while sitting undisturbed on the App Store.

They do agree about real world goods and services. Apple requires you to use something other than in-app purchase. Google forbids its billing system for the same transactions. If you are pricing out the work, the deletion page and the Android release cadence are the two items that turn into recurring effort rather than a one-off, which is the part of what an app costs to maintain people forget to budget.

Who actually decides your app is rated 12+?

On the App Store, Apple does. Its age ratings reference page, read on 17 October 2026, says Apple generates appropriate ratings based on your answer to the age rating questionnaire. The page on setting a rating puts it the same way: your selections are then translated into an Apple global age rating, as well as additional region-specific ratings if required. You answer questions about content descriptors, in-app controls and capabilities, and Apple turns the frequencies you declare into a number. The global values are 4+, 9+, 13+, 16+ and 18+, with Unrated as a state that cannot be published on the App Store at all.

On Google Play nobody at Google writes it. The content rating requirements page in Play Console Help, read on 17 October 2026, says your app's content ratings are assigned by separate rating authorities and determined by your questionnaire responses, and that because they are independent third parties, each rating authority uses its own methodology to assign ratings. You answer once and receive a rating from multiple authorities no matter where you are, and Google displays it. The page names ESRB for the Americas, PEGI for Europe and the Middle East, USK for Germany, the Australian Classification Board for games in Australia, ClassInd for Brazil and GRAC for games in South Korea, with an IARC generic rating where no local authority takes part.

The practical consequence is a mismatch in the numbers themselves. The IARC generic bands Google publishes are 3+, 7+, 12+, 16+ and 18+. Apple's global values are 4+, 9+, 13+, 16+ and 18+. Only the top two coincide, so below 16+ the number printed on one listing cannot be the number printed on the other. Neither store publishes a crosswalk between the two scales, so do not expect your App Store number to appear on Google Play. Nobody made a mistake. The scales were never the same scale.

Appeals follow the same split. Google's page says that if you object to the rating assigned by a participating IARC rating authority, you appeal directly using the link provided in your certificate email, so the argument is with the authority and not with Google. Apple's route runs through Apple: its page on setting a rating says App Review may contact you if the Korean Games Rating and Administration Committee issues a region-specific rating that differs from your existing one, and you then supply a Rating Classification Number and submit a new version. Those two Apple pages name only Korea's GRAC and Brazil's MJSP as outside bodies. Searching both pages on 17 October 2026 returned no mention of IARC, ESRB, PEGI or USK, which is worth knowing before you assume one rating answers for both stores.

What does each store make you build for account deletion?

Apple wants a button in the app. Guideline 5.1.1(v) says that if your app supports account creation, you must also offer account deletion within the app. Apple's own reference page for that guideline, read on 17 October 2026, is more specific: apps submitted to the App Store that support account creation must also let people initiate deletion of their account within the app, the option should be easy to find and typically sits in account settings, and you have to offer to delete the entire account record along with associated personal data. Only offering to temporarily deactivate or disable an account is insufficient. Apps outside highly regulated industries should not make people phone, email or go through a chat support flow.

A website is allowed to finish the job, but not to be the job. The same page says that if people need to visit a website to finish deleting their account, you include a link directly to the page on your website where they can complete the process. Nothing on that page asks you to register a deletion URL anywhere in App Store Connect. The two mentions of App Store Connect on it are navigation.

Google wants two paths, and one of them is a form field. Its User Data policy, read on 17 October 2026, says users must have a readily discoverable option to initiate app account deletion from within your app and outside of your app, for example by visiting your website, and that this must be available both in-app and on an external web resource. Then the sentence that creates work: a link to this web resource must be entered in the designated URL form field within Play Console. Google also matches Apple on substance, saying temporary account deactivation, disabling or freezing does not qualify as account deletion, and allowing retention for security, fraud prevention or regulatory compliance only if you disclose it.

So the same app needs one more artefact for Android than for iOS: a public page, live before you submit, that a stranger can reach without installing anything. It is a small thing that arrives at a bad time, because it is discovered during submission rather than during the build, and a dead link there is the kind of detail behind why apps get rejected more often than any code problem.

Apple, App Store Review Guidelines, guideline 5.1.1(v), read 17 October 2026

Pick one

What each store says about the same thing

Each side is taken from that store's own page about its own rule, with the date it was read. Nothing here characterises one store from the other's documentation.

App Store

Apple writes the rating itself. Its reference page says Apple generates appropriate ratings based on your answer to the age rating questionnaire. The bands are 4+, 9+, 13+, 16+ and 18+, plus Unrated, which cannot be published.

Apple, age ratings reference, read 17 October 2026

Google Play

Google does not write it. Your answers go to outside bodies: ESRB, PEGI, USK, the Australian Classification Board, ClassInd, GRAC and an IARC generic rating. The generic bands are 3+, 7+, 12+, 16+ and 18+.

Google, content rating requirements, Play Console Help, read 17 October 2026

What you actually have to build

Nothing to build, but expect two different numbers on the two listings. Only 16+ and 18+ line up.

Can you charge for a real world service without store billing?

Yes, and here the two stores agree. Apple's guideline 3.1.3(e), read on 17 October 2026, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. Read it twice: it is an obligation, not a concession. Google is the mirror image. Its Payments page in Play Console Help says Google Play's billing system must not be used where payment is primarily for the purchase or rental of physical goods, giving groceries, clothing, housewares and electronics as examples, or for the purchase of physical services, naming transport, cleaning, airfare, gym memberships, food delivery and tickets for live events.

If you are building a booking app for a salon, a clinic or a trades business, that is the answer, and it is the same answer on both platforms. Neither store takes a cut of a real appointment. The work is a card form or a wallet, which is what adding payments means in practice. The thing to carry away is that a rule can be mandatory in both directions at once: use store billing for a real world service and you are breaking a rule, not saving yourself a step.

Past that point the two sets of words part company. Apple's guideline 3.1.3(d) exempts the purchase of real-time person-to-person services between two individuals, with tutoring, medical consultations, real estate tours and fitness training as examples, and then flips: one-to-few and one-to-many real-time services must use in-app purchase. Apple's test is the shape of the audience. Google's answer on its own Payments help page attaches a second condition instead. A 1:1 online paid service is exempt if the paid service is between two individuals and the paid service is not available for replay afterwards in any Play-distributed app. Sell the recording and the exemption lapses. The words replay and record do not occur anywhere in Apple's 3.1.3, which I checked by searching the guidelines page on 17 October 2026, so Apple is silent on recording rather than relaxed about it, and silence is not permission.

Charity collection is where the two rules stop resembling each other entirely. Apple's guideline 3.2.2(iv) lists as unacceptable the act of collecting funds within the app for charities and fundraisers unless you are an approved nonprofit or otherwise permitted under 3.2.1(vi), and adds that apps seeking to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS. Guideline 3.2.1(vi) says approved nonprofits may fundraise directly within their own apps or third-party apps, must disclose how funds will be used, and must offer Apple Pay support. Google's Payments page targets the method, not the place: Play's billing system must not be used where payments include peer-to-peer payments, online auctions and tax exempt donations. It does not push the collection out of the app. The result is two different builds from one idea. Android gets a donate screen with your own processor. iOS gets nonprofit approval or a link to a browser.

One more asymmetry in the same area, because it decides what your checkout screen may say. Apple's preamble to 3.1.3 states that apps in that section cannot, within the app, encourage users to use a purchasing method other than in-app purchase, except for apps on the United States storefront and as set forth in 3.1.1(a) and 3.1.3(a). The exception is a storefront. Google's Payments page instead points to programmes you enrol in, letting developers offer an alternative billing system within the app or lead users in eligible countries and regions outside the app, provided they enrol. The exception is a sign-up. Same commercial question, two different kinds of door.

Apple, App Store Review Guidelines, guidelines 3.1.3 and 3.2.2, read 17 October 2026

Google, Payments, Play Console Help, read 17 October 2026

Which store can shrink your audience while you do nothing?

Google Play, and the mechanism is not a removal. Its target API level requirements page, read on 17 October 2026, carries two separate rules. The first is a gate on submission: starting 31 August 2026, new apps and app updates must target Android 16, API level 36, or higher to be submitted to Google Play, with lower floors for Wear OS, Android Automotive OS, Android TV and Android XR. The second is the one people miss. Existing apps must target Android 15, API level 35, or higher to remain available to new users on devices running a newer Android version than the app targets. Apps at API level 34 or lower will only be available on devices running Android at the same level or lower. Google says you will be able to request an extension to 1 November 2026 if you need more time, and that the extension forms arrive in Play Console later in the year.

Read that again with a shipped app in mind. You change nothing, you break nothing, and your installable audience narrows every time a new Android version reaches more phones. Google is explicit that people who already installed the app are not affected and can still find, reinstall and use it. The loss is new users on new hardware, which is the quietest possible way to lose them.

Apple's equivalent rules point at the upload instead. Its Upcoming Requirements page, read on 17 October 2026, says that since 28 April 2026 apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26, and that since 9 September 2026 iOS and iPadOS apps uploaded to App Store Connect must target iOS 13 or later. Both are conditions on getting a binary accepted. That page lists no rule that makes an app already on sale unavailable because of the SDK it was built with.

Apple does remove stale apps, but on different grounds. The App Store Improvements page, read on 17 October 2026, says developers with apps that have not been updated within the last three years and that fail to meet a minimal download threshold get a message from App Review and are asked to submit an update within 90 days, after which the app is removed until an update is approved. The criteria are age and downloads. That page does not name SDK version or target OS as a trigger, and it confirms that current users keep a fully functional app. So the honest summary is a difference in kind: on the App Store an old SDK blocks your next release, while on Google Play it erodes your reach without you doing anything at all.

That asymmetry has a practical edge. An iOS-only app can sit still for a year with no visible cost. The same app on Google Play needs a release in the diary, which is why an Android target keeps turning a finished project back into an ongoing one.

The same app, measured by two different rulebooks

The question	App Store	Google Play	Same on both
Who writes the age rating	Apple, from your questionnaire answers	Independent rating authorities, not Google	No
Deletion can live entirely inside the app	Yes	No	No
Store billing banned for a real world service	Yes	Yes	Yes
In-app charity collection allowed	Approved nonprofits only	Yes, but not through Play billing	No
An untouched app loses new installs	No	Yes	No
People who already installed it keep it	Yes	Yes	Yes

Each row is taken from the store's own page about its own rule. The payments row is the one most often reported wrongly, so it is worth reading in the original: Google, Payments, Play Console Help, read 17 October 2026

Where this lands if a builder generated your app

None of it changes because an agent wrote the code. You answer both questionnaires, you own both deletion paths, and on iOS you are the one who presses submit. Guideline 4.2.6 is the reason: apps created from a commercialised template or app generation service are rejected unless submitted directly by the provider of the app's content. The store accounts are yours, so the four disagreements above are yours too.

Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two-way GitHub sync so the code is never trapped. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not submit to the App Store for you, for the reason just given. It is $25 a month, with no free tier.

Two of the four items are ordinary build work and the agent can do them: a delete-my-account screen that really deletes the record, and a card checkout for a real world booking instead of a store purchase. Two are not code. Nobody can answer a rating questionnaire for you, and nobody can get your organisation approved as a nonprofit. Handle those two yourself, early, and the Android release cadence is the only one of the four that keeps asking for your attention after launch.

Questions people ask when the two stores disagree

Usually not, and the reason is structural. Apple writes the rating itself. Its age ratings reference page says Apple generates appropriate ratings based on your answer to the age rating questionnaire, and the page on setting a rating says your selections are then translated into an Apple global age rating, as well as additional region-specific ratings if required. Google does not write yours at all. Its content rating page says your app's content ratings are assigned by separate rating authorities and determined by your questionnaire responses, and that because they are independent third parties, each rating authority uses its own methodology. The bands do not line up either. Apple's global values are 4+, 9+, 13+, 16+ and 18+. The IARC generic bands Google shows where no local authority participates are 3+, 7+, 12+, 16+ and 18+. Only the top two coincide. Both pages read 17 October 2026.

Build it once, then answer each store in its own words

Put the deletion page and the payment method in from the start, read each rule on the store that wrote it, and the two submissions stop being two arguments. Everything else is one codebase.

Start building