What I learned shipping apps to the App Store and Google Play

When I submitted my first app, the thing I feared most was the code. Five apps later I know the code was the easy part; the real time disappears into store processes. Here is what I wish I knew on day one.

Review processes: two stores, two personalities

Google Play scans mostly automatically; you're live within hours, but when something goes wrong it's hard to find a human. On the App Store, a real person opens your app, pokes around and sends a rejection with screenshots if needed. My early App Store rejections all had the same causes:

• Not providing a test account. If the reviewer can't log in, they don't try; they reject.
• Empty states. Screens without content scream "unfinished app".
• Permission strings. If your camera or location prompt has a generic sentence, it comes back; you must state clearly what the permission is for.

A rejection is not a punishment; it's a free QA report. Even the worst one is resolved in a day or two; no need to panic.

Metadata is part of the code

The store page isn't a side quest; it's part of the product. The routine I settled on:

• Brand + strongest keyword in the title, like "Benim Sınavım: TYT AYT Prep".
• The first two sentences are everything; most users never tap "more".
• Screenshots tell a story, not a feature list: one message per frame, big text.
• Pick keywords from search suggestions and competitor pages, not from guesses.

My release-day checklist

Before every release I walk the same list:

• Are the release notes ready in both languages?
• Are new permissions reflected in the store copy?
• Does the app survive its first launch without internet?
• Is the rollback plan clear? (Especially for server-side changes)

Shipping to the stores is not a marathon; it's a short run you repeat regularly. Once the process became a template, every release got easier than the last.