7 Lessons from Shipping Apps to the App Store

I started mobile development on the Android side in 2020, moved to iOS with Swift in 2021, and shipped my first apps to the stores in 2022. Since then I have released 11 apps on the App Store and Play Store. Looking back today, what actually hurt was not the parts that were technically hard — it was the time I lost because I did not know the process.

What follows is not secondhand advice. These are things I know because they happened to me. Three of the apps I am building right now — Vakti Geçmeden, Hadi Yapalım and Sinepia — are in review, and I still work off this list.

1. A rejection is not a failure, it is part of the process

When I got my first rejection, I assumed something was fundamentally wrong with the app. It was not. The App Review team rejects you because you tripped over a guideline, and they tell you exactly which clause you tripped over, with its number. That is a free audit report.

What to do is simple: read the Resolution Center message all the way through, open the guideline it cites, and do exactly what is asked. Nothing more. Do not add your own interpretation and think "maybe I should fix this too" — you open a new surface and trip over a new clause.

2. Privacy declarations tripped me up the most

The code is ready, the screenshots are ready, and the app still gets rejected. The reason was almost always the same: the data I declared in the App Privacy section did not match the data the app actually collected.

The trap here is that the code you wrote may not collect anything, but the third-party libraries you integrated do. An ad SDK, an analytics tool, a crash reporting service — all of them collect data that has to be declared.

• Read the privacy documentation of every dependency in the project, one by one.
• Add the data they collect to the App Privacy form — saying "I don't collect anything" is the riskiest option.
• Give the app a reachable privacy policy URL. A static page is enough; I put up a page on my own website for each app.

3. If you offer account creation, you must offer account deletion

This rule cost me an entire release. If a user account can be created inside your app, the user must be able to delete that account from inside the app. "They can email us and we'll delete it" is not accepted.

The deletion flow also has to genuinely work: pressing the button must remove the account and the data attached to it. The reviewer tests this. If you use Firebase or Supabase, it can be handled by a server function — but if you don't plan for it up front, bolting it on later can wreck your data model.

4. The store page matters as much as the app itself

For a long time I thought that if I built a good app, the rest would follow. It does not. Before a user downloads you, all they see is your icon, your title and your first two screenshots. The decision is made right there.

The three things that made the biggest difference on the ASO — App Store Optimization — side:

• Subtitle: Explain what the app does in 30 characters. Write the function, not a slogan.
• The first two screenshots: Instead of raw screen captures, use designed images with a short headline on top. I put these together in Photoshop and Canva.
• The keyword field: 100 characters. Separate words with commas, do not add spaces, and do not repeat words that already appear in the title.

5. Make the reviewer's job easier

Every sentence you write in the App Review notes shortens the review. This is my standard template:

Test account:
  Email    : test@ornek.com
  Password : ...

To try the main feature:
  1. Sign in
  2. Tap the "+" button on the home screen
  3. ...

Note: The notification permission prompt appears on first launch.
Location data is used only for feature X, it is not collected in the background.

If some part of the app is hard to grasp, I also attach a 20–30 second screen recording. The reviewer is seeing your product for the first time; if something does not make sense to them, rejecting it is faster than trying to figure it out.

6. Do not put the review time on your calendar

There is no rule that says "approved within 24 hours". Sometimes I got through in 8 hours, sometimes I waited 4 days. It takes longer during holiday periods and in the weeks when major iOS versions ship.

So if you are committing to a fixed launch date:

• Turn off automatic release after approval and choose manual release. That way the app gets approved but does not appear in the store until you press "release".
• Submit at least a week before your planned date.
• Submitting on a Monday works out better than submitting on a Friday — if it lands on the weekend, the wait gets longer.

7. Release is the starting line, not the finish line

This is the most expensive lesson on the list. With my first apps I thought "I shipped it, the job is done" and waited for the download numbers to climb on their own. They did not.

What an app needs after release:

That is why, starting in 2025, I stopped staying purely on the code side; I learned SEO, ASO and digital marketing. It is not enough for a feature to work — it has to be found and used.

Summary

The hard part of app development is usually not the code, it is the process around the code. The good news is that this process can be learned, and once you have learned it, it pays off again on every app.

An app is not finished the moment it is uploaded to the App Store; it is finished when it reaches users, gets measured and grows.

• App Store
• iOS
• Swift
• App Review
• ASO
• Release process