DevelopmentSubsection
Mobile
Five ways to put software on a phone, each defined by the hard limit its platform imposes rather than by its API surface. Battery, memory pressure, a lifecycle that can kill your process at any moment, and a store that decides when your fix ships. Those constraints are what differ between the five, and they are what should decide the choice — the language rarely does.
What is inside
Every page in this group, with what each one covers.
- React NativeWhat keeps moving when JavaScript is busy, the New Architecture, the limits of over-the-air updates — and why Shopify went back to native.JSIExpo
- FlutterWhat Flutter draws and what it must ask the platform for, the 16 ms frame budget, rebuilds — and why iOS 26’s redesign passed it by.ImpellerDart
- iOS / SwiftSixteen references an iOS app holds and what frees each, who owns SwiftUI state, Swift 6 concurrency — and the seven-day phased release.ARCSwiftUI
- Android / KotlinSixteen events that destroy a screen and what survives each, coroutine scopes, Compose’s three phases — and Google Play’s 2026 calendar.LifecycleCompose
- PWASixteen capabilities platform by platform, the update that never arrives, caching and eviction — and what Apple permits.Service workerOffline
Where to start
- Choosing an approachRead React Native and Flutter together — they make opposite trades on the same problem, and the contrast decides it.
- Going nativeStart with the platform constraint — ARC on iOS, the lifecycle on Android. Both explain more crashes than the frameworks do.
- Maybe you do not need an appPWA. It is worth knowing exactly what the web can reach before committing to a store release cycle.
Elsewhere in the section
- DevelopmentSoftware development is the work of deciding where the boundaries in a system go, what runs on each side of them, and what moving one of those boundaries will cost once the code is live. This section covers 30 topics — architecture, the browser, seven backend languages, four mobile platforms, language models and the databases underneath all of it. Every page turns on the constraint that actually separates the options, rather than on the API surface.
- FrontendThe code that runs in somebody else’s browser, on hardware you did not choose, over a network you cannot rely on. Five topics: the platform itself, the language it runs, and the three frameworks that solved the same problem — keeping a screen in step with data — in three genuinely different ways. Each framework page is about its update model rather than its syntax, because that is what you actually have to reason about when something renders twice.
- ArchitectureWhere to put the boundaries, and what each boundary costs. Four topics: the two shapes a system can take, the migration between them that most teams attempt at the wrong moment, and the contract that makes any boundary usable by somebody else. The recurring theme is that a boundary is not free — it buys independence and charges you in latency, debugging and operational surface.
Found this useful?
Share it with someone who is working on the same problem.