Building the app was the easy part. Now you're stuck in Play Console declarations, Data Safety forms, API level requirements and review rejection emails that don't explain anything clearly. I handle the entire publishing process — so your app actually goes live.
Google Play has become dramatically stricter. Policy changes in 2025 and 2026 mean apps that would have been accepted last year are now flagged, rejected, or silently held. Here's what's actually happening.
Data Safety forms, content ratings, target audience declarations — every section must be filled in correctly. Missing or inaccurate declarations are the #1 cause of review holds and rejections.
As of August 31, 2026, new apps and updates must target Android 16 (API 36). Apps targeting older versions are blocked or lose visibility. If your app was built recently but with older SDK settings, it will be rejected.
Analytics, ads and crash-reporting SDKs often collect more data than developers realise. If the SDK's behaviour doesn't match the Data Safety form, Google flags "impermissible SDK activity" — a rejection reason that's very hard to self-diagnose.
New personal (individual) developer accounts must run a closed test with at least 12 testers active for 14 consecutive days before applying for production access. Corporate accounts are exempt — but personal accounts must plan this into the timeline.
Google doesn't guarantee review times. New apps, sensitive permissions and declaration changes trigger longer, more careful reviews. Repeated resubmissions restart the clock and make it worse.
"Broken functionality." "Policy violation." "Metadata issue." The emails rarely explain exactly what to fix — so developers guess, resubmit, and get rejected again.
These aren't optional. Every one of them must be completed correctly before Google Play will accept your app. Here's what actually matters in 2026.
Google Play Developer account with $25 one-time fee, two-step verification enabled, and proper account verification. Registration is now enforced — apps not registered under a verified developer are removed.
New apps and updates must target Android 16 (API 36) or higher as of August 31, 2026. Existing apps need Android 15 (API 35) minimum to remain visible to new users. An extension to November 1, 2026 is available if you need more time.
Every app must complete this — even apps that collect no data. It covers data collection, sharing with third parties, security practices, and must match what every SDK in your app actually does at runtime.
Complete Google's content rating questionnaire honestly. Wrong ratings can get your app removed. Most Nigerian business and utility apps rate as "Everyone."
If your app collects any user data — even an email address — a hosted privacy policy URL is mandatory. The URL must resolve correctly in every locale your app supports.
Debug builds are not accepted. You need a properly signed release build in Android App Bundle (AAB) format, with a version code that increments on every update. The signing key must be backed up safely.
512×512 icon, feature graphic (1024×500), at least 2 screenshots (up to 8), short description (80 chars), full description (4000 chars), and a support email address.
New personal developer accounts must run a closed test with at least 12 testers (sometimes enforced at 20) opted in for 14 consecutive days before applying for production access. Corporate accounts are exempt.
These are the rejection categories Google Play uses most often in 2026. Each one has a specific fix.
Crash on launch, ANR on cold start, dead privacy policy URL, or gated content with no test credentials. Reviewers open the app and hit a wall. Fix: test on multiple real devices, provide working credentials, ensure all links resolve.
Store listing describes something the app doesn't actually do, or uses impersonated icons/names. Fix: align the listing exactly with what the release build actually delivers.
A third-party SDK collects data your Data Safety form never declared. This flags behaviour in code you didn't write. Fix: audit all SDK network calls and update declarations to match.
Location, contacts, or foreground services used beyond what the app's declared purpose justifies. Fix: remove unnecessary permissions or provide clear justification in the Console.
App is not registered under a verified developer account. Fix: complete developer verification in Play Console before resubmitting.
An app that was previously live gets removed after a policy re-scan — often triggered by new rules it no longer complies with. Fix: audit your live app against current policies regularly.
You built the app. I get it live. From release build to review approval, every step is handled — including the ones that trip up most developers.
Building the correct AAB release, generating and securely storing the signing key, and configuring Play App Signing so future updates work smoothly.
Creating the app, setting the package name, configuring tracks, and organising the Console so every required section is complete before submission.
Completing the Data Safety form, content rating questionnaire, target audience declaration, and every other required declaration — correctly, and matching your app's actual behaviour.
Writing the short and full descriptions, preparing or reviewing screenshots, feature graphics and icon, and making sure the listing accurately describes the app.
Checking target API level, permissions, SDK behaviour, link integrity, and cold-start stability before hitting submit — so you avoid preventable rejections.
If Google rejects the app, I diagnose the actual reason, fix it, and resubmit with a new version code. No guessing, no blind resubmissions.
Structured, transparent, and paced so you know exactly where things stand at every stage.
You share access to the codebase or the built APK/AAB. I review the app against Play Store requirements: target API level, permissions, SDK activity, signing setup, and store listing readiness. You receive a clear report of what's ready and what needs fixing.
Any issues identified get fixed: API level updated, permissions trimmed, signing configured, release build generated. This is where most apps go from "won't be accepted" to "ready to submit."
App created in Play Console, package name confirmed, store listing drafted, and every required declaration completed — Data Safety, content rating, target audience, privacy policy, and any others that apply.
Cold-start testing on real devices, link integrity checks, and a full walkthrough as a reviewer would experience it. If the app crashes, has broken links, or gates content without credentials, we find it before Google does.
App submitted to the correct track (internal, closed or production). Review status monitored and any questions from Google answered. If rejection happens, the fix is diagnosed and resubmitted.
Once approved, the app is live. You receive documentation on how to manage future updates, where the signing key is stored, and what to check before any future submission.
Publishing from Nigeria follows the same process as anywhere else: create a Google Play Developer account, pay the one-time $25 registration fee, build a release AAB, complete all Play Console declarations (Data Safety, content rating, privacy policy), and submit for review. Nigerian cards and virtual dollar cards both work for the registration fee. The key is completing every declaration correctly before submission — incomplete declarations are the most common cause of review delays and rejections.
The most common rejection reasons include: broken functionality (crash on launch, ANR on cold start), metadata contradicting runtime behaviour, missing or inaccurate Data Safety declarations, impermissible SDK activity, permissions exceeding declared use cases, missing privacy policy URL, and apps that haven't met the current target API level requirement. Each rejection comes with a specific reason in the Play Console — the fix depends on which one applies.
Yes — every app published to Google Play must have a completed Data Safety form, even apps that collect no user data. The form requires you to disclose what data your app collects, whether it shares data with third parties, how it handles data security, and more. Incomplete or inaccurate declarations are one of the most common causes of rejection and retroactive removal. The form covers all SDKs included in your app — including analytics, ads and crash reporting libraries you may not think of as "collecting data".
As of August 31, 2026, all new apps and app updates submitted to Google Play must target Android 16 (API level 36) or higher. Existing apps must target Android 15 (API level 35) or higher to remain available to new users. If your app was built before this date or targets an older API level, it needs updating before it can be published or updated on the Play Store.
If you're using a new personal (individual) Google Play Developer account, yes — Google requires at least 12 testers (sometimes enforced at 20) to opt in and stay active for 14 consecutive days in a closed testing track before you can apply for production access. Corporate/organisation accounts are exempt from this requirement. If you're using a personal account, the testing period must be planned into your launch timeline.
Google charges a one-time $25 registration fee for a Play Console developer account — that's the only fee Google charges to publish, and it covers unlimited apps. Beyond that, the cost depends on what work needs doing: building a release AAB, writing store listings, creating privacy policy, completing declarations, or fixing rejection issues. I quote per project after reviewing your app and understanding what needs to be done.
Tell me what you built, what tools you used, and where you're stuck — rejected, held in review, or not sure where to start. I'll tell you honestly what's needed and what it costs.
Release builds · Declarations · Store listings · Rejection resolution · Nigeria-based, worldwide service