Shaurya's knowledge base(|)
Shaurya WikiApp Store Nightmares

App Store Nightmares

Every iOS developer has App Store horror stories. Mine are worse because I was 14 when they started, and nobody prepares you for the bureaucratic obstacle course that is Apple's developer ecosystem.

Provisioning Profiles

If you've never dealt with Apple provisioning profiles, count yourself lucky. They are the system Apple uses to control which devices can run which apps, which entitlements an app can use, and which developer signed the build. In theory, this is a security feature. In practice, it's a maze designed to make you question your life choices.

My first encounter with provisioning profiles almost made me quit iOS development entirely. Amir had to hop on a late-night Google Meet to walk me through certificate generation, because the error messages Apple gives you are deliberately unhelpful. "No matching provisioning profile found" — thanks, Apple. Which of the seventeen profiles I've accidentally created is the wrong one?

Entitlements

LockIn uses Apple's FamilyControls framework, which requires a special entitlement that Apple has to manually approve. You can't just flip a switch in Xcode — you have to apply, explain your use case, and wait. For a 15-year-old building a screen time app, this added weeks of delay to what should have been a straightforward feature.

The entitlement system is Apple's way of gatekeeping access to powerful APIs. Want to use Screen Time? Apply. Want to use HealthKit? Apply. Want push notifications? Configure certificates, keys, and profiles. Each one is another step between "I built this feature" and "users can actually use it."

Sandbox IAP Testing

StoreKit 2 — Apple's in-app purchase framework — works differently in sandbox mode than in production. Subscriptions renew every few minutes instead of monthly. Transactions behave unpredictably. Sandbox accounts expire or get stuck in weird states. Testing in-app purchases is an exercise in managing two realities simultaneously: the sandbox world and the real world.

For LockIn's subscription model, I had to test purchase flows, trial periods, and paywall behaviour across multiple sandbox accounts. Half the time the sandbox would just... not work. Purchases wouldn't register. Receipts wouldn't validate. And there's no clear documentation explaining why.

Xcode Build Errors

Xcode is the only IDE for iOS development, and it has opinions. Strong opinions. About everything. Build errors in Xcode are a special breed of frustration because they cascade — one genuine error triggers fifteen phantom errors that disappear once you fix the real one, but you have to figure out which one is real first.

The worst are the signing errors. "Build input file cannot be found." "Command CodeSign failed with a nonzero exit code." These appear, disappear, and reappear based on what feels like lunar cycles. Clean build folder. Restart Xcode. Delete derived data. Pray. This is the iOS developer's diagnostic ritual, and I perform it more often than I'd like to admit.

The Review Process

Submitting to the App Store means your app goes through Apple's review team. They check for compliance, functionality, and content. For LockIn, navigating App Store compliance for an app that literally blocks other apps on your phone required careful communication about what the app does and why it needs the permissions it requests.

Why I Keep Doing It

Despite all of this, shipping on the App Store feels like nothing else. When LockIn went live on April 13, 2026, all the provisioning profile nightmares, the sandbox testing pain, the Xcode build errors — they were worth it. Because the app was real, in the real App Store, downloadable by real people. That moment of "it's live" erases a lot of suffering.

See Also

Browse Wiki