Complete Mobile Tutorial

Mobile development punishes a habit that server-side work tolerates: assuming the thing you need is already there. A backend process starts, loads its config, and runs. A mobile screen is built, torn down, rebuilt on rotation, suspended when a call comes in, and restored from a snapshot hours later — and every one of those transitions can hand your code a widget that no longer exists, a field that was never assigned, or a value the platform swears is non-null but isn't.

That is why almost every error in this track is a lifecycle error wearing a framework's costume. Flutter calls it setState called after dispose. Kotlin calls it lateinit property has not been initialized. Swift calls it unexpectedly found nil while unwrapping an Optional. Three languages, three stack traces, one root cause: code ran at a moment the author did not picture. Learn to read the moment and the fixes stop feeling like guesswork.

The four moments where mobile code breaks

Before reaching for a fix, place the failure on the lifecycle. Nearly every crash in this track lands in one of four windows, and the window tells you which fix is the correct one rather than the one that merely silences the log.

The pattern is worth internalising because it generalises. A crash in the third window is never fixed by a null check — a null check there just converts a loud crash into a silent no-op while the leak that caused it stays. The fix is to cancel the work when the owner dies.

Null safety is a contract, and the platform boundary breaks it

Kotlin and Swift both have real null safety, and both punch a hole in it at exactly one place: the boundary with code the compiler cannot see. In Kotlin that boundary is Java. A Java method returning String becomes a platform type, written String!, which Kotlin will happily assign to a non-null String with no complaint at all — and then throw at runtime when the value turns out to be null.

This is the single most surprising thing about Kotlin for engineers arriving from Java, because the crash looks impossible: a NullPointerException on a type the compiler declared could not be null. The compiler was not wrong. It was never asked.

// Java: @Nullable is absent, so Kotlin sees String! (platform type)
//   public String getDisplayName() { return null; }

val name: String = user.displayName   // compiles. NPE at runtime.

// Make the boundary explicit and the compiler starts helping again:
val name: String? = user.displayName        // honest type
val shown: String = name ?: "Anonymous"     // decision at the edge

// Or reject bad data once, loudly, where it enters:
val name = requireNotNull(user.displayName) { "displayName missing for ${user.id}" }

Layout errors are arithmetic, not taste

Flutter's yellow-and-black overflow stripe reads like a styling complaint. It is not. It is Flutter telling you that a child asked for more space than its parent offered, and that the difference is exactly N pixels. Layout in Flutter is a single pass: constraints travel down the tree, sizes travel back up, and a Row hands its children unbounded width in the main axis. A Text that never wraps plus a sibling icon can therefore exceed a phone's width with no warning until it renders.

So the fix is chosen by intent, not by trial. If the content should shrink, constrain it. If it should wrap, let it. If it should scroll, make the axis scrollable. Wrapping the whole thing in something that merely hides the overflow removes the stripe and keeps the bug.

Build-system failures: read the resolver, not the error

Gradle, CocoaPods and Swift Package Manager all fail with messages that name a symptom several layers from the cause. Minimum supported Gradle version is X is not really about Gradle: an Android Gradle Plugin version pins a Gradle version, which pins a JDK, and a plugin you added last week moved one of the three. Unresolved reference after adding a dependency usually means the dependency resolved for one source set and not the one you are editing.

The productive move with all three tools is the same: ask the resolver what it actually decided, instead of reading the failure and guessing.

# Android: what does the plugin/Gradle/JDK triangle look like right now?
./gradlew --version
./gradlew :app:dependencies --configuration debugRuntimeClasspath

# Why is this version of a library here at all?
./gradlew :app:dependencyInsight --configuration debugRuntimeClasspath \
  --dependency okhttp

# Flutter: the doctor names toolchain breakage before the build does
flutter doctor -v
flutter pub deps

# iOS: resolve and report, rather than re-running the failing build
pod install --repo-update
xcodebuild -resolvePackageDependencies -showBuildSettings | grep -i swift_version