●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 27 days left. If your app calls it, check the migration target●SDK 58 — Moves to React Native 0.88. R8 is now on by default in Android release builds, and iOS prebuild generates a SceneDelegate●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…●GPT-6.1 SOL — Added to Rork's model menu (09-29) with Low, Medium and High effort; included on Pro and Max●SONNET 5.5 — Claude Sonnet 5.5 is selectable: strong at UI design and faster than Sonnet 5 (09-28)●SONNET 4.5 — Retires on the Claude API on 11/30, 27 days left. If your app calls it, check the migration target●SDK 58 — Moves to React Native 0.88. R8 is now on by default in Android release builds, and iOS prebuild generates a SceneDelegate●OBSERVE — EAS Observe now records native crashes too (SDK 57.0.21 or later, 10/07)●NEW — My App Open Ad Only Showed When the App…
When Your Rork App Gets ITMS-91053 — A Practical Guide to Privacy Manifests and Required Reason APIs
Submitting a Rork-generated Expo app to the App Store can trigger Privacy Manifest warnings even when you never wrote the offending code. Here is how to clear both Required Reason API and SDK manifest issues before you submit.
A few minutes after uploading a build to App Store Connect, an email with "ITMS-91053" in the subject line lands in your inbox. As an indie developer who has shipped apps for years, I will admit that the first time I hit this warning, I genuinely could not tell what it was complaining about. I had not knowingly written any privacy-related API.
Rork generates an Expo (React Native) app, and you write almost no native code yourself. The warning still appears because the cause is not your JavaScript — it lives in the native layer of Expo and the SDKs underneath it. Without understanding that, you keep burning time on pre-review rejections. This article walks through clearing Privacy Manifest issues before submission, assuming a Rork-generated app.
ITMS-91053 and ITMS-91061 Are Two Different Problems
These two get conflated constantly. Both arrive by email, but the cause and the fix differ.
ITMS-91053 is "Missing API declaration": you use a Required Reason API but have not declared the reason in PrivacyInfo.xcprivacy. This is usually about your own app (or a thin native layer).
ITMS-91061 is "Missing privacy manifest": a third-party SDK on Apple's "commonly used" list does not ship a signed manifest. AdMob (Google Mobile Ads SDK) and various analytics SDKs fall here. You cannot fix this in your code — you bump the SDK version instead.
Early on, I tried to fix both as one "privacy warning," patched only one side, resubmitted, and got the same email again. Splitting them by the ITMS number first is by far the fastest path.
What a Required Reason API Is, and Why Expo Apps Trip It
Required Reason APIs are OS APIs that are easy to abuse for fingerprinting. Using them is allowed, but you must declare why with a reason code. The four common categories are file timestamps (NSPrivacyAccessedAPICategoryFileTimestamp), disk space (DiskSpace), system boot time (SystemBootTime), and UserDefaults.
The catch in Expo apps is that you hit these without calling them directly. UserDefaults is used internally by AsyncStorage and many libraries; file timestamps are touched by caching libraries. The more features you add in Rork, the more of these APIs creep in.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦Learn to read the ITMS-91053 / ITMS-91061 emails that arrive right after upload and tell whether your code or a bundled SDK is the cause
✦Get a minimal PrivacyInfo.xcprivacy that declares only the four NSPrivacyAccessedAPITypes a Rork app realistically hits
✦Turn 'commonly used SDK' manifest gaps like AdMob into a permanent fix using Expo config plugins and dependency upgrades
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
PrivacyInfo.xcprivacy is a plist. Here is a minimal example declaring the four that a Rork app realistically hits. Reason codes are fixed strings defined by Apple; you cannot invent values.
CA92.1 is the UserDefaults reason for "storing your app's own data within the app," which covers almost any app using AsyncStorage. Wrong reason codes get rejected even when declared, so pick the one matching your use from Apple's docs.
The Real Hurdle Is the SDK Manifest Gap (ITMS-91061)
If ITMS-91061 persists after fixing your own app, the cause is a bundled SDK. For me, the warning appeared the moment I added AdMob for monetization.
The fix:
Check the SDK names listed in the email body (e.g., GoogleMobileAds).
Find the version of that SDK that ships a privacy manifest.
Bump it in package.json and rebuild the iOS project with npx expo prebuild --clean.
Rebuild, submit, and confirm the warning is gone.
Skipping prebuild --clean leaves stale native artifacts, producing the maddening "I upgraded it but it still fails" state. I got stuck on exactly this once, so I now always do a clean build after an SDK update.
The NSPrivacyTracking Question When You Don't Track
Even with AdMob, if you serve only non-personalized ads and do not track via ATT (App Tracking Transparency), you can leave NSPrivacyTracking as false. But this decision must match your ad configuration.
If you lock to non-personalized ads only, it does not count as tracking. Conversely, if you later enable personalized ads but leave the manifest at false, your declaration no longer matches reality. Whenever you change monetization settings, revisit the manifest.
A Final Pre-Submission Check
Before submitting your next build, confirm three things: PrivacyInfo.xcprivacy is included in the iOS target, your declared reason codes match your actual use, and every bundled SDK is on a manifest-supporting version. With those three aligned, most ITMS-91053 and ITMS-91061 cases disappear before submission.
Rejections are draining, but Privacy Manifest issues follow a fixed pattern — build the setup once and you stop worrying about it. I hope this saves someone stuck at the same gate.
Share
Thank You for Reading
Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.