Three App Store Rejections and What They Taught Us

Getting rejected by the App Store is one of the most frustrating parts of iOS development. It happens after weeks of work, often for reasons that feel arbitrary — and the feedback is usually brief. This is a documented case of a GPS tracking app that received three consecutive rejections, what caused each, and how they were resolved. The patterns repeat across many apps, and understanding them upfront prevents avoidable delays.

The project context

After Google discontinued Timeline in Google Maps in 2024 — moving location history to an unreliable local mode — a developer with no prior iOS experience built a personal GPS trip tracker in SwiftUI. The app records routes, calculates fuel costs, color-codes speed segments on a map, and includes a fog-of-war overlay that reveals only traveled areas. It also uses Live Activity on the lock screen as a recording indicator.

The full project — from first commit to App Store submission — took one month of evenings. It then required three review cycles before approval.

Rejection 1: The start button didn't work

The original design used a long press (0.4 seconds) to start recording, specifically to prevent accidental launches. Apple's reviewers tapped the button — nothing happened — and rejected the app for non-functional UI.

The design intention was sound: preventing accidental GPS recording is a real concern. But the interaction was invisible. No visual hint communicated that a long press was required. The fix was replacing the long press with a slide-to-start mechanic — the interaction became self-explanatory.

Rejection 2: Vague location permission description

The NSLocationAlwaysUsageDescription string contained generic text. Apple rejected the submission, requesting a more specific explanation of what is recorded, why always-on location access is necessary, and what controls the user has over their data.

The required level of specificity is higher than most developers expect. Generic phrases like "used for location features" are not sufficient. Apple wants to see:

• What data is collected (coordinates, route points, speed)
• Why background access is necessary (recording continues when the app isn't foregrounded)
• How users can stop collection (explicit stop control in the app)
• Whether data leaves the device (local only, or synced)

This requirement applies equally to health data, microphone access, contacts, and any other sensitive permission. The description should read like an honest summary of the privacy policy, not a placeholder.

Rejection 3: Non-localized system alert text

The permission strings were hardcoded in a single non-English language directly in Info.plistrather than stored in a InfoPlist.strings localization file. Apple's reviewers use devices with English as the system language. When the permission alert appeared in a foreign script on their English-language review device, the submission was rejected.

The fix is structural: permission descriptions and any user-facing text in Info.plist must be localized via InfoPlist.strings files. At minimum, an English version is required. This applies to all permission strings — location, camera, microphone, contacts, and others.

One useful observation about the review process

After each rejection, canceling the current review via the Resolution Center and resubmitting appeared to significantly accelerate processing — from several days to 2–5 hours. This is not guaranteed behavior, but it's worth knowing as a practical option when facing a time-sensitive release.

What AI-assisted development handles well — and what it doesn't

This project was built with Claude and Cursor providing substantial coding assistance. The experience illustrates a clear division:

• AI handles SwiftUI boilerplate, navigation, data models, and Info.plist structure reliably
• AI generates ActivityKit and CoreData schemas quickly and correctly
• Background GPS behavior, battery optimization, and edge cases require real-device testing — AI cannot simulate a GPS signal dropout on a specific highway
• Domain-specific algorithms (the Kalman filter for smoothing GPS coordinates) needed multiple iterations and manual refinement on real trip data before the output was usable

What to validate before App Store submission

• Test all custom interactions with someone who has never seen the app — if they can't figure it out in 5 seconds, rethink it
• Write permission descriptions that answer: what, why, how to stop, where the data goes
• Localize all Info.plist strings — at minimum English and any language in your primary market
• If your app has in-app purchases, test the full payment flow, including the review sandbox
• Check your screenshots on the exact device sizes Apple lists — they test on those configurations