Noted: when you submit your latest build to the App Store, an hour later an email arrives: "ITMS-91053: Missing Privacy Manifest." With every new iOS SDK version, Apple deprecates old APIs and introduces mandatory requirements. Without planned migration, you risk being unable to submit updates. We frequently encounter these scenarios and offer end-to-end migration — including audit, update, and guarantee.
What Actually Breaks When Changing SDKs
Deprecated APIs are the most extensive part of the work. UIWebView has been removed since the iOS 15 SDK; apps using it receive rejection with ITMS-90809. UIAlertView, UIActionSheet, shouldAutorotateToInterfaceOrientation — these methods no longer compile in the iOS 16 SDK. We search the codebase via Xcode #available and the deprecated list from the specific SDK release notes.
Privacy Manifest (iOS 17 SDK) — a new requirement from recent versions. Every third-party dependency and the app itself must include a PrivacyInfo.xcprivacy file declaring the used API categories (NSPrivacyAccessedAPITypes): NSUserDefaults, NSFileManager, NSProcessInfo, UIDevice.systemBootTime. If the file is missing, ITMS-91053 appears as a warning (now an error) during submission.
Example PrivacyInfo.xcprivacy:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ...> <plist version="1.0"> <dict> <key>NSPrivacyAccessedAPITypes</key> <array> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategoryUserDefaults</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>CA92.1</string> </array> </dict> </array> </dict> </plist> Reasons must be specific codes from Apple's documentation. CA92.1 for UserDefaults means "storage of settings directly managed by the user." You can't just write any code — you must choose from the approved list. If none fit, you need to write to Apple via App Review, which is a challenge in itself.
Swift Concurrency and Sendable — iOS 16+ SDK includes enhanced Sendable checks and actor isolation. A project that built without warnings on an older SDK will produce dozens of warnings like Capture of non-Sendable type 'SomeModel' on the new SDK. With iOS 17 SDK, some become errors when strict concurrency checking: complete is enabled. On large codebases, this is a significant effort.
How We Perform the Migration
-
Audit via
xcodebuildxcodebuild -workspace MyApp.xcworkspace \ -scheme MyApp \ -destination 'generic/platform=iOS' \ -sdk iphoneos17.0 \ build 2>&1 | grep -E "error:|warning:" | sort | uniq -c | sort -rn | head -50This provides a quantitative picture: how many errors, which categories, top 50 by frequency. For a 300k line codebase jumping from iOS 14 SDK to iOS 17 SDK, typical results are 15–40 errors and 100–300 warnings. Our automated audit approach is 10–15 times faster than manual code review.
Analysis of Third-Party Dependencies The second issue is libraries that haven't been updated in two years. Our checklist:
- CocoaPods:
pod outdatedfor a list of outdated dependencies - SPM: check
Package.resolved, look for libraries without recent tags on GitHub - Dependencies with outdated
deployment target— conflicts with the app's new minimum iOS version
A special case is dependencies without a Privacy Manifest. Apple requires manifests from popular SDKs (Firebase, Crashlytics, Amplitude, Adjust, and others have updated their packages). But for lesser-known libraries, the manifest may be missing, requiring either forking and adding it or removing the dependency.
Migration by Complexity Levels
Category of Changes Effort Replace UIWebView→WKWebViewMedium (delegate API changes) Privacy Manifests for custom code Low (configuration) Privacy Manifests for third-party SDKs Depends on author support Sendable/actor isolation warnings High (architectural changes) Removed APIs (UIAlertView etc.) Low (direct replacement) - CocoaPods:
What's Included in Our Work
- Full codebase audit with xcodebuild and identification of all blocked APIs
- Configuration of Privacy Manifest for the app and all dependencies
- Updating third-party SDKs to versions compatible with the new iOS SDK
- Fixing Sendable/actor isolation warnings
- Testing on real devices with the new iOS version
- Documentation of changes and recommendations for ongoing support
- 30-day guarantee after delivery
How We Test After Migration
Smoke tests on a real device with the new iOS are mandatory. Simulator and real device can behave differently when changing SDKs, especially regarding URLSession timeouts, push notifications, and background execution.
Crashlytics or Firebase Crash Reporting — after release we monitor new crash signatures in the first 24–48 hours. SDK migration sometimes introduces crashes in edge cases not covered by tests.
Timeline Estimates
Timelines depend on codebase size, number of deprecated APIs, and dependency state:
| Project | Timeline |
|---|---|
| Small app (< 50k lines, few dependencies) | 1–2 days |
| Medium project (50–150k lines) | 3–5 days |
| Large project with legacy Obj-C code | 1–2 weeks |
Cost is calculated individually, but you save by catching issues early — migration costs are always lower than the consequences of blocked releases. Contact us for an accurate assessment. With experience migrating over 50 projects, we guarantee to account for all pitfalls. Get a consultation for your codebase — we'll conduct an audit in one day.
Apple App Store Review Guidelines