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 NativeTwo worlds and the boundary between them: the new architecture, what crosses it, and why that crossing is the cost.JSIFabric
- FlutterDrawing every pixel itself rather than using platform widgets — what that buys in consistency and costs elsewhere.Widget treeDart
- iOS / SwiftAutomatic reference counting is not a garbage collector: retain cycles, and where SwiftUI puts the boundary.ARCSwiftUI
- Android / KotlinThe lifecycle as the platform’s central fact: your process can be killed at any point, and the state has to survive it.LifecycleCompose
- PWAThe service worker as a programmable network proxy — what a web app can and cannot reach without a store.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 28 topics — architecture, the browser, five backend runtimes, 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.