Why I Keep Getting Apple Review Rejections

I’ve been rejected by Apple review more times than I’d like to admit. Every time it’s frustrating. Sometimes it’s infuriating. But looking back, they might have saved me more than once.

FansLineup - using real data

This one killed an entire project. I spent two years building FansLineup, a football app where fans submit their preferred lineups for upcoming matches. We used real team names, real logos, real player names and faces, real stats.

Apple rejected it. The reasoning was that news and media apps can use that kind of data as public domain, but because our app was closer to a game (even though it really wasn’t), they blocked it. We reached out to the clubs to license the branding. Everyone said no.

How I solved it: I didn’t. I gave up. And honestly? If I’d only launched on Android and kept going, would I eventually have been hit with a trademark lawsuit? Probably. Apple protected me from something worse down the line even though it didn’t feel like it at the time.

API Alerts - “accepting payments”

When I first submitted API Alerts to the App Store, they rejected me for having payment functionality. The thing is, payments weren’t even built yet. I just had a standard registration flow with a “Get Started” button.

The problem was that my onboarding made it look like I was going to sell something outside of Apple’s in-app purchase system. They flagged it preemptively.

How I solved it: I reworked the onboarding to look like an account check process rather than a sign-up flow. Think “Enter your email to check your account” instead of “Register now.” The app does sell subscriptions through the website, but the mobile app itself is a companion that checks your existing account status. That distinction mattered.

Metadata and screenshots

I’ve been rejected for screenshots not accurately representing the app. You’d think this would be straightforward but Apple is strict about what’s shown. Marketing screenshots that are too stylised or show features that don’t exist yet will get flagged.

How I solved it: Use real screenshots. Annotate them if you need to, but make sure every screen you show actually exists in the build you’re submitting.

The login screen problem

If your app requires authentication, you need to provide Apple with a demo account so the reviewer can actually use the app. I’ve been rejected for not including login credentials in the review notes. Easy fix but easy to forget, especially when you’re submitting at 2am and just want it done.

Missing privacy policy

Apple requires a privacy policy URL that’s accessible from outside the app. I’ve had rejections where the URL was there but the page was broken or returned a 404. If you’re deploying your website and your app at the same time, make sure the privacy policy page is live before you submit.

My advice

If you’re building for both platforms, submit to Apple first. Not because Android doesn’t matter, but because Apple is stricter and you want to find out early if your concept has a problem. Android will almost certainly approve it. That’s both good and bad.

With FansLineup, if I’d submitted to Apple in month 3 instead of month 18, I would have found out about the trademark issue before investing another year of nights and weekends. Build the iOS version first, get it through review, then do Android knowing the concept is approved.

Also, validate your idea against Apple’s guidelines before you write a single line of code. Read the App Store Review Guidelines. It’s not exciting reading but it could save you from building something that can never ship.

My personal feelings towards Apple and their review process are complicated. They’ve rejected me enough times that I should probably be bitter. But honestly, they might have protected me from worse outcomes more than once. I just wish they’d tell me that before I spend two years building something.