Objective-C iOS modernization
Nobody starts a new iOS app in Objective-C. Plenty of apps that still earn money were started in it, and the useful question is whether you keep that codebase running, move it onto Swift, or replace it.
01Capabilities
Four ways an app like this stays alive
This page is not an argument for writing new Objective-C. New iOS work goes to Swift, and if a rebuild is on the table the native-versus-cross-platform question belongs on iOS and Android. This page is about an app you already depend on, which is the honest reason anyone reads it.
- Publishable
Keeping it accepted by the store
New Xcode and SDK versions, deprecated Apple interfaces, privacy manifests and data-collection disclosures, and dependencies that stopped being maintained years ago. Long-lived operational apps, the sort logistics teams run every shift, end up here. Ongoing ownership of that is maintenance and support.
- Migration
Moving onto Swift a module at a time
Objective-C and Swift call each other in both directions, so migration happens module by module with a shippable app at every step. We start where you are already changing code, because that is the migration you were half paying for anyway.
- Assessment
A written read before you spend
What the app actually does, what is genuinely broken, which business rules exist only in this codebase, and whether migrating, repairing or replacing is cheaper. Where that verdict has to be independent of whoever would do the work, it is a quality audit rather than an opinion.
- Exit
New features written on the way out
Building the new work in Swift alongside the existing code, behind a boundary we choose deliberately, rather than adding another year of Objective-C to a surface you want to shrink. That is legacy modernization applied to a phone.
02Fit
Deciding between another year and an exit
Objective-C is not deprecated, and your app is not broken because it is written in it. What makes these codebases expensive is people, dependencies and tooling drift rather than the language itself. So the right move depends almost entirely on how much you still need to change the app. Four of the six rows below end in less work than you probably came for, and two of those name no page of ours at all.
| Your situation | What we recommend |
|---|---|
| It is stable, it builds on current tooling, and you have few changes planned | Leave it aloneA migration with no change pressure behind it is spend with no return. We would rather say that than sell you a project. |
| It no longer builds on a current Xcode, or nobody can produce a signed release | Fix shipping firstNothing else is decidable while you cannot get a release out, and this is usually smaller work than it feels like. |
| You are already modifying a module for other reasons | Move that moduleOnto Swift, as part of the change you were making anyway. You are paying for the testing either way, which makes it the cheapest migration available. |
| You want the whole app rewritten in Swift as a single project | We argue againstA rewrite turns a working app with known bugs into a new app with unknown ones, and your store rating absorbs the difference. |
| Small app, a thin client over an API, and the interface is being redesigned anyway | Rebuild insteadMigrating code you are about to throw away is work you pay for twice. Here rebuilding genuinely can beat migrating. |
| You also need the app on Android now | Different decisionNot a migration at all. Start at iOS and Android, where Flutter and React Native become real candidates. |
Scope
What we own is the recommendation, including the version where the answer is to do nothing, and the shape of the migration if there is one. In practice that means keeping the app shippable throughout, and not leaving you stalled halfway between two languages, which is worse than either end. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries. The work runs under an ISO 27001:2022 certified information-security management system. Where the sensible destination is a stable mixed codebase rather than pure Swift, we will say that too, in writing.
03Delivery
Making change safe before making changes
The order matters more here than on new work. The first job is to make a change safe to attempt, not to start attempting changes.
- Get it building and shipping on current toolingCurrent Xcode, current SDK, working signing, and a real build distributed to testers before we touch behaviour. Until you can release, every change is a guess, and on a neglected app this step alone tells you a great deal about the condition of the codebase.
- Write down what it actually doesTests around the flows that pay, written against the app's behaviour today rather than against what the documentation claims. On an old iOS codebase the code is the specification, and this is the difference between a modernization and an outage with a project plan attached.
- Set the boundary, then migrate by moduleWhich module goes first, how the two languages are allowed to call each other, and where the line sits after each step. We migrate where the change is needed rather than alphabetically, and the app stays releasable the whole way. Every step meets our QA and test automation practice.
- Name the end state out loudFully Swift, or a stable mixed codebase we stop at deliberately. Both are legitimate. Naming which one you are aiming at is what stops a migration quietly running out of budget at sixty percent, with nobody willing to own the rest of it.
04Stack
What an ageing iOS app sits beside
The four pages this decision can end at, whichever of the three answers you land on.
05Questions
What owners of these apps ask before spending
Answered the way we would answer them on a call. If yours is not here, it is a good first message.
Our iOS engineers work in Objective-C and can join your team to do it. What we will not do is quietly staff more Objective-C feature work without first asking whether it belongs in Swift, because the direction is worth more to you than the hours. Design review comes from an architect outside the delivery team, under the same QA practice as our own projects. Team extension is managed teams.
No. Apple still compiles it, the platform frameworks are still callable from it, and a well-behaved app can keep shipping for years. The pressure is practical rather than technical: fewer engineers want to work in it, some libraries you depend on have gone Swift-only, and new Apple features arrive with Swift-first interfaces. That is a slow squeeze rather than a deadline, so we would rather help you time the move.
Incrementally, in nearly every case where the app is substantial and in daily use. The two languages mix well enough that you never need a single cutover, and each migrated module ships on its own. If priorities change you stop with a working app rather than a half-built one. A full rebuild is defensible when the app is small, or when the interface is being redesigned anyway.
Sometimes, and it turns on two things: whether you need Android as well, and how much the app touches the device. If you need both platforms and the app is mostly screens over an API, one cross-platform rebuild can beat migrating iOS and then building Android. If it leans on Bluetooth, the camera or background location, you would write native code anyway. We work through this on iOS and Android.
A scoping call with an engineer, and for an existing app we ask for read access to the repository beforehand. The first two things we look for are whether it builds on a current Xcode and how much test coverage exists, because those change the recommendation more than anything you could tell us in a meeting. What comes back is written. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based and quoted per project, offered once the first read is done. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Still shipping an app nobody wants to open?
Send us the repository and tell us what you need to change. You will get an engineer's read on whether to migrate it, repair it or replace it. That includes the answer where you spend nothing.