Your iOS App Passed Review. What Should You Keep on File Now?

Guest article by Robert Lynch, Buzko Legal

‍

Once an app is approved, it is easy to stop thinking about App Review. The app is live, customers are paying, and the team has a backlog to work through. Unless another rejection arrives, there may seem to be little reason to revisit it.

Apple’s June 8, 2026 revision to Guideline 4.3(b) is a reason to revisit that assumption. The spam rule now expressly allows removal of certain existing apps if they are not being updated, improved, or attracting customers. Apple names established categories including dating, wallpaper, flashlight, sound-effects, simple-timer, and fortune-telling apps. Its current guidelines also distinguish low-effort categories whose repeated submission can put developer membership at risk.

For a founder, the practical response is fairly modest. Keep a short, current file showing what the app does for customers and how the team maintains it. If a notice arrives, the underlying evidence should already exist.

Start with the rule Apple is actually applying

Apple already had mechanisms for removing existing apps. Its separate App Store Improvements process describes a combination of inactivity and very low downloads, with a 90-day update window for apps identified through that process. Apps that crash on launch can be removed immediately.

But those are not necessarily the standards Apple will apply in every dispute under its spam rule. Guideline 4.3(b) has its own wording. It does not specify a universal minimum customer count or an update schedule that guarantees continued distribution.

My earlier analysis of the June change covers the rule itself. For developers, the more practical question is what they should be able to show Apple if the app’s continued availability is challenged.

Keep a history that explains the product

A list of version numbers is a start. Keep a record of what each meaningful release changed, what was submitted to Apple, and any screenshots or other materials that accompanied the submission. If a dispute develops later, you want to be able to show clearly what Apple reviewed and what changed afterward.

Maintenance can also be important. Fixing a persistent crash or restoring compatibility with an operating-system update may be just as relevant as adding a new feature. Describe the work accurately. A cosmetic change should not be presented as a major product improvement.

Keep that record as the work happens. A short entry identifying the issue, the change, the date, and the supporting materials is usually enough. Trying to reconstruct the review and development history after a termination or removal notice makes an already urgent dispute much harder to assess.

Show what a customer can do with the app

If Apple questions an app’s continued availability, the developer should be able to explain its core functionality clearly and support that explanation with the actual product. Keep screenshots, recordings, or other materials showing the important features and how users interact with them.

That can also help if Apple raises concerns that the app is duplicative, low quality, or has not meaningfully improved. The goal is to give the reviewer a clear picture of what the app does today, rather than relying on general statements about its value or uniqueness.

If the app has changed since an earlier review, keep a record of those changes as well. In our experience, being able to show what Apple previously saw and what the developer changed afterward can become important very quickly once a dispute begins.

Preserve evidence of customer activity

If customer activity is relevant to Apple’s concern, keep records that can support what you say about the app’s users and continued use. That might include downloads, subscriptions, usage data, or other metrics that make sense for the particular product.

The same applies to customer feedback and maintenance. If users identified a problem and the team fixed it, keep enough of that history to show what happened and what changed. The goal is not to overwhelm the reviewer with data, but to be able to support the important factual points in the appeal.

None of these metrics creates an official safe threshold under Guideline 4.3(b). They are useful because they can help show that the app is actively used, maintained, and improved if Apple questions its continued availability.

This is also worth considering when buying an app. In one of our matters, a client acquired an app through Apple’s official transfer process and later faced an account-wide termination after Apple alleged that the acquired app contained prohibited code. The issue put the client’s other apps at risk as well. Before completing a transfer, review the app’s Apple correspondence, review history, code history, and any prior compliance issues. A live App Store listing does not tell you what problems may come with the app.

When a notice arrives, answer the stated concern

Preserve the notice and identify the cited provision, the affected app or account, and the response deadline. Then focus the response on the evidence that addresses Apple’s concern. If a proposed fix changes the product, describe what has already been completed and what still needs to be done.

Ask for clarification when the grounds are unclear. A further submission should give the reviewer something concrete to evaluate. Keep the account’s broader review history in mind, particularly if repeated issues have become part of the platform’s concern.

Buzko Legal’s guide to App Store disputes explains the available internal and legal routes. If an app or account is already at risk, the firm’s platform-disputes team can assess the notice, the evidence, and the timing of a response.

‍

Robert Lynch is a New York-licensed attorney in Buzko Legal’s litigation practice, with experience in App Store and Google Play disputes. Skala is affiliated with Buzko Legal.