iOS holds 58% market share in North America. App Store consumer spend reached $89.3 billion in 2025. The iOS developer market is one of the most concentrated high-value engineering segments in software — the combination of Apple’s platform constraints, the performance expectations of premium users, and the revenue density of the App Store creates a specific set of engineering requirements that generalist software engineering does not address.
The iOS platform in 2026 is in a significant technical transition. Swift 6’s strict concurrency model is the largest change to the language since Swift was introduced in 2014. SwiftUI has crossed the maturity threshold to become the default UI framework for new development. Kotlin Multiplatform (KMP) has crossed its own maturity threshold to become a viable shared-logic strategy. And the EU’s Digital Markets Act has forced Apple to support alternative app distribution in the EU — the first structural change to iOS distribution in the App Store’s history.
Swift 6: What the Concurrency Overhaul Actually Means
Swift 6 was released with Apple’s 2024 toolchain and became the default language mode for new Xcode projects in 2025. The defining change: strict concurrency checking by default. In Swift 5.x, data race safety was opt-in; in Swift 6, the compiler enforces it for all code.
The practical consequence: codebases migrating from Swift 5.x to Swift 6 mode encounter compiler errors at sites where they previously relied on informal concurrency conventions that were not enforced. This is a migration cost — significant for large codebases — but the outcome is a language where data races are a compile-time error rather than a runtime crash that is difficult to reproduce and diagnose.
The performance improvement measured in benchmarks: approximately 30% improvement in compute-intensive tasks compared to equivalent Swift 5.x code, due to the combination of strict concurrency allowing better compiler optimization (knowing that data is not shared means it can be kept in registers and cached more aggressively) and continued improvements to the Swift runtime and stdlib.
The concurrency model specifics matter for iOS engineers:
Actors. Swift actors protect state by serializing access — only one task can access an actor’s state at a time, enforced by the compiler. This is the replacement for manual dispatch_queue management and DispatchQueue-based concurrency. The @MainActor attribute marks code that must run on the main thread (UI updates), and the compiler verifies that main actor code is not called from non-isolated concurrent contexts.
Structured concurrency. async/await with TaskGroup provides structured concurrency — a task hierarchy where parent tasks track child tasks, cancellation propagates, and the execution lifetime of concurrent work is explicit. This replaces the implicit task tracking of completion handler chains, where tracking which work is in-flight was the programmer’s responsibility and cancellation required explicit management.
For teams maintaining Swift 5.x codebases: the migration to Swift 6 strict concurrency is not required immediately, but the incompatibility grows as third-party dependencies update to Swift 6 mode. Planning the migration now — incrementally adopting Swift 6 mode per-module using the swift6 compiler flag, fixing concurrency errors module by module — is less disruptive than a forced migration when a critical dependency drops Swift 5.x compatibility.
SwiftUI: The Default UI Framework
SwiftUI is now the default UI framework for new iOS development. UIKit remains supported and appropriate for specific scenarios, but the balance has shifted: SwiftUI is what Apple’s own apps and documentation target, SwiftUI is what new Xcode project templates produce, and SwiftUI’s capabilities have closed the gap with UIKit sufficiently that the remaining UIKit-only scenarios are specific rather than general.
What SwiftUI enables:
Multi-platform UI from a single codebase. SwiftUI code targeting iOS runs on iPadOS, macOS (via Mac Catalyst or native macOS target), watchOS, tvOS, and visionOS. The adaptation is not complete — each platform has distinct interface idioms that SwiftUI does not abstract away — but the shared view hierarchy and state management reduce per-platform development cost compared to separate UIKit/AppKit codebases.
Declarative state-driven UI. SwiftUI’s declarative model — views are functions of state, and the framework manages the reconciliation between state changes and rendered UI — eliminates a large category of manual UI update bugs. The UIKit pattern of maintaining view state in view controllers alongside model state, and manually synchronizing them, produced a class of bugs that SwiftUI’s model eliminates structurally.
iOS 26 Liquid Glass. Apple’s 2026 design language — Liquid Glass, introduced with iOS 26 — shifts the visual paradigm toward translucency, dynamic material, and physics-driven transitions. SwiftUI 6 includes native Liquid Glass materials via .glassEffect(), dynamic adaptation to background content, and physics-based spring animations that match the new design language. Apps using custom UIKit-based UI components face higher adaptation cost for iOS 26 Liquid Glass than apps built on SwiftUI’s native material system.
The scenarios where UIKit remains appropriate in 2026: complex collection views with custom layout (UICollectionViewCompositionalLayout with decoration views has no direct SwiftUI equivalent), highly custom animations that require frame-by-frame control, integration with low-level Core Animation, and existing large UIKit codebases where a full migration is not justified by the incremental benefit.
The practical approach for most teams: new screens in SwiftUI, UIKit where existing code is stable and migration cost exceeds benefit. UIKit and SwiftUI interoperate cleanly via UIHostingController (embedding SwiftUI views in UIKit) and UIViewRepresentable (embedding UIKit views in SwiftUI).
Kotlin Multiplatform: The Cross-Platform Architecture That Is Working
Kotlin Multiplatform (KMP) — sharing Kotlin code between iOS and Android by compiling to native frameworks on each platform — has reached production maturity and is now a viable strategy for teams that need iOS and Android apps and want to avoid duplicating business logic.
The cost reduction figure — 30–45% compared to fully separate native per-platform development — reflects the specific layer that KMP shares: business logic, data models, API clients, repository patterns, validation rules, and state management. KMP does not share UI — each platform uses its native UI framework (SwiftUI on iOS, Jetpack Compose on Android). This is intentional and is the key distinction from Flutter and React Native, which share UI at the cost of platform-native feel.
The technical mechanism: KMP code written in Kotlin compiles to a framework that can be imported as a standard dependency in an Xcode project. The Swift/iOS developer sees a standard Swift-callable API — KMP’s interop layer generates Swift wrappers that expose Kotlin APIs in idiomatic Swift. The framework handles threading, memory management, and the Kotlin-to-Swift type mapping.
What actually works well in KMP:
Data layer. Repository classes, data models, serialization/deserialization (using kotlinx.serialization), and network clients (using Ktor for multiplatform HTTP) are well-supported and production-stable. The majority of cross-platform business logic in data-centric apps fits this category.
Domain logic. Business rules, validation, state machines, and use case orchestration transfer cleanly to KMP. The logic runs natively on each platform without bridge overhead.
State management with Kotlin Flows. KMP’s StateFlow/SharedFlow interoperates with Swift’s Combine and async/await via libraries (SKIE, KMMBridge) that generate Swift-idiomatic async API surfaces from Kotlin flows. This enables shared state management across platforms without requiring the iOS team to understand Kotlin’s coroutine model.
What does not work well in KMP: anything that requires direct access to platform APIs (camera, biometrics, ARKit, HealthKit, location with full permissions) requires platform-specific implementations. KMP provides expect/actual declarations for this — each platform provides its own implementation of a common interface — but it requires careful API design to keep the cross-platform interface stable as platform APIs evolve.
For product teams deciding between KMP and React Native / Flutter: if your team has iOS and Android engineers who want to use their native platform expertise, if you need tight integration with platform-specific APIs and frameworks, or if you need the full native performance ceiling, KMP preserves native development while eliminating duplicated business logic. If your team is JavaScript-native and wants a single-language solution, React Native remains a better fit. If you need maximum code sharing including UI and have no preference for native feel, Flutter is a coherent choice.
ATT and Privacy: The Economics of iOS Advertising
Apple’s App Tracking Transparency (ATT) framework, introduced with iOS 14.5, requires apps to ask for explicit permission before tracking users across apps and websites for advertising purposes. The steady-state opt-in rate in North America: under 30% of users grant tracking permission.
The advertising revenue impact for apps dependent on personalized advertising: 58% revenue reduction from affected ad formats, according to mobile marketing platform analyses of campaigns before and after ATT. This is a structural change to the iOS mobile advertising market, not a temporary adjustment.
The engineering responses that have emerged:
SKAdNetwork (SKAN 4.0). Apple’s privacy-preserving attribution framework delivers aggregated, delayed campaign attribution data (24–72 hour delay, coarse geographic data, limited event count) without device-level tracking. Engineering teams building attribution for App Store campaigns must implement SKAN correctly — most mobile measurement partners (Adjust, Appsflyer, Branch) handle SKAN reporting, but the event taxonomy and conversion value mapping need to be designed around SKAN’s constraints.
First-party data strategy. Apps that collect first-party data directly — authenticated user accounts, preference data, in-app behavior — are not subject to ATT for their own analytics (ATT covers third-party tracking, not first-party data about users who have accounts with you). Building app analytics on your own event pipeline using authenticated user identifiers, rather than relying on IDFA-based third-party analytics, is now the standard practice for apps that want analytics that survive ATT.
Contextual advertising. App Store Search Ads (Apple’s own network) uses contextual signals rather than cross-app tracking, and is exempt from ATT. Its performance-per-dollar has improved as more advertising spend shifted to it post-ATT. Building App Store Search Ads into the UA mix — alongside optimized App Store Optimization to improve organic discovery — is the channel strategy that most iOS-first products have settled on.
EU Sideloading and the DMA
The EU’s Digital Markets Act required Apple to allow alternative app distribution in the EU by March 2024. In practice, this means:
- Notarized apps distributed outside the App Store (via alternative marketplaces or direct download) are allowed for EU users
- Apple’s notarization process reviews apps for malware and basic policy compliance, but does not apply the full App Review guidelines
- Third-party payment processors are allowed in the EU, bypassing Apple’s in-app purchase requirement
- Alternative browser engines (not WebKit) are allowed in the EU
The business implications for app developers in the EU: the 27–30% App Store commission can be avoided for EU users via alternative distribution, with Apple’s alternative fee structure (a Core Technology Fee of €0.50 per install per year for apps with over 1 million installs). For apps with large EU user bases and high revenue, the math of alternative distribution versus App Store commission needs to be evaluated against the operational cost of supporting an additional distribution channel.
The engineering implications: apps supporting EU alternative distribution need to handle differential feature availability (EU users may have access to alternative payment flows or features that global App Store policy does not permit), device and region detection for feature gating, and the logistics of notarization for non-App-Store distribution.
For teams building consumer apps primarily for the North American market, EU sideloading changes very little in the near term. For teams building B2B or enterprise apps where the App Store distribution model has historically created friction (MDM deployment, volume licensing, enterprise feature access), alternative distribution in the EU is worth evaluating.
What Senior iOS Engineers Are Actually Worth
The concentration of iOS development in premium apps — financial services, healthcare, productivity, social platforms — creates a compensation market that reflects the revenue density of the App Store. Senior iOS engineers (5+ years, Swift 6 proficient, SwiftUI-native, with App Store submission and performance optimization experience) command $180,000–$250,000+ total compensation in the US market in 2026.
The scarcity is not just credential scarcity. Senior iOS engineers who understand the full production stack — Core Data (or SwiftData) performance, memory management with ARC in concurrent contexts, Instruments profiling for identifying memory leaks and frame drops, TestFlight deployment, App Store Review requirements and the strategies for navigating them — are less common than the total iOS developer headcount suggests. The iOS developer population includes a large proportion of developers who learned SwiftUI in 2021–2022 and have not shipped high-scale production apps.
For engineering leaders evaluating iOS team capacity: the specific questions that separate senior iOS capability from iOS familiarity are performance-related (how do you identify and fix scrolling performance issues in a SwiftUI List with complex cells?), concurrency-related (how do you structure a feature that requires background data sync to not block the main actor?), and App Store-related (what are the most common reasons an app update is rejected during App Store Review, and how do you handle them before submission?).
How we approach this at Insoftex
iOS engineering is a domain where we apply Swift 6’s strict concurrency model as the default for new projects — the discipline of making data isolation explicit at the compiler level catches issues that would otherwise surface as hard-to-reproduce runtime crashes in production. For clients migrating existing Swift 5.x codebases, we scope the Swift 6 migration as a distinct workstream with a module-by-module approach rather than a flag-day rewrite.
For clients evaluating KMP for iOS and Android development, we run a technical spike during the Product Pilot — implementing the data layer and one representative feature — to validate that the specific API integration requirements and platform features the product needs work correctly with KMP before committing the architecture to it. KMP is production-ready for the common case; the unusual cases need validation before architecture commitment.
The App Store is one of the most competitive product distribution environments that exists. The iOS engineering quality that supports a successful App Store presence — performance that satisfies premium user expectations, reliability that survives App Store Reviews without rejection cycles, optimization for Apple’s recommendation and search algorithms — requires engineers who have operated at that level, not just written iOS code.
Building an iOS app from scratch or scaling an existing iOS engineering team? Our Scale service places senior iOS engineers with Swift 6 and SwiftUI production experience. Most clients start with a Product Pilot to assess architecture fit and scope before team buildout.