birb.an app for iPad & iPhone

blog / a short note

inside the birb. preview interpreter

How birb. shows your Swift running without building the whole app every time. Kept short. We promise.

the idea

You change one line. You want to see it. That’s the whole thing.

Normally that means a full build, an install, and a little hunt for the screen you were on. For a padding tweak.

Local Preview skips all that. An interpreter that lives on your iPad or iPhone runs your SwiftUI inside birb. and shows a real, interactive, native preview right beside the editor. Edit, look, keep going.

why an interpreter?

Fun fact: Swift can be compiled on an iPad. The catch is running the result. iOS won’t let a freshly compiled native program run through the normal install flow. The door is shut, politely but firmly.

fig. 1 — iOS, at the door. a brand-new program isn’t on the list. birb. is, because you installed it.

So birb. keeps your edited code as data, and birb.’s own runtime runs it. That runtime came in with birb.: already installed, already allowed to run. Native UI and system-service adapters connect it to the real device, so what you’re poking at is actual native UI, not a painting of one.

  1. your Swift
  2. kept as data
  3. birb.’s runtime (already installed)
  4. real native UI
fig. 2 — the whole route, in four wobbly boxes.

does it run real apps?

It does. birb. runs SwiftUI apps, including real, existing ones like BookPlayer and NetNewsWire. (Links go to the apps’ own repos.) Not a demo we made up for the occasion: proper apps that other people wrote.

the hard part

Drawing a view is the easy bit. Being right is the hard bit.

Real Swift is full of decisions: which overload gets called, which protocol method wins, when an object goes away, how packages fit together, when callbacks fire. The interpreter has to make every one of those calls exactly like compiled Swift does, or your preview is quietly fibbing to you. A button that looks perfect but calls the wrong overload is still a bug.

what we’re working on next

Four things, in no particular order of glamour:

  1. Faithful Swift. Behave exactly like compiled Swift, all the way down. No creative interpretations. (It’s an interpreter. We had to.)

  2. Native dependencies. Swift, C, Objective-C and C++ getting along, plus exceptions, callbacks and object lifetimes. The plumbing.

  3. Changes while your app is running. Reuse the work that’s still good, redo only what your edit touched, and never let an old callback overwrite a newer result. If the compiler’s unhappy, you get a useful message and a way back.

  4. A faster, steadier loop. Less prep time, quicker edit-to-preview, less memory, and long sessions that stay smooth.

the point

The preview is for all the little “what if I nudge this” moments. Nudge away.

When you want the real thing, birb. builds and signs an IPA for your registered device with your own Apple Developer team. Install it and it runs on its own. The preview is a dev tool; the installed app is its own step.

that’s the whole post!

← all posts