What we use Swift for<\/h2>\n\n- Native apps for iPhone, iPad, Apple Watch, Apple TV and the Mac, with shared Swift packages for models, networking and the design system.<\/li>\n
- App extensions such as widgets, notification service extensions and share extensions, all reusing the same core modules.<\/li>\n
- SDKs you ship to partners, where a stable public API and binary compatibility matter more than internal elegance.<\/li>\n
- Existing Swift codebases that need new features, stability work or structural repair.<\/li>\n
- Objective-C apps that need modernizing, gradually and without a feature freeze.<\/li>\n<\/ul>\n
Swift also runs on Linux servers, with mature frameworks like Vapor and Hummingbird. That’s a reasonable option if your team is Swift-heavy. For most products, though, we still recommend a mainstream stack for the backend<\/a>, where hiring and hosting are simpler.<\/p>\nWriting Swift the compiler can check<\/h2>\nTypes that carry the design<\/h3>\n
Used deliberately, Swift’s type system is the best maintenance tool the language has. In practice that means:<\/p>\n![\"Task](\"https:\/\/inferne.com\/blog\/wp-content\/uploads\/2026\/09\/swift-app-development-concurrency-900x600.webp\")
<\/figure>\n\n- State is modeled with value types. Structs and enums make data flow predictable, and an enum with associated values can rule out invalid states entirely: a screen is loading, loaded with data, or failed with an error, and never a confusing mix spread across several optionals.<\/li>\n
- Network, storage, clock and analytics sit behind narrow protocols that tests can swap for fakes. Inside a feature, concrete types are fine, and we don’t add a protocol for every class.<\/li>\n
- Generics stay modest: opaque types by default, and existential types only where you really need mixed values, since existentials cost runtime performance and lose type information.<\/li>\n
- Functions use untyped throws by default and typed throws for narrow, closed sets of failures, such as in a parser. Business logic never swallows errors silently, because those errors turn into support tickets.<\/li>\n
- When the backend adds a new enum case, an older app version should degrade gracefully instead of failing to decode the entire response. We handle unknown values explicitly and test decoding against real payloads.<\/li>\n
- Macros like the one behind Observation remove boilerplate, but custom macros add build time and a learning curve, so we write our own only when the payoff is clear.<\/li>\n<\/ul>\n
Concurrency without data races<\/h3>\n
Async\/await got rid of the callback pyramid, but the bigger change is safety. Structured concurrency ties child tasks to their parent, so canceling the parent (for example, when someone leaves a screen) cancels the work beneath it. Actors protect mutable state, the main actor owns the UI, and Sendable marks what can safely cross between them. With strict concurrency checking on, a data race becomes a compile error. Recent Swift releases can also make a module default to main-actor isolation, which suits UI code and removes most of the annotation noise.<\/p>\n
In code review, we watch for a few pitfalls:<\/p>\n
\n- Actor reentrancy.<\/strong> An actor’s state can change at every await, so code that checks a condition, awaits, and then acts on the old check has a race in it.<\/li>\n
- Orphaned tasks.<\/strong> A task started in a view model and never canceled keeps working after the screen is gone. Tying work to a view’s lifetime with SwiftUI’s task modifier avoids that.<\/li>\n
- Escape hatches.<\/strong> Unchecked Sendable conformances and unsafe nonisolated state are sometimes necessary, but each one needs a comment explaining why it’s actually safe.<\/li>\n
- A busy main actor.<\/strong> Synchronous file, image or JSON work that blocks the UI belongs somewhere else.<\/li>\n<\/ul>\n
In existing code we adopt strict checking one module at a time, warnings first, with preconcurrency imports for dependencies that aren’t annotated yet. Combine still works wherever it’s used. New code tends toward async sequences and Observation, but we don’t rewrite working Combine pipelines just because they’re older.<\/p>\n
Testing that pays for itself<\/h2>\n
New tests use Swift Testing. Expectations read clearly, parameterized tests replace copy-pasted cases, and tests run in parallel by default, which quickly exposes shared mutable state in the code under test. XCTest stays for UI automation and performance tests, and the two frameworks coexist in the same target.<\/p>\n
What we test, roughly in order of value:<\/p>\n
\n- Domain logic and state machines: pricing, eligibility, validation, sync conflict rules.<\/li>\n
- View models, with injected clocks, identifiers and network responses, so tests are deterministic and never sleep.<\/li>\n
- Decoding against recorded API payloads, and database migrations against real older schemas.<\/li>\n
- Snapshots of design-system components across text sizes and appearance modes.<\/li>\n
- A thin layer of UI tests for flows that must never break, such as sign-in and purchase.<\/li>\n<\/ol>\n
Packages that don’t depend on UIKit can run their tests directly on a Mac without booting a simulator, which keeps the feedback loop short. Automated tests can’t tell you if a flow makes sense to a person, though, so our QA testers also check usability, performance and compatibility across devices and OS versions.<\/p>\n
Modularization without the ceremony<\/h2>\n
We split an app into local Swift packages in one repository: core models and utilities, networking, persistence, a design system, and one module per feature area. The app target becomes a thin layer that wires them together. In return you get faster incremental builds and previews, boundaries the compiler enforces, fewer merge conflicts between engineers, and code that extensions and other platforms can reuse.<\/p>\n
Modules have costs too. Lots of tiny ones add build-graph overhead and make small changes tedious, and dynamic frameworks slow app launch, so we link statically unless we have a reason not to. We aim for one module per feature area and per shared capability, not one per screen. Access control does real work here: internal by default, public only for deliberate API, and package access for code shared between modules of the same package. CI runs a formatter and a linter and fails on new warnings, and a dead-code scan keeps unused code from piling up.<\/p>\n
Migrating from Objective-C, one piece at a time<\/h2>\n
Rewriting a working Objective-C app in one go usually means a long stretch without new features, followed by a fresh set of bugs. Mixed codebases work well, so we migrate incrementally:<\/p>\n![\"A](\"https:\/\/inferne.com\/blog\/wp-content\/uploads\/2026\/09\/swift-app-development-objective-c-migration-900x600.webp\")
<\/figure>\n\n- Add nullability annotations and lightweight generics to Objective-C headers, so Swift sees accurate optionals and typed collections.<\/li>\n
- Write all new features in Swift.<\/li>\n
- Convert leaf code first, such as models and utilities, then services, and screens last.<\/li>\n
- Pin down behavior with characterization tests before converting anything that holds business rules.<\/li>\n
- Give frequently used Objective-C APIs proper Swift names, and expose Swift back to Objective-C only where needed.<\/li>\n<\/ol>\n
A few constraints shape the plan. A Swift package target can’t mix Swift and Objective-C sources, so mixed code either stays in the app target or gets split into single-language packages. Swift-only constructs such as structs, enums with associated values and generic types are invisible to Objective-C, which means shared interfaces stay simple until both sides are Swift. Old runtime tricks like method swizzling need careful review. If the project still depends on CocoaPods, the move to Swift Package Manager belongs early in the plan. And for C++ cores, Swift’s direct C++ interoperability often removes the need for an Objective-C++ wrapper layer.<\/p>\n
When native Swift app development is the right choice<\/h2>\n
Native Swift fits Apple-first products, apps that depend on deep platform integration or demanding performance, products spanning several Apple devices, and codebases expected to last for years. It’s also the right call when you already have a working Swift or Objective-C app that should be improved and extended rather than replaced.<\/p>\n
It isn’t right for every product. If you need iOS and Android at the same time, with shared UI and a small team, React Native<\/a> is often the better trade. If you want to share business logic with Android but keep native UI on both, Kotlin Multiplatform with SwiftUI on the Apple side is a credible middle path. Our native mobile app development<\/a> article covers the wider decision between native and cross-platform.<\/p>\nWith an existing app, we usually start with a focused codebase audit. It covers build times, crash and hang data, concurrency warnings, test coverage of critical paths and dependency health, plus a security review of secrets handling, Keychain use and network settings. You get a written report with prioritized recommendations, and then we either fix things alongside your team or take the work over.<\/p>\n
Frequently asked questions<\/h2>\nShould we rewrite our Objective-C app in Swift?<\/h3>\n
Rarely all at once. Migrate incrementally, starting with the parts that change most often, and leave stable Objective-C code alone until you have a reason to touch it.<\/p>\n
Is Swift the same thing as SwiftUI?<\/h3>\n
No. Swift is the language, and SwiftUI and UIKit are interface frameworks you use from Swift. A codebase can be modern, well-tested Swift with UIKit screens. Plenty of good ones are.<\/p>\n
How much work is strict concurrency checking for an existing app?<\/h3>\n
It depends on how much shared mutable state the code has and how it’s modularized. We estimate it after an audit, then adopt it module by module so feature work can continue in parallel.<\/p>\n
Can you work with our in-house iOS engineers?<\/h3>\n
Yes. We can pair on a migration, review pull requests and set up CI and modules, and your team ends up owning code they understand.<\/p>\n
What does a Swift codebase audit give us?<\/h3>\n
A written account of where time and risk go: build performance, crash and hang hotspots, concurrency and memory issues, test gaps, outdated dependencies and security findings. Each item comes with a recommended fix and a rough effort estimate.<\/p>\n
Swift also runs on Linux servers, with mature frameworks like Vapor and Hummingbird. That’s a reasonable option if your team is Swift-heavy. For most products, though, we still recommend a mainstream stack for the backend<\/a>, where hiring and hosting are simpler.<\/p>\n Used deliberately, Swift’s type system is the best maintenance tool the language has. In practice that means:<\/p>\n Async\/await got rid of the callback pyramid, but the bigger change is safety. Structured concurrency ties child tasks to their parent, so canceling the parent (for example, when someone leaves a screen) cancels the work beneath it. Actors protect mutable state, the main actor owns the UI, and Sendable marks what can safely cross between them. With strict concurrency checking on, a data race becomes a compile error. Recent Swift releases can also make a module default to main-actor isolation, which suits UI code and removes most of the annotation noise.<\/p>\n In code review, we watch for a few pitfalls:<\/p>\n In existing code we adopt strict checking one module at a time, warnings first, with preconcurrency imports for dependencies that aren’t annotated yet. Combine still works wherever it’s used. New code tends toward async sequences and Observation, but we don’t rewrite working Combine pipelines just because they’re older.<\/p>\n New tests use Swift Testing. Expectations read clearly, parameterized tests replace copy-pasted cases, and tests run in parallel by default, which quickly exposes shared mutable state in the code under test. XCTest stays for UI automation and performance tests, and the two frameworks coexist in the same target.<\/p>\n What we test, roughly in order of value:<\/p>\n Packages that don’t depend on UIKit can run their tests directly on a Mac without booting a simulator, which keeps the feedback loop short. Automated tests can’t tell you if a flow makes sense to a person, though, so our QA testers also check usability, performance and compatibility across devices and OS versions.<\/p>\n We split an app into local Swift packages in one repository: core models and utilities, networking, persistence, a design system, and one module per feature area. The app target becomes a thin layer that wires them together. In return you get faster incremental builds and previews, boundaries the compiler enforces, fewer merge conflicts between engineers, and code that extensions and other platforms can reuse.<\/p>\n Modules have costs too. Lots of tiny ones add build-graph overhead and make small changes tedious, and dynamic frameworks slow app launch, so we link statically unless we have a reason not to. We aim for one module per feature area and per shared capability, not one per screen. Access control does real work here: internal by default, public only for deliberate API, and package access for code shared between modules of the same package. CI runs a formatter and a linter and fails on new warnings, and a dead-code scan keeps unused code from piling up.<\/p>\n Rewriting a working Objective-C app in one go usually means a long stretch without new features, followed by a fresh set of bugs. Mixed codebases work well, so we migrate incrementally:<\/p>\n A few constraints shape the plan. A Swift package target can’t mix Swift and Objective-C sources, so mixed code either stays in the app target or gets split into single-language packages. Swift-only constructs such as structs, enums with associated values and generic types are invisible to Objective-C, which means shared interfaces stay simple until both sides are Swift. Old runtime tricks like method swizzling need careful review. If the project still depends on CocoaPods, the move to Swift Package Manager belongs early in the plan. And for C++ cores, Swift’s direct C++ interoperability often removes the need for an Objective-C++ wrapper layer.<\/p>\n Native Swift fits Apple-first products, apps that depend on deep platform integration or demanding performance, products spanning several Apple devices, and codebases expected to last for years. It’s also the right call when you already have a working Swift or Objective-C app that should be improved and extended rather than replaced.<\/p>\n It isn’t right for every product. If you need iOS and Android at the same time, with shared UI and a small team, React Native<\/a> is often the better trade. If you want to share business logic with Android but keep native UI on both, Kotlin Multiplatform with SwiftUI on the Apple side is a credible middle path. Our native mobile app development<\/a> article covers the wider decision between native and cross-platform.<\/p>\n With an existing app, we usually start with a focused codebase audit. It covers build times, crash and hang data, concurrency warnings, test coverage of critical paths and dependency health, plus a security review of secrets handling, Keychain use and network settings. You get a written report with prioritized recommendations, and then we either fix things alongside your team or take the work over.<\/p>\n Rarely all at once. Migrate incrementally, starting with the parts that change most often, and leave stable Objective-C code alone until you have a reason to touch it.<\/p>\n No. Swift is the language, and SwiftUI and UIKit are interface frameworks you use from Swift. A codebase can be modern, well-tested Swift with UIKit screens. Plenty of good ones are.<\/p>\n It depends on how much shared mutable state the code has and how it’s modularized. We estimate it after an audit, then adopt it module by module so feature work can continue in parallel.<\/p>\n Yes. We can pair on a migration, review pull requests and set up CI and modules, and your team ends up owning code they understand.<\/p>\n A written account of where time and risk go: build performance, crash and hang hotspots, concurrency and memory issues, test gaps, outdated dependencies and security findings. Each item comes with a recommended fix and a rough effort estimate.<\/p>\nWriting Swift the compiler can check<\/h2>\n
Types that carry the design<\/h3>\n
<\/figure>\n\n
Concurrency without data races<\/h3>\n
\n
Testing that pays for itself<\/h2>\n
\n
Modularization without the ceremony<\/h2>\n
Migrating from Objective-C, one piece at a time<\/h2>\n
<\/figure>\n\n
When native Swift app development is the right choice<\/h2>\n
Frequently asked questions<\/h2>\n
Should we rewrite our Objective-C app in Swift?<\/h3>\n
Is Swift the same thing as SwiftUI?<\/h3>\n
How much work is strict concurrency checking for an existing app?<\/h3>\n
Can you work with our in-house iOS engineers?<\/h3>\n
What does a Swift codebase audit give us?<\/h3>\n