So your production access got rejected
You did everything right. You set up closed testing, got your 12 testers, waited the 14 days, and submitted your production access request. Then Google sent you an email saying your app isn't ready for production yet.
This is happening to a lot of developers right now. Google has tightened their review process and many apps that would have passed a year ago are now getting sent back.
The good news is that this is fixable. Google tells you why they rejected it (sort of), and you can reapply after making changes. Let's go through what's actually going on and how to get through it.
Why Google rejects production access
Based on what Google has shared and what developers have reported, there are three main reasons apps get rejected:
1. The production access form was not detailed enough
This is the most common reason by far. Google asks you a series of questions about your testing process, the feedback you received, and what changes you made. Most developers treat these like throwaway fields and write one or two sentences per answer. Google wants real detail. If your answers are vague, generic, or too short, they will reject you.
2. No evidence that you updated your app during testing
Google wants to see that you actually used the testing period to improve your app. If you uploaded one build on day 1 and never touched it again for 14 days, that's a red flag. They want to see that you listened to feedback and made changes.
3. Low tester engagement
This one is harder to control. If your testers opted in but never installed the app, or installed it once and never opened it again, Google may consider that insufficient engagement. They want evidence of real testing, not just names on a list.
How to get approved on your next attempt
Here's what to do before you reapply.
Publish at least 2-3 new releases during testing
This is probably the single most important thing you can do. During your 14-day testing period, push at least 2 or 3 updated builds to your closed testing track. You don't need to rebuild the entire app. Small, genuine improvements count:
- Fix a layout issue a tester pointed out
- Add a small UX improvement
- Address a crash from the pre-launch report
- Improve your onboarding flow
Each release should have meaningful release notes. Don't just write "bug fixes." Write something like "Improved navigation flow based on tester feedback, fixed layout overflow on smaller screens, added loading indicator on the main screen."
The point is to show Google a clear timeline: you got feedback, you acted on it, you shipped improvements.
Check your pre-launch report
Google Play Console has a pre-launch report that runs automated tests on your app. You can find it under Testing > Pre-launch report. Go through it and fix as many issues as you can, especially crashes and ANRs (Application Not Responding errors). Try to get the total issue count below 10.
Google can see this report. If it shows dozens of crashes and warnings while you're claiming your app is production-ready, that's not a good look.
Write proper answers on the production access form
This is where most developers fail. Google asks several questions and you need to give real, substantive answers for each one. Here are the key questions and what they're looking for:
"How did you recruit users for your closed test?"
Be specific about your recruitment method. Don't just say "I asked friends." Explain exactly how you found your testers, why you chose that approach, and how many people you recruited. If you used a testing platform like Get12Testers, say so. Google wants to see that you put real effort into finding legitimate testers. Not sure where to find testers? Read our guide on the 12 testers requirement and where to find them.
"How easy was it to recruit testers for your app?"
Be honest here. If it was easy because you used a platform, explain that. If it was hard, explain the challenges and how you overcame them. Mention how long it took to get all testers opted in and whether anyone dropped out during the process.
"Describe the engagement you received from testers during your closed test."
This is where numbers matter. How many feedback submissions did you get? How often did testers use the app? Did engagement stay consistent over the 14 days or drop off? Mention specific metrics: "We received 45 feedback submissions across 5 checkpoints covering 4 core features, with consistent participation throughout the full testing period."
"Provide a summary of the feedback that you received from testers. Include how you collected the feedback."
Give concrete examples. Mention specific bugs that were reported, specific features testers commented on, and specific suggestions they made. Explain how feedback was collected: was it through a structured platform, email, a form, or casual messages? Include sample quotes from testers if you have them, and mention your average tester rating if applicable.
"What changes did you make to your app based on what you learned during your closed test?"
This is the most important question. List actual changes you made to your app based on feedback. Be specific: "We improved the navigation based on tester feedback about the menu being confusing. We fixed a crash on Android 12 devices that was reported by 3 testers. We added a tutorial screen because testers said the onboarding was unclear."
Never say "no changes were needed" or "no bugs were found." Even if your app was working perfectly, mention UX refinements, performance improvements, or design polish you did based on feedback.
"How did you decide that your app is ready for production?"
Talk about your testing coverage, the number of testers, how long they tested, the feedback you addressed, and the stability of your app. Mention how many bugs were found and resolved, your average tester rating, and the fact that testers maintained active participation throughout the full testing cycle. Reference your pre-launch report if the numbers are good.
General rules for the form
- Write at least 250-300 characters per answer. Short answers get rejected.
- Be specific, not generic. "We improved the app based on feedback" means nothing. "We redesigned the settings screen because 4 testers found it confusing" means something.
- Reference real numbers: how many testers, how many feedback submissions, how many builds you pushed, how many bugs you fixed.
- Don't copy-paste the same answer for multiple questions. Each answer should address what's being asked.
What to do differently if you've already been rejected
If this is your second attempt, Google expects you to show improvement. Here's the sequence:
- Don't panic. Getting rejected once is normal. Lots of developers go through this.
- Read Google's rejection email carefully. They usually give a general reason. Pay attention to it.
- Start a new 14-day testing cycle. You'll need to go through the closed testing period again.
- This time, push multiple releases. At minimum 2-3 updated builds with real release notes.
- Collect structured feedback. Don't just have testers use the app. Have them report specific feedback on specific features.
- Fix your pre-launch report issues. Get those numbers down.
- Rewrite your production access form answers from scratch. Don't just tweak the old ones. Write them fresh with more detail and specifics.
Getting real feedback from testers
One problem a lot of developers run into is that their testers don't actually give useful feedback. Your friend saying "looks good" over text message is not what Google wants to see.
Structured feedback makes all the difference. Instead of asking testers "what do you think?", give them specific things to evaluate:
- Can you complete the signup flow? Any issues?
- Try using the search feature. Is it intuitive?
- Use the app for 10 minutes and note anything confusing.
This kind of structured approach gives you real data you can reference in your production access form, and it actually helps you improve your app.
This is one of the things we built into Get12Testers. Every tester goes through 5 feedback checkpoints over the 14-day testing period, and they evaluate each of your app's features individually. By the end, you have detailed, feature-by-feature feedback with bug reports and ratings that you can directly reference when filling out Google's questionnaire. See how the full testing process works for a detailed walkthrough.
The timeline for getting approved
If you're starting fresh or reapplying after a rejection, here's a realistic timeline:
- Day 1: Upload your app to closed testing, start recruiting testers
- Days 1-3: Get all your testers opted in
- Days 3-17: 14-day testing period (push 2-3 updates during this time)
- Day 17: Fill out the production access form with detailed answers
- Days 17-24: Wait for Google's review (typically 3-7 days)
Total: about 3-4 weeks from start to finish.
Don't treat this as a checkbox
The developers who get approved on the first try are the ones who actually use the testing period to improve their app. Google can tell the difference between someone going through the motions and someone who genuinely tested their app and made it better.
Recruit real testers. Collect real feedback. Make real improvements. Write detailed, honest answers on the form. That's it. There's no secret hack or workaround. Google wants quality apps on the Play Store, and the production access form is how they verify that you took the process seriously.
If you're struggling to find testers or collect structured feedback, that's exactly what Get12Testers is built for. You earn credits by testing other developers' apps, then use those credits to get your own app tested by real Android developers who give detailed, checkpoint-based feedback over 14 days. Everything you need to fill out that production access form with confidence. Here's how to get started.
Related reading: