iOS app upgrade and migration
iOS app upgrade services for apps that have fallen behind Apple’s toolchain
Our iOS app upgrade services bring an existing iPhone or iPad app back to a state where it builds on the current Xcode, passes App Review and can be changed safely. We handle the Xcode 26 and SDK move, Swift 6, dependency updates, privacy manifests and a step-by-step move from UIKit to SwiftUI where it pays off. This is a focused project within our iOS app development service.
The app keeps shipping throughout. We do not freeze your roadmap for a rewrite.
- Xcode 26 and iOS 26 SDK builds
- CocoaPods and Carthage moved to SPM
- Swift 6 adopted module by module
- Privacy manifests and SDK audit
Signs your iOS app needs an upgrade project, not a quick fix
Most upgrade projects start with a small request that turns out not to be small. A founder asks for a one-line change, and the developer discovers the project will not build on the current Xcode, half the third-party libraries are abandoned, and the last person who understood the build settings left two years ago.
The typical warning signs are easy to check:
- The project only builds on an old Mac with an old Xcode
- Upload to App Store Connect fails with an SDK or toolchain error
- CocoaPods, Carthage and Swift Package Manager are all in use at once
- Key SDKs (analytics, ads, payments, maps) have not been updated in years
- App Review has started rejecting updates over privacy or data declarations
- Nobody on the team will touch certain screens because changes break them
If three or more apply, a planned upgrade is cheaper than continuing to patch. If the app is beyond saving, our app modernization services page covers full rebuilds and rescue work across platforms.
Apple’s current rules that force iOS upgrades
These are the platform rules we most often see blocking an update. Each one turns a routine release into an emergency if it is discovered late.
| Rule | What it requires | What breaks if you ignore it |
|---|---|---|
| Xcode 26 and the 26 SDKs | Since 28 April 2026, App Store uploads must be built with Xcode 26 or later using the iOS 26, iPadOS 26, watchOS 26, tvOS 26 or visionOS 26 SDK. | You cannot upload any update, including an urgent security fix. |
| Privacy manifests and required reasons | Since 1 May 2024, new or updated apps adding an SDK from Apple’s commonly used third-party SDK list must include privacy manifests, required-reason declarations and, for binary SDKs, valid signatures. | The upload is not accepted until every listed SDK is compliant. |
| Third-party AI disclosure (5.1.2(i)) | Apps must disclose where personal data is shared with third parties, including third-party AI, and get explicit permission first. | Older apps that quietly added an AI feature can be rejected on their next update. |
| In-app account deletion (5.1.1(v)) | Apps that allow account creation must let users delete the account from inside the app. | Older apps without a delete flow are rejected when they next submit. |
Rules are taken from Apple’s developer news and App Review Guidelines. We re-check them at the start of every upgrade, because Apple changes them during the year. For audit steps and the upload warnings to expect, read our guide to the Apple privacy manifest and required reason APIs.
How our iOS app upgrade services run, step by step
Every upgrade follows the same order. Getting the build green comes before anything else, because every later step depends on it.
Audit (about one week)
We clone your repository, try a clean build on the current Xcode and record every error, warning, deprecated API and outdated dependency. You get a written audit with a risk rating per area and a fixed price for the upgrade.
Build on Xcode 26
Raise the SDK and deployment target, fix compile errors and project settings, and set up CI with GitHub Actions or Xcode Cloud so the build stays green. The first milestone is a TestFlight build from the new toolchain.
Dependency clean-up
Consolidate on Swift Package Manager where possible, update or replace abandoned SDKs, and remove libraries the app no longer needs. Each removed dependency is one less thing to break next year.
Privacy and review compliance
Add or update privacy manifests, required-reason declarations and the App Store privacy label to match what the app actually collects after the SDK updates.
Swift 6 and concurrency
Turn on strict concurrency checks one module at a time and fix the data races they find, rather than switching the whole app at once.
UI migration where it pays
Move the screens you change most often to SwiftUI. Stable screens stay in UIKit for now.
Regression testing and release
Run the regression suite on physical devices across supported iOS versions, then ship through TestFlight and a phased release so any problem reaches a small group first.
Swift 6 and SwiftUI: part of the upgrade, not the whole of it
An upgrade usually includes the first steps of Swift 6 and SwiftUI, because they touch the same code: the Swift 6 compiler first, the Swift 6 language mode module by module, and new screens in SwiftUI hosted inside the UIKit app. The migration order, architecture rules and testing approach are on our SwiftUI app development company page, and our Swift page explains Swift 6 for buyers. Here we cover what is specific to old apps: dependencies, Objective-C and the audit.
Not sure how far behind your app is?
Give us read access to your repository. We reply within one business day, then run a clean build on the current Xcode and tell you what blocks an upload, what is risky, and what a fixed-price upgrade would include.
Moving from CocoaPods and Carthage to Swift Package Manager
Many older apps mix two or three package managers. Consolidating on Swift Package Manager (SPM) removes a whole layer of build tooling, and there is now a deadline: CocoaPods plans to stop accepting new pod versions on its central trunk from 2 December 2026, according to the CocoaPods trunk read-only plan. Existing builds keep working, but libraries distributed there will stop receiving updates through it.
Inventory every dependency
List each pod and Carthage framework with its version, its last release and whether the vendor publishes a Swift package. This list usually exposes two or three libraries nobody knew were still in the app.
Move in small batches
One dependency group per pull request, starting with libraries that ship official packages. The Podfile shrinks as packages replace pods, and CI builds the app after every batch.
Handle the awkward ones
Binary-only SDKs become XCFramework binary targets. Abandoned libraries are replaced, rewritten as a few lines of first-party code, or removed, which is often the best answer. Updated SDKs may collect new data, so the privacy label is re-checked; our guide to App Store rejection reasons shows how often that mismatch causes rejections.
Remove the old tooling
Delete the Podfile, the generated workspace, Carthage build scripts and stale build phases, then run a clean build from scratch on CI to prove nothing depended on them.
Objective-C bridging: the issues that slow upgrades
Apps started before Swift often keep Objective-C in their oldest and most important modules: payments, networking, a custom SDK wrapper. We rarely rewrite that code during an upgrade. We make the boundary between the languages safe, because that is where upgrade bugs appear.
The usual problem is code that compiles but crashes. Objective-C headers without nullability annotations import into Swift as implicitly unwrapped optionals, so a nil that Objective-C handled quietly becomes a Swift crash. Annotating the headers Swift calls is cheap and removes a whole class of bugs.
What we fix at the boundary
- Nullability annotations on headers Swift calls
- A bridging header that imports half the app, split into modules
- Swift-only types (structs, enums with values, async functions) wrapped for Objective-C callers
- Objective-C classes used across concurrency boundaries under Swift 6 checks
What an iOS upgrade audit report looks like
The audit ends with a written report. This is an illustrative excerpt showing the format, not a client’s app.
| Area | Example finding | Risk | Planned fix |
|---|---|---|---|
| Toolchain | Builds only on an older Xcode; compile errors in networking and two UI modules | High: no update can be uploaded | Raise SDK and deployment target, fix errors, CI on Xcode 26 |
| Dependencies | CocoaPods, Carthage and SPM all in use; two SDKs with no release in years | High | Consolidate on SPM; replace both abandoned SDKs |
| Privacy | No privacy manifest for a listed SDK; privacy label omits crash data | High: upload or review blocked | Update SDKs, add declarations, correct the label |
| Review rules | No in-app account deletion | Medium: rejection on next submission | Add a delete-account flow with backend support |
| Objective-C | Payments module without nullability annotations | Medium | Annotate headers Swift calls; no rewrite |
| Concurrency | Completion handlers update UI off the main thread, matching crash reports | Medium | Main-actor isolation, then Swift 6 mode per module |
| Testing | No CI and no UI tests on sign-up or purchase | Medium | CI pipeline and smoke tests before refactoring |
The real report adds a risk rating per area, the order of work and the fixed price for the upgrade.
One-off upgrade or ongoing maintenance?
An upgrade project gets you current. It does not keep you current. Apple previews new OS versions at WWDC each June and ships them in September, and the toolchain requirement moves with it, so an app that is upgraded once and left alone will be behind again within a year or two. React Native apps have an extra step; our React Native New Architecture migration guide covers it.
After an upgrade, a retainer is the simplest way to stay current. Our OS update compatibility support covers the yearly beta testing and release-day fixes, and our mobile app maintenance services cover monitoring, bug fixes and dependency updates. If you also run an Android app, the matching service is Android app upgrade and migration.
Choose a one-off upgrade when
- You have an in-house team that will maintain it afterwards
- The app is stable and changes rarely
- You need to ship one blocked update urgently
- You are preparing the app for sale or due diligence
iOS upgrades we have delivered
[[Case study: app type, client country, starting state (Xcode and Swift versions, dependency count), what we changed, and verified results such as crash-free rate or build time. Confirm with the client before publishing.]]
[[Client testimonial with name, role and company, used with written permission.]] Until these are ready, see our portfolio.
iOS app upgrade services: FAQs
Why can’t I upload an update to my old iOS app?
Most often because of the toolchain rule. Since 28 April 2026, Apple only accepts App Store uploads built with Xcode 26 or later against the iOS 26 family of SDKs. An app last built on an older Xcode has to be upgraded first, which can surface compile errors, outdated SDKs and missing privacy manifests that also have to be fixed before the upload is accepted.
How long does an iOS app upgrade take?
It depends on the size of the codebase, how far behind it is and how many dependencies need replacing. We start with an audit of about a week, which ends with a written risk report and a fixed price. A small, well-structured app can be current in a few sprints; a large app with abandoned SDKs takes longer. The audit tells you which you have.
Do we have to move off CocoaPods?
Not overnight, but plan for it. CocoaPods plans to stop accepting new pod versions on its central trunk from 2 December 2026. Existing builds keep working, yet libraries published there will stop receiving updates through it, including security fixes. During an upgrade we move dependencies to Swift Package Manager in small batches, so the app keeps building at every step and the old tooling can be removed cleanly.
What is a privacy manifest and do we need one?
A privacy manifest is a file declaring what data an app or SDK collects and why it uses certain sensitive APIs. Since 1 May 2024, apps adding an SDK from Apple’s list of commonly used third-party SDKs must include privacy manifests and required-reason declarations, and binary SDKs must be signed. During an upgrade we audit every SDK and update your App Store privacy label to match.
Can you upgrade an app another agency built?
Yes. We need read access to the repository, the Apple Developer account and any backend documentation. The audit shows how healthy the code is before you commit to anything. If the code is not in your own repository yet, we help you move it there first, because you should own it outright.
Get your iOS app current and keep it shipping
Book a 30-minute call. We will go through your app’s current state, what is blocking updates, and a step-by-step upgrade plan with a fixed price after the audit.