iOS Development: Swift, SwiftUI & the App Store Pipeline

iOS Development

iOS development means building for Apple's mobile platforms — iPhone, iPad, and their siblings (watchOS, tvOS, visionOS) — with Swift as the language, SwiftUI as the modern UI framework, and Xcode as the (mandatory, Mac-only) toolchain. Apple's platform is a vertically integrated world: one company controls the language, frameworks, IDE, devices, and the App Store gate your software ships through.

That integration is the platform's character in both directions: native iOS apps get first-day access to every OS capability with best-in-class tooling and performance, and in exchange you accept Apple's rules — review guidelines, revenue share, yearly OS migrations, and hardware you must buy. For businesses, iOS punches above its unit share: iPhone users skew heavily toward the top of consumer spending.

TL;DR

The modern stack is Swift + SwiftUI: declarative UI (state → view, React-like), with UIKit as the imperative predecessor you'll still meet in every mature codebase.
Xcode on a Mac is non-negotiable — editor, simulator, profiler (Instruments), signing, and the only sanctioned build/submit path.
Architecture today: SwiftUI views + @Observable state models + async/await for concurrency; SwiftData/Core Data or GRDB (SQLite) for persistence.
Distribution runs through Apple's pipeline: code signing → TestFlight beta → App Store review (human review, typically ~1–2 days, with rejection as a normal planning risk).
The yearly cadence is real: each June's WWDC brings OS/API changes; apps are expected to keep pace (and can usually support ~2–3 OS versions back).
Go native for platform-heavy, performance-sensitive, or Apple-ecosystem apps; React Native/Flutter for shared-codebase products — most teams' real question.

Quick Example

A complete SwiftUI screen — state, list, navigation, async data:

Declarative UI, structured concurrency, and platform behaviors (pull-to-refresh, navigation, dynamic type, dark mode) largely for free — this is why SwiftUI ended the "iOS UIs take forever" era for standard screens.

Core Concepts

SwiftUI vs UIKit

The 2026 reality: new apps start SwiftUI, drop to UIKit via UIViewRepresentable for the occasional gap, and every established employer has a UIKit codebase you'll need to read. The interop is smooth in both directions, so this is an "and," not an "or."

State and Architecture

SwiftUI's data flow is explicit ownership:

@State — view-local value state
@Observable classes (the modern Observation framework) — shared model objects; views auto-track exactly the properties they read
@Environment — dependency injection down the tree
@Binding — two-way handles into a parent's state

On top of this, most teams run a lightweight MV(VM) shape — views + observable models + service layer — while larger apps reach for TCA (The Composable Architecture) when they want Redux-style rigor. Concurrency is Swift's structured async/await + actors, with the compiler (Swift 6 strict concurrency) enforcing data-race safety — the platform's biggest recent shift.

Persistence options in order of commonness: SwiftData (the SwiftUI-era ORM) or Core Data for object graphs, GRDB/SQLite when you want SQL, plus Keychain for secrets and CloudKit/iCloud for sync.

The Toolchain

Xcode: editor, Interface previews, simulator fleet, and Instruments — the profiler suite (time, allocations, hangs, energy) that answers every "why is it slow."
Swift Package Manager is the dependency standard (CocoaPods is legacy).
Testing: the modern Swift Testing framework (@Test, #expect) plus XCTest for UI automation; snapshot tests via community tooling.
CI: Xcode Cloud (Apple's), or GitHub Actions/CircleCI on macOS runners with fastlane automating signing, screenshots, and upload — the de facto release toolchain.

Shipping: Signing, TestFlight, Review

The pipeline every iOS team internalizes:

Planning realities: review takes hours-to-days and can reject (in-app purchase rules and privacy disclosures are the top tripwires — Apple takes 15–30% of IAP revenue and requires its payment system for digital goods, with regional carve-outs evolving under regulation). Privacy is enforced product surface: permission prompts need purpose strings, App Privacy labels are mandatory, and App Tracking Transparency gates cross-app tracking.

Native iOS vs Cross-Platform

The honest middle: cross-platform apps still need native modules and someone who understands this page — iOS knowledge is required infrastructure for RN/Flutter teams, not an alternative to it. And Kotlin Multiplatform's "share logic, keep SwiftUI" model is the rising third option for teams wanting native UI on both platforms.

Common Mistakes

Fighting the Platform's Conventions

Custom navigation stacks, hand-rolled gesture systems, and Android-patterned UI read as "wrong" to iOS users and multiply maintenance. The Human Interface Guidelines and system components encode behavior users expect (and accessibility you'd otherwise rebuild) — deviate deliberately, not by default.

Treating Signing as Voodoo

Certificates, provisioning profiles, and entitlements are learnable, and fastlane match (shared, versioned signing assets) turns the chaos into config. Teams that never systematize signing lose days per release to "works on my Mac" archery.

Ignoring the Main Thread

UI work belongs on the main actor; everything slow doesn't. Jank and hangs from synchronous I/O or heavy work in view code remain the #1 perceived-quality killer — Instruments' Hangs tool finds them in minutes.

Skipping Older-Device/OS Testing

The simulator on an M-series Mac hides what an iPhone SE on last year's OS reveals. Support a realistic OS window (current + 1–2 back), and keep one old physical device in the drawer.

Discovering Review Rules at Submission

Building a payment flow Apple's guidelines forbid, or shipping without privacy labels, costs a rejection cycle at the worst moment. Read guidelines before building monetization, and submit early builds to TestFlight external review as a dry run.

FAQ

Do I really need a Mac?

Yes — Xcode runs only on macOS and it's the only sanctioned path to build and submit. Workarounds exist (cloud Macs, CI-only building) but a local Mac remains the practical floor for real iOS work. You'll also want at least one physical iPhone; the simulator can't test cameras, push UX, or true performance.

SwiftUI or UIKit in 2026?

Learn SwiftUI first and build in it — it's Apple's clear direction and covers the overwhelming majority of app UI. Learn enough UIKit to read existing code and drop down for gaps; job listings still assume passing familiarity with both.

How long does App Store review take, and what gets rejected?

Typically under 48 hours now. Common rejections: incomplete/mislabeled privacy disclosures, in-app purchase rule violations (digital goods bypassing Apple's IAP), broken demo credentials for reviewers, and minimum-functionality complaints for thin apps. Expedited review exists for critical fixes.

Can I use AI/LLMs in iOS apps?

Yes — on-device via Core ML and Apple's Foundation Models framework (Apple Intelligence era), or server-side via any API. On-device inference is a genuine iOS strength: the Neural Engine runs quantized models with no per-call cost or data egress — with App Review's usual content rules applying to generated output.

How does iOS development pay/hire relative to cross-platform?

Native iOS remains a deep-specialization market: fewer candidates than web, strong demand at product companies that treat the iOS app as a flagship. Cross-platform (RN/Flutter) roles are more numerous but often expect native-iOS debugging ability anyway — the skills compound rather than compete.