Neither store asks you to report a breach to it. Apple asks you to report it to your users.
That is the first of five things the app store rules do not say. Neither store requires you to notify the store of a data breach. Neither gives your users a right to a copy of their data. Apple publishes no validity period for a distribution certificate. Apple publishes no deadline for appealing a rejection. Google does publish an appeal deadline, 180 days, but only for a terminated developer account, not for a removed app. Each of those is an absence checked by opening the page where the rule would live and reading it on 17 October 2026, and every page is named below. The rules people do read closely are the ones about why apps get rejected.
None of this is a loophole. Four of the five absences mean the duty sits somewhere else: with your own regulator, with your own customers, or in a screen inside your own account. The fifth one, the appeal deadline, means a number that gets repeated as universal is true for exactly one case.
Start hereThe short version
Five silences, and the duty each one pushes somewhere else.
An absence is a harder thing to claim than a rule, so the standard here is higher. For each of the five, the page where the rule would sit was opened and read, and that page is named in the section. All five held. What makes them easy to get wrong is that four of them have a real, documented rule sitting right beside the missing one. Apple does require immediate written notice of a compromised signing key, just not of a customer data breach. Google does publish a 180 day appeal window, for a terminated account and not for a removed app. Both stores do require account deletion in detail, but never an export. And Apple does publish what happens when a certificate expires, just never how long it lasts.
What replaces each gap is usually more demanding than the rule people imagined. Instead of reporting a breach to a store that will file it, you have to tell the people whose data it was. Instead of a certificate lifespan you can plan a year around, you have a date in your own account that only you will look at. The budgeting side of that sits with what it costs to publish an app.
Does either store make you report a data breach to it?
No. The Apple Developer Program License Agreement is the binding document, and its breach clause points the other way. Under section 3.3.3(C), Disclosures to Users, you agree to notify your users, in accordance with applicable law, in the event of a data breach in which user data collected from your application is compromised. Apple's own example is sending your users an email if their data has been unintentionally disclosed or misused. The phrase appears once in the whole agreement, and that is where. There is no clause telling you to notify Apple.
The App Store Review Guidelines do not add one. Guideline 1.6, Data Security, says apps should implement appropriate security measures to ensure proper handling of user information and prevent its unauthorized use, disclosure or access by third parties. That is a duty to protect, not a duty to report. There is one security event you must tell Apple about in writing, and it is not a customer data breach: section 5.1 says you agree to immediately notify Apple in writing if you have any reason to believe there has been a compromise of any of your Apple certificates or keys.
Google is the same shape with less text. Google Play's User Data policy, read on 17 October 2026, does not use the word breach anywhere in the article. It requires you to handle personal and sensitive user data securely, including transmitting it using modern cryptography, and it requires disclosure, consent and a privacy policy. The Google Play Developer Distribution Agreement, effective 15 September 2025, has no breach notification clause either. The one place the User Data policy tells you to notify Google is narrower than a breach: if you cannot meet Google's conditions for EU personal information made available to you by Google under the data privacy frameworks, you must immediately notify [email protected] and take corrective action. That is a notice that you cannot comply, not an incident report.
The practical reading: a breach is a legal event and a customer event, and neither store has made itself a party to it. Your reporting obligations come from the law where your users are, and Apple's clause explicitly defers to it. Build the notification list before you need it, because the people you have to reach are your own.
Apple Developer Program License Agreement, sections 3.3.3(C) and 5.1, read 17 October 2026
Check one
What gets repeated, and what the page says
Pick a claim you have heard. The second box is what the first party page actually says, with the page named so you can go and read it.
What gets repeated
A data breach has to be reported to Apple and to Google, the way you would report it to a regulator.
What the documentation says
Apple's agreement makes you notify your users, not Apple. The phrase data breach appears once in the whole agreement and it points at your users. Google's User Data policy does not use the word breach at all.
Apple Developer Program License Agreement, section 3.3.3(C). Google Play User Data policy. Both read 17 October 2026.
Do the rules give your users a right to a copy of their data?
No, and the gap is clean. The words portability and export do not appear in Apple's Program License Agreement. Google's User Data policy and its account deletion requirements page contain no export, no copy and no download of user data. The only download on the Google page is about not making a user reinstall your app to reach a deletion form. Neither store asks you to hand a user their data.
What both cover instead, in detail, is deletion. Apple's guideline 5.1.1 requires your privacy policy to explain your data retention and deletion policies and to describe how a user can revoke consent or request deletion of their data. Guideline 5.1.1(v) goes further: apps submitted to the App Store that support account creation must also let people initiate deletion of their account within the app, and Apple's own support page on it says offering only to temporarily deactivate or disable an account is insufficient. Deleting the account has to remove the record and the data associated with it that you are not legally required to keep.
Google matches it and adds a surface. The User Data policy requires a readily discoverable option to initiate app account deletion from within your app, requires you to delete the user data associated with that account, and states that temporary deactivation, disabling or freezing does not qualify as account deletion. The Data safety form then asks one question about it: does your app provide a way for users to request deletion of their data. There is no matching question about giving them a copy, and the form has no field for one.
So the honest answer to a customer asking for their data is that the store has nothing to say about it and your law probably does. If you are under a regime with a portability right, build the export yourself and say so in the privacy policy, because the store review will never ask you for it and will never check it. The thing review does check is the deletion path, and it checks that it is inside the app.
How long does an Apple distribution certificate last?
Apple does not publish the answer, which is why you will be told one year by one person and three years by the next. Apple's Certificates overview page in Developer Account Help is the canonical reference. It lists around twenty certificate and key types, from Apple Development and Apple Distribution through to Pass Type ID and Apple Pay, and for each one it says what happens if it expires or is revoked. For an App Store distribution certificate that consequence is that you will no longer be able to upload new apps or updates signed with the expired or revoked certificate to App Store Connect. Nowhere on the page is a lifespan.
The closest Apple comes to a number is strange enough to be worth quoting. The cloud-managed certificates page says a new cloud-managed certificate is automatically created 90 days before expiration when new signing requests are received, and that manual certificate rotation is available once the certificate has less than half of its validity duration left, often 180 days. Apple is describing rotation relative to a validity duration it never states. The one firm period in this corner of the documentation belongs to a provisioning profile rather than a certificate: Developer ID provisioning profiles generated after 22 February 2017 are valid for 18 years from the creation date.
The pages checked for this were the Certificates overview, cloud-managed certificates, Developer ID certificates, enterprise distribution certificates, revoke a certificate, Apple's certificate expiration support page and the Program License Agreement in full, all on 17 October 2026. The expiration support page carries dates only for the intermediate certificate authority, where the renewed Apple Worldwide Developer Relations intermediate expires on 20 February 2030. Section 5 of the agreement covers Apple certificates and their revocation, setting out signing and safekeeping duties with no duration anywhere in it. Apple's certificates support page adds the reason a published lifespan would not settle this on its own: Apple can revoke digital certificates at any time at its sole discretion.
Treat the date in Certificates, Identifiers and Profiles in your own account as the only authority, and put it in a calendar, because nothing will warn you until an upload fails. Distribution certificates belong to the team, not to a person, and only the Account Holder or an Admin can create them, so the renewal is somebody's named job rather than whoever happens to be publishing to the App Store that week. It belongs on the same list as what an app costs to maintain, next to the annual membership renewal.
Is there a deadline for appealing a rejection or a removal?
On the App Store, none is published. Apple's App Review Help page on appealing to the App Review Board, read on 17 October 2026, states no deadline, no time limit and no expected timeline for the board's investigation. It limits the shape of an appeal rather than its timing. Reply to the rejection, removal or termination message in App Store Connect first, and only appeal if that does not settle it. Submit one appeal per rejected or removed app, with one form able to cover up to five apps. The board will message you in App Store Connect when its investigation is complete, and may ask for more information or schedule a call. Do not use an appeal to reinstate a terminated account, to chase a status or to ask for an expedited review.
One limit on that finding, stated plainly because it matters. The appeal form itself opens behind an Apple Account sign-in, so it could not be read. The claim here is that no deadline appears in Apple's public documentation, including the review guidelines, which say only that if you disagree with the outcome of your review you should submit an appeal. It is not a claim that every screen inside App Store Connect has been checked.
On Google Play a deadline does exist, and it is narrower than the way it travels. Google's page on the account termination appeal time limit says that starting 28 January 2026 you must submit your appeal within 180 days of the date your account was terminated, and that after the window ends the matter is considered closed and the option to appeal is no longer available. The 180 days run from the termination date. Terminations before that date had a one time grace period until 27 July 2026, which has passed. If you appeal late in the window and are denied, you automatically get a further 30 days to come back with new information.
That window is for a terminated developer account. It is not for an app. Google's page on an app being removed from Google Play says you may submit one appeal per app removal, suspension or other enforcement action, and gives no deadline. The enforcement process page says enforcement actions remain in effect unless you appeal and the appeal is granted, and gives no deadline either. The clock those pages do publish runs the other way: a warned app is removed after the number of days named in the warning email. So the number to remember is 180 days for a terminated account, and no published window for everything else, on either store.
Google Play Console Help, account termination appeal time limit, read 17 October 2026
The one published appeal window, and everything it does not cover
Read down the first column before you repeat a number. Only one row has a deadline in it, and it is about an account rather than an app.
| What was actioned | App Store | Google Play | Same on both |
|---|---|---|---|
| A submission was rejected | No deadline published | No deadline published | Yes |
| A live app was removed | No deadline published | No deadline published | Yes |
| The developer account was terminated | No deadline published | 180 days from the termination date | No |
| New information after an appeal was denied | Not addressed | An extra 30 days after the decision | No |
| How many appeals you get | One per rejected or removed app | One per removal, suspension or other action | Yes |
Where these gaps land if a builder generated your app
All four of them land on you, because you are the developer of record. The distribution certificate is created inside your Apple Developer account by the Account Holder or an Admin, so the date you cannot look up is in your account and nobody else will watch it. The appeal, if you ever need one, is filed from your App Store Connect. And the breach notice runs to your users, which means it depends on what your app sends off the device, which is a decision you make and not one the tool makes for you.
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, because Apple requires an app built from an app generation service to be submitted by the provider of the app's content, which is you. It is $25 a month and there is no free tier.
The part that actually changes your exposure is where the data goes. A new app starts local first, with its data on the phone, no accounts and no server, and a breach notification duty needs data off the device to be triggered. The moment you ask for sign-in, sync or payments, a backend arrives with a database and file storage, and then you have a notification list, a deletion path to build and a privacy policy to write. The honest limit is that no builder can tell you what your own law requires, and the stores, as this page shows, will not tell you either.
Questions people ask about what the store rules leave out
Not according to their own documents. The Apple Developer Program License Agreement, read on 17 October 2026, says you agree to notify your users, in accordance with applicable law, in the event of a data breach in which user data collected from your application is compromised, and gives sending them an email as the example. The duty runs to your users. The phrase data breach appears once in the whole agreement, in that clause. Google Play's User Data policy does not contain the word breach at all. The Google Play Developer Distribution Agreement, effective 15 September 2025, has no breach notification clause either. Your own law may still require you to report to a regulator, and Apple's clause defers to it.
Build the app, then write down the four dates nobody sends you
Your certificate expiry, your membership renewal, the day you last checked what the app sends off the device, and the address list you would have to email. None of them arrive in your inbox, and three of them are not in any rule book.
Start building