App Store审核避坑：加速过审与Google 14天测试要求

The late submitter's guide to getting through app review

Everything you need to get your app approved by App Store review and Play Store review before the Shipaton deadline

At the time of writing, there’s a little less than a month left before the Shipaton deadline. Following conversations in our Discord and on social media, we’ve noticed three groups of developers: some have been stuck in app review despite submitting early; some haven’t submitted yet and are worried they won’t make it; and some are only just starting to build and are considering giving up because they’ve heard reviews can take a long time.

So I decided to write this guide to help you get through app review as quickly as possible. Apple and Google can be unpredictable, but the process is mostly manageable if you do the right things. Even if there’s less than a month left when you read this, don’t give up: mobile apps can ship surprisingly fast. Your app must be publicly available — not just in TestFlight or a Google Play testing track — before submissions close, so review should be your priority. This guide will show you how to reduce your app to a review-ready release, navigate Google Play’s 14-day testing requirement, and avoid preventable delays. If you’re a student, you can skip the stores and enter the Next Gen category with a demo video and public open-source repository instead.

How much time do you actually have?

Shipaton’s submission requirements say that your app must be publicly available — not just in TestFlight or a Google Play testing track — in the US app stores by September 30th at 11:45 pm PDT. Apple also says that it can take up to 24 hours for the app to appear in the App Store, so to be on the safe side, your app should be in stores, with RevenueCat powering an in-app purchase or serving ads through RevenueCat Ads, at least a day or two before the submission period ends.

How does the app review process work?

The next sections will assume some familiarity with the app review process both Apple and Google have for their respective stores. Fear not, we’ll go through the fundamentals here.

To publish your app, you need a developer account. Apple charges $99 per year, while Google Play charges a one-time $25 registration fee. You can enroll as an individual or an organization.

Organization accounts require additional verification, which may include a D-U-N-S number. New personal Google Play accounts also have a testing requirement, which we’ll cover below.

Once you have your account, you need to create your app, provide all the required assets, and bundle your app. After that, you can submit it to different “release tracks”. In Apple’s case, these release tracks are TestFlight and App Store. The first one is meant for testing your app either in private or public beta, and the latter is the actual store release, which allows everyone to download your app (and pay actual money for it).

Google Play offers internal, closed, open, and production tracks. You don’t have to use every testing track. However, some new personal accounts must complete a closed test before applying for production access. More on this below.

When we talk about submitting your app for review, we usually mean the store release tracks. Neither Apple nor Google allow apps into their store before someone from their team has reviewed the app and made sure it's not misleading, buggy, or unsafe for users. This is the part where first-time developers often get stuck. However, by doing the right things, which we go through next, you can make this process more likely to go through without problems.

I have not yet submitted my app for review

Ok take a deep breath, if you’re at this stage with your app, we will need to sprint a little, because our first priority will be to get our app into the review pipeline as soon as possible. To do this we need to strip our app to its core features. I’ve written about how to build a minimum lovable product in an earlier post, but to summarize:

build something that your core users would love, and drop everything else.

Should you ship your first version without in-app purchases?

Comment out the draft features, remove unfinished authentication if the core experience doesn’t need it, and postpone subscriber-only extras. You can also consider submitting a complete free version first and adding monetization in a second submission once the first is approved. This is optional, and it only makes sense if you have enough time for two reviews.

Purchases and subscriptions give reviewers more to check, and missing metadata, unclear instructions, or misconfigured products can cause a rejection. But for the main Shipaton competition, your qualifying version must still be live before the deadline with RevenueCat powering an in-app or web purchase, or serving ads through RevenueCat Ads. If the deadline is close, including monetization in the first submission may be safer than betting on a second review. Whichever route you choose, test your purchases in the platform sandboxes before submitting the monetized version.

Ace Google’s 14-day testing requirement

This requirement applies to personal Play Console accounts created after Nov 13, 2023. Before you can apply for production access, you must run a closed test with at least 12 testers opted in continuously for 14 days.

Start with the earliest functional version of your app. You can keep building while the closed test runs.

Once the 14 days are complete, apply for production access. Google may require additional testing if participation or engagement is insufficient, so encourage testers to use the app and share feedback.

To recruit testers, reach out to your friends and family. If you’re a billionaire in Gotham City, or just someone who doesn’t have family or friends, head to our Shipaton Discord to make use of the #looking-for-google-play-tester channel to recruit people to give your app a try.

My colleague Jaewoong wrote a deeper guide to Google Play’s 14-day testing requirement if you want the full walkthrough.

Make use of TestFlight and testing tracks

Talking of testing, it is good to test your app with a closed or open group of people before submitting the app to stores. This is a great way to gather feedback on your product, but it can also help you catch what an app review might flag: bugs, performance issues, bad copy, and incomplete features. You save the reviewer’s time and have a better feedback loop in your development process.

Another thing, and this is pure speculation, but if I were an app reviewer and needed to review 10 apps a day, I would definitely look at whether any testing was done on the app before it was submitted for review. I would take a TestFlight with 30 active testers as a green flag, and I might review the app first since the expectation is that it is not pure AI slop and my eyes are the first to see it.

Get all your assets ready

Apple and Google both have extensive guidance on how your store submission should look, what assets and things you need (e.g., privacy policy and terms of service documents), and what not to say, for example (mention the word beta, or call your unreleased app the number 1 app for doing anything). Read these carefully, and ingest the information yourself, so that when you start editing your screenshots and app descriptions, you know exactly what is allowed and what is not.

For more detail, read Apple’s common app review issues and our guide to common App Store rejection reasons.

I’m ready to submit / I’ve already submitted my app

This section applies whether you're preparing to submit or your app is already waiting for review.

Before withdrawing a submission, understand what happens. Apple removes it from the review queue, and resubmitting starts the review process over. Apple does not promise to review submissions in the order received.