What nobody tells you before launching your first app — these mistakes can flag your account
MoveOn is the first app I’ve ever shipped. Writing the code was the part I knew how to do. Getting it past App Store review was the real education — here’s the honest log.
I spent about a month studying before I wrote a line of MoveOn. How the App Store works, how other people ship, what a good launch looks like — I read all of it. And the honest takeaway is that the reading only got me so far. The best way to learn this is to actually start building and shipping. Everything that really stuck, I learned by hitting a wall and climbing over it.
The development itself wasn’t the hard part. I work as a software engineer, and with tools like Claude Code in the loop, building the app moved fast. The wall I didn’t see coming was everything around the code — the paywall, the store rules, the review process. That’s where I lost the most time, so that’s what this post is about.
The bug I literally couldn’t see
This one cost me days. I’d submit the app, and Apple would reject it saying the paywall was missing its privacy and terms links. Except it wasn’t — the links were right there. I’d resubmit, get rejected again, and slowly lose my mind.
The paywall is built with RevenueCat, and here’s what was actually happening: I was reviewing the paywall in my own language, Spanish, where everything was translated and looked perfect. But the English version was missing a word — and on top of that, the paywall wasn’t even rendering correctly in English. RevenueCat never flagged the missing string as missing, so nothing pointed me to it.
“We were unable to find the privacy policy and terms of use within your app’s paywall.” — a message I saw far more times than I’d like to admit, for a paywall that had both.
The reviewer doesn’t see your app in your language. They see the default — English — and that’s where it was broken. I only caught it because, out of desperation, I started checking the translations one by one. The moment I switched the device to English, the problem was obvious.
Review your paywall and onboarding in every language you ship — especially the default one. Your own language being perfect tells you nothing about what the reviewer actually sees.
Apple really cares how you say “free”
The second wall was about wording. In the onboarding I’d leaned too hard on the word “free”, and I’d made the free trial days more prominent than what the subscription actually costs per year. Apple is strict about exactly this — they want the price and terms to be at least as clear as the “free” part.
The frustrating bit is that plenty of popular apps clearly push “free” harder than I did. From what I can tell, how much you can get away with depends partly on how established your app is — the number of downloads behind it. As a brand-new app with no track record, I got held to the stricter reading of the rule.
Don’t make “free” or the trial length louder than the real price. On a new app especially, assume review will read every guideline literally — because it will.
What actually taught me
A month of reading gave me a map. Shipping gave me the territory. Both of these problems were invisible until I was standing in front of them, and neither was really about code — they were about the boring, unglamorous layer where your app meets the platform.
If you’re sitting on your first app waiting to feel ready: you won’t, and that’s fine. Build it, submit it, and let the rejections teach you. That’s the fast version of the lesson I paid for in days.
Next up: how MoveOn got its first organic traffic, and then everything I learned about organic marketing. Subscribe and you’ll get them first.
Get the next post →