→ From Coder to Shipper
From Coder to Shipper · Rapid-fire

Mobile Dev — the phone as a platform

Your web skills, one step closer to the user's pocket: native apps (Swift/Kotlin) and cross-platform (React Native/Flutter) — same ship-it habits.

← / → to navigate · EN/VI switch below

The basics

What a mobile app actually is

Not a URL — a bundle of code + assets that lives on the device.

Installed, not visited

The app is downloaded from a store (or a link) and runs on the device itself — with or without internet.

Two roads

NATIVE: written in the platform's own language (Swift on iOS, Kotlin on Android). CROSS-PLATFORM: written once, wrapped for both (React Native, Flutter).

The same loop you know

Code → build → run on a device or emulator → see it → change it. The dev loop is identical to web — the target is just a phone.

State → screen

Same reactive idea as the web: the screen is a function of state. Change the state, the UI re-renders — whether it's a browser tab or a phone.

The split

Native vs cross-platform

The whole mobile decision in one slide.

Native — one language per platform

Swift for iOS, Kotlin for Android. Fastest, most polished, full access to every piece of hardware — but TWO codebases, two languages, two app stores.

Choose it when the platform IS the product.

Cross-platform — one codebase, two targets

React Native (JSX) or Flutter (Dart): write once, ship to both stores. About 90–95% of the native experience for most apps.

Choose it when being everywhere matters most.

01
The roads

Pick a language, pick a road

Four options cover 99% of real mobile work.

Road 1 · native

The native road — Swift & Kotlin

Swift — Apple's language

iOS, iPadOS, macOS. Modern, safe, fast; the only way to a first-class Apple app. Xcode is the IDE.

Kotlin — Android's language

The official Android language: concise, Java-friendly, null-safe. Android Studio is the IDE.

What you get

Full hardware access (camera, GPS, sensors, push), the best performance, and the store's recommended tooling.

What it costs

Two codebases and two languages for two stores — double the work, double the review queues.

Road 2 · cross-platform

The cross-platform road

React Native — JSX

Your web skills, on a phone: JavaScript + JSX rendering to REAL native widgets. Expo is the easiest on-ramp.

Flutter — Dart

Google's toolkit: a Dart codebase that draws its OWN UI (not native widgets). One pixel-perfect look on every screen.

What you get

One codebase, both stores. Hot reload: save a file and see it on the device in a second. Big, mature ecosystems.

What it costs

The last 5–10% of polish, and occasional friction with brand-new hardware features (native modules bridge the gap).

Side by side

Four options, one job

SwiftKotlinReact NativeFlutter
RoadNative (iOS)Native (Android)CrossCross
UI styleNative Apple widgetsNative Android widgetsReal native widgets via JSDraws its own UI
StoresApp StoreGoogle PlayBoth / Cả haiBoth / Cả hai
Best forPremium iOS-first productsPremium Android-first productsJS shops, fast MVPsPixel-perfect, both platforms
Core ideas

Ideas you'll meet on every road

Hot reload

Save the file → the running app updates in a second, without a full rebuild. The dev loop gets 10x faster.

Device vs emulator

An emulator is a phone inside a program — fine for most work, but battery, camera and real lag only exist on real hardware.

The build pipeline

JS gets bundled; Dart gets compiled (AOT) to machine code. The store gets a signed package: .ipa / .apk / .aab.

State → screen, again

useState in React Native, setState in Flutter: the same reactive contract you met on the web, enforced by the framework.

Play it yourself · React Native

One screen, in JSX

This is your web React knowledge — View and Text are just the app's div and p.

App.jsx
import { useState } from "react";

export default function App() {
  const [count, setCount] = useState(0);

  return (
    <View style={styles.box}>
      <Text>Tap count: {count}</Text>
      <Button title="Tap" onPress={() => setCount(count + 1)} />
    </View>
  );
}

State change → screen re-renders — the same contract as the web, now on a phone.

Play it yourself · Flutter

One screen, in Dart

Flutter builds the screen as a tree of Widgets — the UI is code, drawn by the engine.

main.dart
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Text("Hello, mobile")
      )
    );
  }
}

Scaffold → Center → Text: three widgets, one screen. That's the whole pattern.

In the terminal

Run it on a phone

Expo points your phone at your laptop; flutter builds and pushes to the device.

ops@vps — zsh
$ npx expo start
Starting project from ~/mobile-app
› Scan the QR code with Expo Go — it opens on your phone
$ flutter run
Launching lib/main.dart on Pixel 8 in debug mode...
✓ Built app/debug/app-debug.apk
← save a file: both rebuild + redeploy in seconds
The landscape

Names you'll actually meet

React Native / Expo

Meta's JS framework + the Expo toolchain — the fastest way for a JS developer to ship to both stores.

Flutter / Dart

Google's cross-platform toolkit. Backed by a big company, huge community, one consistent UI everywhere.

The stores

App Store + Google Play: review queues, signing, versioning — the shipper half of mobile. Budget a day for first submission.

The decision

Which road do you pick?

A wrong pick is a re-write; a good pick is boring.

Go native when…

One platform matters first, the product lives or dies on camera/GPS/performance, or you want the absolute last percent of polish.

Pay the price once; the other platform comes later.

Go cross-platform when…

Being on both stores on day one matters, you're a JS shop (→ React Native) or want one pixel-consistent UI (→ Flutter).

Ship faster, iterate faster — the last 5% can wait.

The edges

What we're deliberately skipping

Native modules

The JS/Dart → native bridge when the framework can't reach the hardware directly.

Push notifications

APNs/FCM tokens, permission flows, the app pokes the user — a topic with its own paperwork.

Offline & sync

Local storage, conflict resolution, going out and back — the hard 10% of real apps.

Releases & monetization

Signed builds, staged rollouts, in-app purchases, subscriptions — the shipper half of mobile.

A mobile app is just your codebase wearing a device: same state, same build-run-see loop, same ship-it discipline — the only new thing is that the user holds it in their pocket.
the big picture

One codebase. Two pockets.

You now speak every language in this course — pick one and ship.