inside the birb. preview interpreter.
a shorter path from Swift to something you can see.
birb. engineering · engineering update · 5 min readA small UI change shouldn’t require a whole build-and-install cycle before you know whether it looks right.
That’s the idea behind Local Preview in birb. Write Swift on your iPad or iPhone, keep the interface next to the editor, and see your work take shape. If you’ve used Xcode Previews, the rhythm should feel familiar. The difference is where you’re working: on the mobile device itself.
birb. already runs apps. The first iteration can run any pure SwiftUI app that doesn’t depend on additional Apple frameworks. The newest version goes further and can run apps such as BookPlayer and NetNewsWire. The September reassessment is useful background for how the engine evolved, but its older app-execution limits do not describe the current version.
The loop we’re shortening
There are two different jobs here. Local Preview lets you run and explore your SwiftUI app inside birb. A device build produces a signed app you can install and run independently. Both matter, but they shouldn’t be the same step every time you adjust a color or move a button.
If you’re using GitHub runners for builds, that means you can save full builds for changes you actually want to install. If you already own a Mac, it means you can leave it at home and keep working. And if your iPad is your main computer, it means native app development can start there.
Preview while you iterate. Build when you’re ready.A preview is a development tool. Testing the installed app is still a separate part of the workflow.
Why an interpreter?
The original preview engine lowers Swift into instructions that it executes inside the native preview host in birb. That gives edited code a route to a visible interface without creating and installing a new app for each change.
Compilation and execution are separate problems. The research has already demonstrated Swift and Clang compilation on an iPad. But producing a native executable does not, by itself, give that executable permission to run under the intended installation flow. The earlier generated-native-image experiments did not resolve that boundary.
The interpreter approach keeps edited program instructions as data that the installed runtime executes. Native UI and system-service adapters connect that execution to the device. The runtime has to preserve the program’s behavior across those boundaries: what it draws, how its state changes, and how it responds to interactions.
That last point is the hard part. Showing a view is useful, but it doesn’t prove that overloads, protocol dispatch, object lifetimes, packages, and callbacks behave the way they do in compiled Swift.
From pure SwiftUI to full apps
The first iteration: pure SwiftUI.
The first version can run any pure SwiftUI app without dependencies on additional Apple frameworks. That already makes it a place to build an interface, exercise its state, and see your code in action.
The newest version: BookPlayer and NetNewsWire.
The newest version can run apps such as BookPlayer and NetNewsWire. These are existing applications with real project structures and dependencies, beyond a standalone sample view.
This is an important step for birb. as it moves from pure SwiftUI projects to the kinds of codebases people already work on. The work now is about continuing to improve compatibility, correctness, and the development loop around that capability.
Apps are already running.Pure SwiftUI apps work in the first iteration. The newest version extends that capability to apps like BookPlayer and NetNewsWire.
What we’re working on
Running an app is the foundation. Making the experience dependable as you edit it is the continuing focus. The surrounding interpreter work concentrates on four connected areas:
- Faithful Swift behavior. Preserve the compiler’s decisions about declarations, conformances, overloads, and object ownership. Correctness matters just as much as a convincing first render.
- Native dependencies and framework integration. Continue improving the paths between Swift, C, Objective-C, C++, and native services. Exceptions, retained callbacks, and object lifetimes are part of the app’s behavior, not just details of loading its source.
- Reliable changes while an app is running. Reuse work when possible, invalidate the right dependencies, and replace an old preview safely. A callback from an earlier edit must not overwrite a newer result; a compiler error should lead to a useful diagnostic and a clear recovery path.
- A faster, steadier development loop. Keep improving preparation, edit-to-preview responsiveness, memory use, and longer sessions with real projects. Measure the whole interaction, from a saved edit to the result you can use.
BookPlayer and NetNewsWire make those priorities concrete. The question is how well the experience holds up while you keep developing an app: changing code, navigating its interface, recovering from errors, and returning to work.
The experience we’re after
Open a project. Make a change. See it. Keep going.
The rest of birb. is built around that rhythm too: an on-device agent that connects to over 50 providers, continued background tasks through BGContinuedProcessingTask when iOS allows them, and actual signed device builds when you’re ready to install. The agent runs locally; model responses come from the provider you connect.
The next phase of interpreter work is about making that short feedback loop hold up to more of the Swift and native dependencies people actually use. The goal is for your iPad or iPhone to be a place where you can build with the result in front of you.