Our First App Store Submission: Xcode Errors, Terminal Rabbit Holes and Getting There in the End
We thought submitting our first app to the App Store would take an afternoon. It did not. Here's the honest account of what the process involved, what kept going wrong, and why — despite everything — getting that first approval was one of the best feelings we've had building this studio.
The confidence before the fall
By the time we were ready to submit our first app, we felt fairly good about where we'd got to. The app was working. We'd been through the pain of setting up our Apple Developer account, we'd dealt with the keychain issues, we'd done our testing. Submission, we told ourselves, would be the easy part.
We were wrong about this in a way that, looking back, feels almost comic. The submission process has its own set of things that can go wrong — completely separately from anything that happens inside your code — and most of them are not particularly well-explained anywhere.
The process, as it actually unfolds
Before you can submit anything, you need to get through a sequence of steps in Xcode that go under the label of "archiving" and "distributing" your app. Archive creates a packaged version of your app. Distribute sends it to App Store Connect, which is Apple's portal for managing everything on the App Store side. Only once it's in App Store Connect can you actually submit it for review.
Each of those steps — archive, distribute, App Store Connect setup, submission — has its own things that can fail. Here's roughly how our first attempt went:
Even with the signing setup looking correct, archiving threw an error about certificates. This was related to our provisioning profile not matching the bundle identifier we were using. We fixed it, tried again.
We got an archive but the upload to App Store Connect errored out. The error message was one of those that tells you what went wrong but not how to fix it. We spent a while trying different export options before finding the right configuration.
At some point the Xcode GUI wasn't giving us enough information to understand what was failing. We ended up using the Terminal to run parts of the process manually, which gave more detailed output but also introduced new opportunities to do the wrong thing. Several were taken.
Eventually a build made it through. At this point we felt genuinely relieved — for about ten minutes, until we realised how much needed filling in before we could submit.
App name, subtitle, description, keywords, screenshots for multiple device sizes, privacy policy URL, contact details, content rating questionnaire, age rating, pricing, availability. All of this needed to be in before we could hit Submit for Review.
The first review took longer than expected. We checked the status approximately every twenty minutes.
The rejection
Our first submission was rejected. This is apparently very common for first-time submitters — Apple's reviewers are thorough, and they catch things that you either missed or didn't know were required.
The rejection came with notes explaining what the issue was. We read those notes carefully, fixed the specific problems raised, and resubmitted. The second submission went through.
It's worth saying clearly: a rejection is not a disaster. It feels like one in the moment. But the App Store review process exists to protect users, and the feedback is usually specific and actionable. The worst thing you can do is resubmit without properly reading and addressing what they've raised.
When it went live
The moment the app status changed to "Ready for Sale" was genuinely one of the best moments we've had building anything. After all of the setup, the certificate issues, the keychain problems, the failed builds, the forms, the waiting, and the rejection — there it was. On the App Store. Something real that anyone could download.
It sounds simple when you write it like that. It hadn't felt simple getting there. But the combination of knowing that we'd built it ourselves, dealt with everything that went wrong, and come out the other side with a live product — that felt like something.
What we'd tell ourselves going in
- Treat submission as a full day's work, not an afternoon task. Budget the time accordingly and don't plan anything else for that day.
- Prepare your App Store assets well in advance. Screenshots, description, keywords, privacy policy — have all of this ready before you start the submission process, not during it.
- Read the App Store Review Guidelines before you submit. Apple publishes the list of reasons apps get rejected. Going through it once before submission lets you catch obvious issues yourself rather than hearing about them from a reviewer.
- A rejection is feedback, not a verdict. Read it properly, fix the specific issues raised, and resubmit. It's part of the process.
- When Xcode error messages stop making sense, use the Terminal for more detail. The output is verbose but it usually tells you exactly what the problem is if you read it carefully enough.
- The second time is dramatically easier. Everything you learn the hard way the first time becomes second nature. It's worth pushing through.
Why it's still worth doing
We've now been through the full process more than once and it has become, if not exactly simple, at least predictable. We know what each step involves, we know what can go wrong and roughly why, and we can move through it with a lot more confidence than we had first time around.
That experience — having actually shipped something to the App Store ourselves — changes what we can offer to clients who come to us wanting an app. We're not describing a process we've read about. We've been through it, including the parts that go wrong, and we're set up to support clients through the same journey.
If you're planning your first submission and want someone to walk through it with you or sense-check what you've prepared, get in touch. We're happy to help you avoid the specific potholes we hit.