Getting Through Review, on Both Stores
Writing the app is one project. Publishing it is another one, with its own paperwork, its own vocabulary and two separate sets of rules. We run that second project for you, from account enrolment through to the day the listing goes public.
The Accounts Go in Your Name. Every Time.
Some agencies publish client apps under their own developer account. It is faster for them and it is a quiet disaster for you. The developer account is the legal publisher: ratings, reviews, install history, subscribers and payouts all attach to it, and they do not follow the app if you change agencies.
Both stores do allow an app to be transferred between accounts, but transfers come with conditions, they take time, and the moment you need one is usually the moment the relationship has already soured. The way to never need one is to start correctly.
So we open both accounts in your company name in the first week of the project, on your card, with you as the account holder. We are added as team members with the access the work requires, and you can remove that access yourself, without our involvement, on any day you like. The same applies to the repository and the signing keys — see ownership and NDA.
Verification Is the Part That Surprises People
Neither store simply takes a card and lets you publish. Both want to know who you actually are, and on a fresh account that checking is the single most common cause of a slipped launch date.
Company or individual
An organisation account publishes under your business name, which is what customers and partners expect to see. An individual account publishes under a person. Switching later is not a checkbox, so it is worth deciding deliberately at the start rather than picking whichever enrols faster.
Business identity checks
Enrolling as a company means proving the company exists: a recognised business identifier, a legal name and address that match your registration, and someone with authority to accept the agreements. Getting an identifier issued or corrected can take a while, and it blocks everything behind it.
Identity and address
Both platforms now verify the people and organisations behind accounts, and the details you enter may be shown publicly on your listing. Names that do not match documents, or a postal address nobody checks, will stall the process at the least convenient moment.
Agreements to accept
The developer agreements, and separately the paid-apps agreements if you intend to charge for anything. An unaccepted agreement silently prevents a submission from going anywhere, and the error message rarely says so in plain language.
Payments and tax
If you are selling, a payments profile has to exist first: banking details, tax forms and the territories you sell into. This is your finance team, not your developers, which is why we raise it in week one instead of the week of launch.
Account fees
Apple charges an annual membership and Google a one-time registration, both paid by you directly. Amounts and terms change, so we confirm the current figures with you at kickoff rather than quoting numbers that age badly.
Certificates, Profiles and the Keys You Cannot Lose
Code signing is how a store proves a build came from you and has not been tampered with since. It is also where a launch quietly breaks, because the failure messages are cryptic and the consequences of losing a key are permanent.
On iOS
- A distribution certificate belonging to your account, plus provisioning profiles that tie the app, the certificate and its capabilities together
- A bundle identifier chosen once and effectively permanent — changing it later means a different app, with no reviews and no existing users
- Capabilities such as push notifications, sign-in, in-app purchase and background modes enabled explicitly, and matching what the build actually uses
- Push credentials configured for the production environment, which is a classic reason notifications work in testing and die on launch day
On Android
- An upload key that identifies you to Play, with Play holding and managing the signing key that reaches devices
- An application identifier that is equally permanent, and a version code that must always increase
- A keystore that has to be backed up somewhere that is not one laptop, because a lost key on a self-managed setup can mean losing the ability to update the app at all
- A release build uploaded as an app bundle, so Play can tailor the download to each device rather than shipping every variant to everyone
Keys and certificates live in your accounts and in a credential store you control. If you walk away tomorrow, you can still ship — that is the test we hold ourselves to.
What Submission Actually Looks Like, Step by Step
Roughly the order we work in. Several of these run in parallel with the last sprint of development rather than after it.
1 — Accounts opened and verified
Week one of the project, not week fourteen. Both accounts created in your company name, agreements accepted, verification started early so a slow business check never lands on the critical path.
2 — Identifiers and signing set up
Bundle and application identifiers registered, certificates and upload keys created, capabilities enabled, and a signed build installed on a real device to prove the chain works long before it matters.
3 — Listing drafted with you
Name, subtitle, descriptions, category, support and privacy URLs, and the first screenshot set. Drafted by us, edited by you. The name in particular deserves a decision rather than a default, because it is the most valuable text you own.
4 — Beta build to real testers
TestFlight and a Play closed track, with your people and a few real customers on their own handsets. Everything found here is cheaper than the same thing found by a reviewer. This runs alongside our own device testing.
5 — Declarations completed from the code
Privacy disclosures on both stores, age rating questionnaires, export and content declarations, all filled in from what the app and its dependencies genuinely do, then sent to you to approve.
6 — Release build, symbols and notes
The production build assembled and signed, debugging symbols uploaded so crash reports stay readable, release notes written in language a customer would understand, and the demo account tested one final time.
7 — Submitted, with the release held
Sent for review on both stores, configured so approval does not publish anything automatically. Approval and publication are two separate decisions, and keeping them apart is what makes a launch date possible.
8 — Review answered
Questions answered the same day wherever we can. Where a change is genuinely needed we make it, resubmit and tell you the cost in days rather than letting a date slide quietly.
9 — Released, then watched
Published on the agreed date, staged on Android and phased on iOS where the release type allows it, with crash-free rate and store reviews watched closely for the first few days while the rollout widens.
Everything the Stores Ask You to Produce
None of it is difficult. All of it takes longer than anyone plans for, and a missing piece stops the submission dead.
Name and short text
An app name with a hard character limit, plus the subtitle on iOS and the short description on Play. This is the copy that appears in search results, so it is worth writing rather than filling in. More on this in store optimisation.
Long description
Different in both length and tone between the two stores. Apple keeps keywords in a separate hidden field; Play reads your description itself, so the same text should not simply be pasted into both.
Screenshots
Required at specific device sizes on each store, often several sets. They need to be produced from the real app at the right resolutions, and they must not promise features the app does not have.
Icon
Supplied at the exact sizes each store wants, legible at the size it is actually displayed, and free of any store trademark or badge. It is also the asset that is hardest to change quietly later.
Preview video
Optional on both, and genuinely useful for an app whose value is hard to convey in a still. Each store has its own rules on length, capture source and what may appear in the frame.
Category and content
A primary category that decides which charts and browse lists you can appear in, plus the content declarations that follow from what the app does and who it is for.
Support and policy URLs
A support page and a privacy policy that both resolve and both say something real. Dead links here are checked, and they are an easy, embarrassing rejection.
Demo account and notes
Working credentials for anything behind a login, plus a short note to the reviewer explaining any feature that needs context. Missing credentials remain one of the most common first rejections there is.
Privacy and Age Ratings, Answered From the Code
Both stores now require you to declare, in structured form, what your app collects and who it is suitable for. These are compliance statements, not marketing copy, and a mismatch with what the build does is treated seriously.
What the app collects
Apple asks for privacy labels describing collected data, whether it is linked to identity and whether it is used to track. Play asks similar questions in its data safety form, with its own wording and its own categories. We answer both from the code and the dependency list.
Your third-party SDKs count
An analytics, advertising, crash or support SDK collects data on your behalf, and you are the one declaring it. Most inaccurate declarations come from a library nobody audited, which is a good reason to keep the dependency list short in the first place.
Declared reasons for APIs
Apple additionally requires a manifest stating why the app uses certain sensitive system APIs, along with signed manifests from common third-party libraries. Missing or hand-waved reasons come back as a rejection.
Permission purpose strings
Every permission prompt carries a sentence you wrote. Vague text of the kind that says an app needs access to work is a routine rejection. Naming the feature the permission enables is better for review and better for opt-in rates.
Age ratings
Both stores set a rating from a questionnaire about violence, language, gambling, user-generated content, unmoderated chat and similar. Answer it accurately even where a higher rating narrows your audience, because a wrong answer discovered later is a far worse outcome.
Account deletion
If people can create an account in your app, they must be able to delete it from inside the app rather than by emailing support. It is a backend endpoint plus a confirmation flow, and it is forgotten until the rejection arrives.
Store policy moves. We check the current requirements at submission rather than working from what was true on the last project, and the security side of the same ground is covered on security and privacy.
The Two Reviews Are Not the Same Process
People talk about store review as one thing. In practice the two stores behave differently enough that planning for them identically is a mistake.
Apple
A Person Uses Your App
- Human review against a published set of guidelines, typically a day or two once a build is clean
- Feedback arrives as a message you can reply to, often with a screenshot attached
- Judgement calls about design, completeness and business model, not only about code
- An expedited path exists for genuine emergencies and should be saved for them
Automation, Then People
- Automated scanning combined with human checks, with timing that varies more than people expect
- New accounts and sensitive permissions attract longer review and extra questions
- Policy issues can arrive after publication as a warning, a removal or an account-level problem
- Formal appeals exist and are worth using properly rather than resubmitting blindly
Review times are not a promise on either store and both slow around major OS releases and holidays. We plan a buffer and assume one feedback cycle, so a question does not move your date.
What Catches People on a First Submission
Rarely anything clever. Almost always something ordinary that nobody owned.
The reviewer could not get in
No demo credentials, credentials that expired, or a one-time code sent to a phone the reviewer does not have. If sign-in needs a code, there has to be a route through it that does not depend on your device.
A thin wrapper around a website
An app that only loads your existing site, with nothing a browser could not do, gets refused as lacking functionality. If the plan is a wrapper, we say so during scoping rather than at submission.
Sign-in demanded too early
Forcing an account before showing anything, for features that do not need an account, is both a rejection risk and the fastest way to lose a new user. Let people see the value, then ask.
Screenshots that oversell
Marketing frames showing a feature the build does not contain, or a device frame that misrepresents the app, gets flagged. The screenshots have to be the app you submitted.
Permissions you do not use
Requesting sensitive access the app never exercises invites questions on both stores, and some categories on Play require a declared, justified use. Ask for less, and ask at the moment it is needed.
Declarations that disagree
Privacy answers that do not match what the code and its libraries do. Reviewers check, and the mismatch is usually an SDK nobody remembered was in the build.
Payment rules misunderstood
Digital content sold outside the store payment system, or subscription terms not stated clearly before purchase. Which side of the line your product sits on is a scoping question, not a launch-week discovery.
An unfinished build
Placeholder text, a dead link, a crash on the reviewer handset, or a feature that is obviously half-built. Still the most common rejection of all, and the most preventable.
Names and marks that are not yours
Using a platform name, another company trademark or a store badge inside your app name, icon or screenshots. Easy to do accidentally and easy to avoid once someone checks.
A Rejection Is a Message, Not a Verdict
The first instinct is usually to change something immediately. That is often the wrong move, because roughly half of what comes back is a misunderstanding that a clear reply will settle without a new build.
Read what was actually said
Identify the specific guideline and the exact screen the reviewer was on. Vague panic fixes usually produce a second rejection for a second reason.
Decide: explain or change
If the app already complies and the reviewer could not find the path, reply with the steps and a screenshot. If it does not comply, change it properly rather than hiding it.
Reply the same day
Review threads move quickly while they are open and slowly once they go cold. We answer inside the working day wherever the decision is ours to make.
Tell you what it costs
In days, not adjectives. If the date moves, you hear it from us that afternoon, with the options: ship without the feature, hold the launch, or expedite.
Rollout, Release Notes and a Date You Can Actually Announce
Approval and publication are separate events. Keeping them separate is what makes a launch plan survive contact with a review queue.
Staged on Android
Release to a small percentage of users, watch the crash-free rate and reviews, then widen. If something is wrong, you halt it while most of your users are still safely on the previous version. There is no reason not to use this.
Phased on iOS
Updates can be spread automatically across several days, with the option to pause, and users can still choose to update immediately. It applies to updates rather than to a brand-new listing, which is worth knowing before you plan around it.
Hold for a date
Get approved first, then publish manually or on a schedule. Book the press, the email and the event against the date you hold the approved build for, never against the date you submitted it.
Release notes people read
Say what changed in the words a customer would use. Generic notes about bug fixes and improvements waste a slot that users genuinely look at, and store reviewers read them too.
Server and support ready
The backend scaled for the day, support briefed on the first questions, and someone assigned to watch reviews. A launch is an operational event, not just a store button.
The first week afterwards
Crash reports, reviews and the funnel watched daily, with a fast follow-up release already planned. Assume one, because the first real-world week always finds something. That work continues under support plans.
Before and After Submission
Testing & QA
The device passes and beta tracks that stop a reviewer finding your bugs first.
Learn moreApp Store Optimisation
The listing you just published, treated as something to improve rather than finish.
Learn moreAnalytics & Monetisation
Knowing whether launch week actually worked, and how the app makes money.
Learn moreSubmission Questions
Whose name should the developer accounts be in?
Yours, always, and we set them up that way in the first week rather than at the end. The developer account is the legal publisher of the app. Your ratings, your reviews, your install history, your subscribers and your payout details all attach to it, and none of that moves cleanly to a different account later. Transferring an app between accounts is possible on both stores but it is fiddly, it has conditions, and it is a bad thing to discover you need in the middle of a dispute. We are added as team members with the access we need to do the work, and you can remove us at any point without asking anyone.
How long does the whole submission process take?
Review itself is usually the short part. The long part is everything before it: enrolling the accounts and passing whatever identity or business verification the stores ask for, setting up a payments profile if you intend to sell anything, preparing screenshots at every required size, writing the listing, and completing the privacy and content forms. On a first launch we budget a few weeks for that groundwork running alongside the final build, and we assume at least one round of review feedback. On an established account, a routine update is a much shorter exercise.
What happens if Apple or Google rejects the app?
We answer it. A rejection is correspondence, not a verdict: it arrives as a message describing the guideline at issue, usually with a screenshot or a short note from the reviewer. Some are a genuine misunderstanding and are resolved by explaining what the reviewer was looking at, which needs no new build at all. Others need a real change, in which case we make it, resubmit and tell you what happened and what it costs in days. You never have to learn guideline numbering, and we do not treat a first rejection as a surprise, because we plan for one.
Can we pick the exact day the app goes live?
You can pick the day it is released, but not the day it is approved, and the difference matters if you have booked press or an event. The way to control it is to get the app approved early and hold the release. Both stores let you keep an approved build waiting and publish it on your command or on a scheduled date. That turns an unpredictable review into a predictable launch: approval first, announcement second, never the other way round.
What do you need from us before we can submit?
A legal entity name and address that match your registration documents, a card for the account fees, a support contact that a real person monitors, a published privacy policy at a stable web address, and the final say on the app name. If anything in the app sits behind a login we also need a working demo account that will stay working, and if you take payments we need your banking and tax details on the payments profile. We prepare everything else, including the screenshots, the listing text and both privacy declarations, and you approve them before anything is sent.
Do we have to release to everyone at once?
No, and for a first release you generally should not. Google Play supports a staged rollout where a percentage of users get the new version and the rest stay on what they have, so you can watch the crash-free rate and halt if something is wrong. Apple offers a phased release for updates that spreads them over several days, with the option to pause. Neither applies to the very first version of an app on iOS, where a new listing simply becomes available, which is one more reason to test with real users before that day rather than after.
Let Us Handle the Stores
Whether we built the app or somebody else did, we can take it from a finished build to a live listing on both stores — accounts, signing, declarations, review and all.