iOS / Swift

Who owns this object

Swift has no garbage collector. Every class instance carries a count of how many strong references point at it, the compiler inserts the increments and decrements for you, and the moment the count reaches zero the object is deallocated — immediately and deterministically. That determinism is a real advantage: there are no collection pauses, memory is released the instant it stops being needed, and deinit runs at a predictable point.

The price is that reference counting cannot see a cycle. If two objects hold strong references to each other, each one keeps the other's count above zero forever, and neither is ever freed — even after everything else in the program has forgotten they exist. Nothing crashes; memory simply grows. The three places this reliably happens are a delegate pointing back at its owner, a parent and child that both hold each other, and a closure that captures self while the object holds the closure.

Two habits keep this from becoming folklore. Put a print or a breakpoint in deinit on the screens you care about while developing — if it never fires when you navigate away, you have a cycle, and you found it in ten seconds instead of in a memory graph three months later. And run the Leaks and Allocations instruments before a release; Xcode's memory graph debugger will draw you the cycle directly, arrows and all.

SwiftUI or UIKit

There are two UI frameworks on the platform and the honest position is that you need to be able to read both. UIKit is imperative: you create views, hold references, and mutate them in response to events. SwiftUI is declarative: you describe what the interface should look like for a given state and the framework works out the changes — the same mental model as React, arrived at independently.

For a new app in 2026, start in SwiftUI and drop into UIKit where you need to — the interoperation works in both directions and is a normal thing to do, not an admission of defeat. For an existing UIKit app, adding SwiftUI screen by screen is a well-trodden path and much safer than a rewrite. The thing that actually determines whether SwiftUI is available to you is your minimum supported iOS version, because the framework gained most of its serious capability after its first release.

Concurrency without the callbacks

Swift added structured concurrency and it replaced a decade of nested completion handlers with async / await that reads in order. The part that matters more than the syntax is the actor: a type that protects its own state by allowing only one task inside it at a time, checked by the compiler rather than by your discipline with locks. Data races stop being a class of bug you hunt and start being a compile error.

The one rule that never changes on this platform: UI work happens on the main thread. @MainActor says so in the type system — mark a view model with it and the compiler guarantees its methods run there. Updating a view from a background thread is undefined behaviour that usually looks like it works and occasionally corrupts the screen or crashes, which is the worst possible failure profile because it survives testing.

How this shows up in real delivery

The part that surprises teams arriving from the web is that shipping is not a deploy. A release goes through App Store review, which takes hours to days and can be rejected — most often for permission strings that do not explain themselves, for account deletion that the app must offer if it offers sign-up, for payments that route around Apple's system, or for privacy declarations that do not match what the app actually collects. None of that is arbitrary, but all of it has to be planned into the schedule rather than discovered on the release day.

Two habits shorten that loop. Ship every build to TestFlight, which is fast, gives you real devices and real crash reports, and is where you find the problems review would find. And keep the number of supported iOS versions deliberate: adoption of a new version on this platform is fast, so dropping the oldest one each year is usually uncontroversial and it is what unlocks the framework features that remove code.

Where it degrades

• Retain cycles through delegates and closures, which leak silently and never crash.
• unowned used where weak was meant, which turns a leak into a crash on a real device.
• View controllers that grow until networking, parsing and navigation all live in one file.
• UI updated from a background thread, which usually appears to work and corrupts state occasionally.
• A continuation that is not resumed on every path, leaving the caller suspended with no error.
• Permission prompts requested at launch instead of at the moment the feature needs them.
• Review requirements — deletion, privacy, payments — discovered on the day the release was due.

When to use it

Related pages

• DevelopmentAndroid / KotlinAndroid is the platform with the widest range of devices in the world and the least control over any of them. Android development is shaped less by its language than by one constraint: the system owns your app's lifetime, can rebuild your screen whenever it likes, and can kill the whole process while the user is somewhere else. This page covers the lifecycle, Kotlin and coroutines, Compose against Views, and what fragmentation actually costs.
• DevelopmentReact NativeReact Native is React, rendering real platform views instead of DOM nodes. It is not a web view and it is not a compiler to Swift or Kotlin: your JavaScript runs in its own engine and tells the platform what to put on screen. That architecture is why a web team can ship a real mobile app, and it is also the source of every performance question the framework has. This page covers the threading model, Expo, native modules, and where the illusion breaks.
• DevelopmentFlutterFlutter is Google's answer to building for several platforms from one codebase, and it takes the opposite approach to React Native: instead of asking the operating system for its widgets, Flutter ships a rendering engine and draws every pixel itself. That one decision explains the consistency, the performance, the size of the binary and the places the approach struggles. This page covers the rendering pipeline, Dart, state management, and where Flutter fits.