iOS Game Store Submission: Avoid These Common Mistakes

Submitting a game to the App Store is straightforward in principle and surprisingly easy to get wrong in practice. Apple rejects a large share of first submissions, and almost all of those rejections come from the same handful of causes: the build crashes, the metadata is incomplete or misleading, the privacy details are wrong, or the game looks like spam. None of these are mysterious — they are predictable, and each has a reliable fix. This guide covers the rejection reasons that catch iOS game developers most often, and what to do about each one before you submit.

The submission process at a glance#

Before the reasons, the shape of the process. To publish an iOS game you need an Apple Developer Program membership ($99 per year), a game built for iOS, an archive uploaded through Xcode to App Store Connect, and a store listing — title, screenshots, description, age rating, and privacy answers. Apple's reviewers then install the build and play it. Most submissions are reviewed within a day or two, but it varies; budget time for at least one review round, and ideally one resubmission, before any hard launch date.

The single best thing you can do is treat submission as the last step of testing, not a separate phase. Every rejection reason below is cheaper to fix in development than in review.

1. Crashes and bugs — the number-one rejection#

Apple's App Review guidelines are explicit that you should test your app for crashes and bugs before submitting, and in practice this is the most common reason a build is sent back. A crash on the reviewer's device — on launch, during a level transition, or on a specific device — is an automatic rejection.

The fix is to test the actual build you submit, on a real device, not only the simulator. The simulator will not catch memory pressure, GPU driver issues, or problems that only appear on older hardware. Test on the oldest device you support and on the newest, because rejection-causing bugs cluster at the edges. If your game uses an account system, test the login and the first-run flow end to end with a fresh account, because that is exactly the path the reviewer takes.

2. Missing or broken demo account#

If your game requires a login, Apple's reviewers cannot play it without credentials. App Store Connect has a field for a demo account under the review information, and leaving it blank — or filling it with credentials that do not work — is one of the easiest rejections to avoid.

Provide a real, working account. If your game has a tutorial or gated content, make sure the account is past any onboarding that would block a reviewer, and add review notes explaining anything non-obvious, such as how to reach a multiplayer mode. A short, clear note saves a round trip.

3. Incomplete or misleading metadata#

Apple cross-checks your store metadata against the actual app. Common metadata rejections include an incomplete description, screenshots that do not match the current build, keywords stuffed with unrelated terms, or app features claimed in the description that the game does not actually have. If your description promises a multiplayer mode that is not in the build, that is a rejection.

Be literal and honest. Your screenshots should be taken from the build you are submitting, your description should describe what the game does today (not what is coming in a future update), and your keywords should be relevant. Metadata that oversells converts a few extra impressions and earns a rejection.

4. Privacy violations and the privacy manifest#

Privacy is scrutinized harder every year, and it is now one of the most common rejection categories. Two things in particular catch developers.

First, since May 1, 2024, Apple requires a privacy manifest — a PrivacyInfo.xcprivacy file — in every app and update. It declares the data your app collects and which "required reason" APIs it uses, and your third-party SDKs must ship their own manifests. A missing or inaccurate manifest, or an SDK without one, will block the submission. Before you upload, confirm every SDK you depend on provides a manifest and that your own file matches what your code actually does.

Second, you need an accurate set of privacy answers in App Store Connect — the "data collection" labels players see on the store page. If your game collects device identifiers, usage data, or purchases, that has to be declared. A mismatch between your answers and the app's real behavior is a common rejection, and the privacy manifest and the App Store Connect labels have to agree.

5. Missing account deletion#

If your game lets players create an account, Apple requires that it also lets them delete that account and its data from inside the app — not only by emailing support. This rule catches developers who added sign-in for multiplayer or cloud saves but forgot to build the deletion flow. If accounts are part of your game, the deletion option has to be there and it has to work.

6. Guideline 4.3 — the spam rule#

Guideline 4.3 is Apple's catch-all for apps that add little value. For games, it most often rejects titles that are near-duplicates of other apps, are re-skins of the same game published under many names, or look like they were generated in bulk. If you publish a portfolio of similar casual games, 4.3 is the rejection you are most likely to hit.

The fix is to make each game genuinely distinct — different core mechanics and identity, not just different art on the same template. For a single, original game this is rarely an issue; for a studio shipping many similar titles it is the central thing to plan around.

7. Broken links and placeholder content#

Smaller but frequent: a support URL or privacy policy URL that returns a 404, placeholder text left in the description, or "lorem ipsum" assets shipped by mistake. Before you submit, click every link in your listing and open the build looking for anything obviously unfinished. Apple's reviewers check these, and a dead privacy-policy link is a rejection you can fix in five minutes.

A pre-submission checklist#

Run through this before you upload:

• Test the submitted build on a real device, oldest and newest supported.
• Provide a working demo account with review notes for anything non-obvious.
• Confirm screenshots and description match the build, with no future-tense claims.
• Ship a privacy manifest and confirm every SDK has one; match your App Store Connect privacy answers to reality.
• Add account deletion if you have account creation.
• Click every link — support URL, privacy policy, marketing URL.
• Remove placeholder content and unfinished features.
• For a portfolio of games, make sure each is mechanically distinct to avoid 4.3.

Most of these take minutes. Doing them up front is dramatically cheaper than a review round trip.

Where Egmatic fits#

A lot of App Store rejection comes down to device-specific bugs and unfinished flows, and both are easier to catch when you can test continuously. Egmatic is a 2D game editor and engine built on the MonoGame runtime, and it exports to iOS from the same project you develop on desktop. You can run the game on a desktop build throughout development, then build the iOS binary and test on a device before submission — so the crashes and edge cases that cause most rejections are found while you are still building, not after Apple has already looked at it. If you want to understand the wider export picture, our guide to multiplatform game export covers how the same project reaches desktop, mobile, and console.

Conclusion#

App Store rejections feel arbitrary until you see the pattern: they cluster around crashes, incomplete metadata, privacy mistakes, missing account deletion, and the spam guideline. The fixes are unglamorous and reliable — test the real build on real hardware, include a working demo account, ship an accurate privacy manifest, keep your store listing honest, and make each game genuinely distinct. Do those things before you submit and most rejections never happen. Budget a day or two for review, plan for one resubmission, and you will ship a clean iOS game the first time.

---

Sources#

1. Apple's App Review guidelines put testing for crashes and bugs and complete, accurate metadata among the core requirements before submission — App Review Guidelines – Apple Developer
2. Apple requires a PrivacyInfo.xcprivacy privacy manifest for app and third-party SDK submissions since May 1, 2024 — Privacy manifest files – Apple Developer
3. The Apple Developer Program membership required to publish on the App Store costs $99 per year — Apple Developer Program
4. The App Store Small Business Program reduces Apple's commission from 30% to 15% for developers earning up to $1 million in proceeds per year — App Store Small Business Program – Apple Developer
5. Apple requires apps that offer account creation to also offer account deletion from within the app (Guideline 5.1.1) — App Review Guidelines – Apple Developer
6. Guideline 4.3 covers spam, including apps that are near-duplicates or add little value — App Review Guidelines – Apple Developer
7. TestFlight is Apple's beta testing service for distributing pre-release builds before App Store submission — TestFlight – Apple Developer