Why Native, and Why Swift

"A web shell reaches the platform through a bridge. A native app is already standing on it."

The Family Started on the Web

The CWK family of apps did not begin in Swift. Its first desktop tools were web interfaces wrapped in a thin native shell, and its first phone surfaces were progressive web apps reached over a private network. That was the right call at the time: one codebase, a fast iteration loop, and a browser engine that already knew how to draw text and tables.

Then the apps grew teeth. A dictation utility needed a global hotkey and the Accessibility API to insert text into whatever app had focus. A prose editor needed a real text system where Korean composition behaves exactly like it does in every other Mac app. A capture app on the phone needed the share sheet, push notifications, a widget, and a button on the watch face. Each of those is reachable from a web shell — through a plugin, a bridge, a permission workaround — and each bridge was one more place for things to go quietly wrong. One by one the apps moved to Swift: the prose editor became a native AppKit app, the terminal and the file workbench were born native, and eight apps now ship to iPhone and iPad through TestFlight.

What Native Actually Buys

The text system. NSTextView on the Mac and UITextView on iOS carry decades of input-method, spell-check, dictation and accessibility behaviour. Korean marked-text composition is not something you want to re-implement.
System citizenship. Menu-bar items, global shortcuts, LaunchAgents, URL schemes, the Accessibility API, the Keychain — all first-class, all governed by one permission model (TCC) keyed to your app's signature.
The surfaces a web page cannot own. Share extensions, App Intents and the Action Button, widgets and Live Activities, background audio, reliable push, the watch.
One language on every Apple device. The same Swift package can hold the model and the wire format for a Mac app, an iPhone app, and a watch app.

What It Costs

Native is not free. You accept Apple's toolchain and its yearly release rhythm, a UI written per platform idiom (AppKit and UIKit still matter), code signing that is part of your app's identity rather than a packaging step, and, for iPhone, iPad and Watch apps, a delivery path that runs through Apple's servers. Those costs are the reason this quest exists: every one of them is learnable, and most of them bit the family at least once before they were written down.

Why Swift, Specifically

Objective-C still runs underneath much of AppKit and UIKit, and you will meet it in delegate protocols and block types. But new Apple APIs are designed Swift-first, SwiftUI and Observation exist only in Swift, and Swift 6's compile-time data-race checking catches a class of bugs that has crashed family apps on real phones. The quest writes Swift and reads Objective-C only where the platform makes you.

Code

One decision, three shapes: the same capture app on three surfaces·text

Spark (the exercise app you will grow through this quest)

  SparkCore        Swift package: the capture model, the wire format, the outbox
  Spark (macOS)    menu-bar utility: global shortcut, signed, LaunchAgent-kept
  Spark (iOS)      one universal target for iPhone and iPad
    + SparkShare   share extension: text, links, photos, PDFs
    + SparkWatch   watch app + complication: speak, and it is safe
  engine           runs at home; every surface is a thin window onto it

Exercise

Pick an app you use every day on a Mac or an iPhone. List three things it does that a web page in a browser tab could not do on its own (think: shortcuts that work in other apps, the share sheet, widgets, text input, background work). For each, name the platform feature behind it. Then write one sentence on what it would cost that app to be a web shell instead.

Hint

Look at where the app shows up outside its own window: the menu bar, the share sheet, the lock screen, the watch face, System Settings > Privacy & Security. Each of those appearances is a platform contract.