Pressing Submit does not mean your app is submitted
Pressing Submit in a store console does not mean your app has been submitted. It means a button was pressed. Those are different facts, and the gap between them is where releases go to die quietly for four days while you believe you are waiting for Apple.
"Submit" in App Store Connect and Play Console names a control, not an outcome. That is a small piece of vocabulary with a large consequence: it lets the console be entirely correct while you are entirely wrong. Nothing lied to you. The button was pressed. The word just did not mean what you took it to mean.
Here is what it ought to mean. A specific build of a specific version has been accepted into a review queue, everything that queue requires is present, and if any of that were not true you would have been told in a sentence.
That is not a demanding specification. It is close to the minimum a person would assume from the word.
What actually has to be true, on Apple's side
The chain from finished code to a queue position has more links than the interface implies. Build an archive. Upload it with Xcode or Transporter. Wait for processing, because the build is not selectable until Apple has finished with it. Attach the build to a version. Answer export compliance. Complete the age rating questionnaire. Fill in App Review Information, including a demo account that works. Confirm your agreements are signed. Create a submission, add items to it, and then submit it.
Each of those can fail without a red banner in front of you:
- A build that never finishes processing, so the version has nothing attached and no obvious reason why.
- A version sitting in Prepare for Submission because one required field somewhere is empty.
- Export compliance unanswered, which quietly holds the build.
- The Paid Applications agreement unsigned, or tax and banking incomplete, so a paid app cannot go live even after approval.
- One empty screenshot slot for one device size, on one localisation you added and forgot.
- An item removed from a submission because it had an issue, letting the rest proceed without the thing you actually cared about.
- A submission created but never submitted, which looks like progress and is not.
The last one is the cruellest, because the screen says a submission exists. It does. It is just sitting there.
And on Google's side
Build an app bundle. Sign it with the right key. Upload it to a release on a track. Set countries and a rollout percentage. Complete the content rating questionnaire. Complete the Data safety form. Declare permissions and target audience. Then roll out.
The failure modes are different in shape and identical in effect:
- An upload rejected at the door for target API level or a signing key mismatch, which is at least loud.
- A release saved as a draft rather than rolled out, which is not.
- A staged rollout left at a small percentage, which is live to almost nobody but reads as released.
- Managed publishing holding an approved change indefinitely, waiting for a click you did not know you owed.
- Country availability that excludes the country you are standing in, so you check your own store and conclude the release failed.
- A Data safety answer that blocks review without a message that names the answer.
- An app published successfully to a track you did not mean.
Notice that most of these are not errors. They are states. The system is functioning exactly as configured, and the configuration is wrong, and nothing in the interface is obliged to point that out.
What the word should guarantee
This is a specification, not a complaint. A console could meet all six.
1. Submitted means queued. If the item is not in a review queue, the word must not appear anywhere near it. Not on a button, not in a toast, not in an email subject line. There are perfectly good words for the other states.
2. Preconditions are checked before the button, not discovered after it. The console knows which screenshot sizes are required, which agreements are unsigned, and which localisation is missing a field. It should refuse the action and name the gap, rather than accept the action and stall on it. A check that runs after the click is a check that has chosen the worse moment to run.
3. One state, in one place. A version that is live in nine countries and pending in three is not "live". A rollout at 5% is not "released". An interface that rounds a partial state up to a clean one is not simplifying, it is misreporting. If there are two numbers, show two numbers.
4. Failure states must be sentences. "There was a problem" is not a state, it is a shrug. The console knows which field, which locale, which device size, which agreement. Say it. A developer can act on a sentence and cannot act on a shrug.
5. Never offer an action that cannot succeed. A retry button on a submission that will fail for the same reason is worse than no button, because it converts a diagnosable problem into a loop. If the action is doomed, hide it and show the fix instead.
6. The confirmation should say what happens next. Not a guarantee, just the shape of it: what state you are in, what moves you out of it, and who moves it. If the system genuinely does not know how long something takes, that is a fine thing to say, and much better than silence.
None of that is hard engineering. There is no distributed systems problem in refusing to write the word "submitted" next to something that is not submitted. It is a naming decision, and a disclosure decision, and both of those are choices about whose time is being spent.
Why the vocabulary is expensive
The cost of an ambiguous "submitted" is not confusion. It is days.
You do not chase a thing you believe is done. That is the whole mechanism. A loud failure costs you ten minutes, because you fix it and move on. A silent one costs you until the moment you happen to look, and you will not happen to look, because you have already moved on to something else with the satisfied feeling of a person who shipped.
The worst failures in a release pipeline are not the ones that break. They are the ones that look exactly like success. A build stuck in processing looks like a build being processed. A draft release looks like a release. A submission with the item you cared about removed looks like a submission. Every one of those is indistinguishable from progress until you check the one screen that tells the truth, and nothing prompted you to check it.
So the word matters more than it sounds. Language is the only interface most developers have to the state of their own release. When "submit" means "a button was pressed", you have to hold the real state in your head, permanently, for every version, on two stores with different vocabularies for the same idea. People are bad at that, and they should not have to be good at it.
AppSubmit exists because of this specific argument: it will not say submitted until something is actually in a queue, and it checks the preconditions before offering the action rather than after. Every check in this article can be done by hand in the two consoles, and the list above is the list.
Until the consoles say what they mean, the workaround is unglamorous and it works. After every release, open the version and read its actual state. Not the confirmation you were shown. The state.