From the engineers behind SwiftUI, Bitrig is a vibe coding app purpose-built for the Apple ecosystem. It writes native Swift, the same way a professional iOS developer would.

Since we launched Bitrig last summer, people have been asking for a Mac app. Bitrig for Mac lets you take advantage of a larger screen, full hardware keyboard, and all of the powerful technologies that come bundled with Xcode.

Bitrig for Mac compiles your code using the complete Xcode toolchain, so you have access to every framework in the iOS SDK. And it displays an inline preview of your app powered by an Xcode iPhone Simulator, so what you see matches what your users will get on TestFlight and the App Store.

The new Mac app also:

• Lets you run your app on a connected iPhone with one click
• Helps you quickly find and fix build errors
• Includes all the core features of the iPhone app, like TestFlight and App Store distribution

There’s no extra charge to use Bitrig Mac. Your subscription and credits transfer between apps, and your projects sync automatically.

One early user said, “It didn’t take long for me to switch to Mac for 90% of my iterative refinement, and just think of the iPhone app as a sketchbook for ideas.”

Ready to get started? Download the app, then follow this setup tutorial. Want to learn more? Watch this tour of Bitrig for Mac.

Rob has never been short on app ideas; he just lacked the tools to bring them to life. “I am always looking for ways to use technology to help myself and colleagues work more effectively,” he told us. “I’ve always wanted to make apps for iPhone/iPad, etc., but do not have the coding ability to do this.” Xcode was another barrier. With all its complexities, even if he learned to write the code, he was worried about using it to distribute apps.

When Rob found a YouTube video demonstrating Bitrig, his interest was piqued. As a longtime Apple fan, finding out that the Bitrig team is made up of Apple alumni sealed the deal. “Bitrig allowed me to build apps using natural language and continuously iterate them until I was ready to share,” he explained. “It’s really simple to use, and the training videos … were really helpful in building the app and getting it ready to share on App Store Connect. When I reached out to the Bitrig team for some guidance, they were really helpful and friendly.” (Thanks Rob!!)

As a geographer and educator, Rob is uniquely positioned to create an app that will help students engage and learn using tools that feel natural. His app Urban Fieldwork builds on the capabilities of the iPhone, turning a device that students already carry into a sophisticated fieldwork companion. It uses GPS to record site location, the microphone to measure sound levels, and the embedded camera to capture images. It even uses Apple’s mapping technologies to identify the category of businesses proximate to the fieldwork.

On supported devices, the app leans on Apple Intelligence for deeper, on-device analysis, helping students interpret their data. And when the work in the field is finished, everything can be exported in a clean PDF report or a spreadsheet for further study.

Urban Fieldwork has been incredibly helpful for both his students and his fellow educators. The cherry on top? “My students are definitely impressed when I show them that I’ve made an app that they can download.”

In addition to Urban Fieldwork, Rob has published SEND ToolKit, which gives teachers quick, practical guidance on supporting students with special educational needs and disabilities, all in one easy-to-access place. He also made the app Darby’s Story which uses Apple Foundation Models to generate silly bedtime stories with his son as the main character.

Rob is a fantastic example of how everyone with an idea can now make a fully native app, and we’re so lucky to have him as part of the Bitrig community. His advice? “If you have an idea for an app but lack the traditional expertise to develop an app, give Bitrig a go. Enjoy the learning process…. Have fun with it.”

Steve has always been excited to make apps, but without a technical background, the path wasn’t easy. Steve has about 10% vision, meaning he can typically see one or two letters on a screen at a time. Traditional development tools just aren’t made with someone like Steve in mind. And then he chanced across Bitrig.

Because Bitrig is fully accessible, Steve was able to hit the ground running. Dictation makes it easy to work with the AI, VoiceOver reads out the transcript, and the entire interface is designed to be navigable with assistive technology. Like SwiftUI, Bitrig was built with accessibility in mind, ensuring that everyone can create great apps that are themselves accessible.

Thanks to his passion and determination, and Bitrig’s approachable stack, Steve is now a bona fide app developer! His first app, Black Lens, which helps people with low-vision take great selfies, is available now on the App Store. “As a blind person, everything is difficult,” Steve told us. “It’s like walking around with a thorn in your paw. Bitrig is like pulling out that thorn.”

This isn’t the first time Steve has blazed a trail. He recently appeared on a reality TV show near his UK home, becoming the first blind contestant to compete. In Hunted, Series 8, he embodied the role of a fugitive, attempting to outsmart the authorities. This is a #nospoiler zone, but you can read all about Steve’s entertaining descent into a life of crime.

Steve’s journey as a developer is only beginning. Keep an eye on the App Store for more of his apps, coming soon.

Welcome to Part 3 in our series on how we built Bitrig's Swift interpreter. In Part 1, we introduced the core idea: interpreting Swift from Swift itself and dynamically bridging into existing APIs. In Part 2, we covered the mechanics of converting Swift code to bytecode. In this post, we'll explain how complex expressions are evaluated at runtime and how they connect to real system framework APIs.

Representing Methods

Our interpreter uses a stack machine to store intermediate values while evaluating expressions. We added the value stack to our interpreter last time, but we didn’t examine how it’s used.

Consider the expression "Hello " + name.uppercased(). It requires multiple evaluations that need to be combined. In pseudo-code:

valueStack.push(evaluate(name))
valueStack.push(evaluate(valueStack.pop().uppercased()))
valueStack.push(evaluate("Hello "))
valueStack.push(evaluate(valueStack.pop() + valueStack.pop()))

The stack provides a uniform place to store any number of intermediate values for any kind of expression.

Notice how the final push isn’t popped? That’s the function’s return value.

Next, let’s look at how we evaluate more complex expressions like name.uppercased().

The first step is to add instructions for encoding this into the bytecode stream:

extension [Bytecode] {
    mutating func appendMethodCall(
        base: ExprSyntax, method: DeclReferenceExprSyntax, arguments: LabeledExprListSyntax
    ) {
        base.appendBytecode(&self)
        appendMethodName(method.baseName.text)
        var argumentCode: [Bytecode] = []
        for argument in arguments {
            argument.expression.appendBytecode(&argumentCode)
        }
        appendInt(arguments.count)
        append(contentsOf: argumentCode)
    }
}

From Part 2, we already have functions for encoding expressions. Those functions can be used here to encode the base expression, the number of arguments, and each argument expression.

To implement appendMethodName, we assign a unique integer to every method name in the SDK and encode that into the bytestream. For example:

extension [Bytecode] {
    mutating func appendMethodName(_ name: String) {
        switch name {
        case "lowercased": appendInt(0)
        case "uppercased": appendInt(1)
        case "contains": appendInt(2)
        ...
        default: break
        }
    }
}

Evaluating Methods

To evaluate a method call, the interpreter first needs to decode its components from the bytestream:

extension Interpreter {
    func beginMethodCall() {
        guard let base = pop() else { return }
        let method = nextSymbol()
        let argumentCount = nextInt()
        var arguments: [Argument] = []
        arguments.reserveCapacity(argumentCount)
        for _ in 0..<argumentCount {
            if let arg = pop() {
                arguments.append(Argument(value: arg))
            }
        }

        evaluateMethodCall(base: base, method: method, arguments: arguments)
    }
}

Then it can call into the corresponding framework API:

func evaluateMethodCall(base: InterpreterValue, method: Int, arguments: [Argument]) -> Any? {
    switch method {
        case 0: // lowercased
            if let value = base.stringValue {
                return value.lowercased()
            } else if let value = base.characterValue {
                return value.lowercased()
            }
        case 1: // uppercased
            if let value = base.stringValue {
                return value.uppercased()
            } else if let value = base.characterValue {
                return value.uppercased()
            }
        case 2: // contains
            if let value = base.stringValue {
                return value.contains(arguments.first?.value.stringValue ?? "")
            }
        ...
        default: break
    }
    return nil
}

This is similar to the implementation of evaluateInitializer from Part 1. The interpreter switches over the integers assigned to each method name and checks each type that has a method of the given name.

(One detail we’ve glossed over: arguments can have labels as well. Those can be handled by encoding the labels and pushing or popping them on a labelStack just like the valueStack.)

Sidenote: Operators

Operators are represented and evaluated similarly to methods:

• Each operator name is assigned a unique integer
• The left-hand and right-hand sides are encoded and decoded the same way as the base and argument expressions in a method call
• The call into the corresponding framework API is evaluated by switching over the operator and checking the type

The only added complexity is operator precedence. For example, with x + y * z the interpreter must evaluate * before +. Fortunately, SwiftSyntax includes a framework that solves this!

SwiftOperators can fold a flat sequence of operators into a structured tree that respects the correct precedence:

let rawFile = Parser.parse(source: code)
let processedFile = try operators.foldAll(parser)

Once folded, operators can be handled the same way as methods.

Extracting APIs

We extract the APIs the interpreter calls from the SDK’s .swiftinterface files. These files are valid Swift code, which means we can parse them directly with SwiftSyntax. Normally, we use SwiftSyntax to convert dynamically generated code into bytecode, but here we use it to preprocess the SDK itself.

A script processes each framework’s .swiftinterface, iterates through its declarations, and generates code:

• For each type, its initializers go into evaluateInitializer.
• For each method, a case is added to evaluateMethodCall and to the lookup table used by appendMethodName.

This approach also works for Objective-C frameworks because Xcode can emit a Swift version of an Objective-C framework’s interface. Since many iOS frameworks are still Objective-C under the hood, this greatly expands what the interpreter can access.

Over the course of this series, we’ve gone from the big picture down to the nuts and bolts: starting with the idea of interpreting Swift in Swift, exploring how source code is translated into bytecode, and finally showing how expressions and APIs are resolved so real Swift code can run. Each piece—parsing, bytecode execution, and API extraction—fits together into a system that makes it possible to run Swift apps instantly, without compiling.

What I find most exciting about the interpreter are the possibilities that come from treating Swift not just as a compiled language, but as a dynamic, interpretable one. I hope this peek behind the curtain inspires you to imagine new ways of building with Swift.

Follow our updates here and on social media, and if you haven’t yet, give Bitrig a try, it’s the easiest way to see this in action.

Did you like learning about how Bitrig's interpreter works? Want to see it up close? We're hiring: join us!

To make it possible to instantly run your app, we built a Swift interpreter. But it’s an unusual interpreter, since it interprets from Swift… to Swift. One of the top questions we’ve gotten is how it’s implemented, so we wanted to share more about how it works.

Welcome to Part 2 in our series about how we built Bitrig's Swift interpreter. In Part 1, we talked about the high-level idea: interpreting Swift from Swift itself, and how we can dynamically bridge into existing APIs. But how do we actually go from a Swift file on disk to something runnable inside our interpreter?

The short answer: we build our own bytecode.

Bytecode and the techniques we're using aren't novel in the world of interpreters. But they were new to us and it was not obvious exactly how to build such a system in Swift for Swift code. If you're curious to learn how we did it, then read on!

From Source to Structure

The syntax tree that we get from SwiftSyntax includes mainly three types of elements: declarations, statements, and expressions. If you'd like a refresher on the details, check out the links. But in short:

• Declarations define things like types, functions, and variables.
• Statements describe what happens, step by step.
• Expressions are the pieces of code that actually produce values.

Declarations are what we start with, since those are the outer-most types within a Swift code document. They give us the types and functions we need, but they don’t actually do anything on their own. To actually start running some code, we have to take a function and interpret the array of statements that it contains.

To run those statements, we could walk the SwiftSyntax tree directly, but that can be slow and memory-intensive. Instead, we start by translating all of those statements into a compact intermediate bytecode.

Bytecode is just a stream of byte-sized instructions. Instead of a big, heterogeneous tree with dozens of node types, we get a flat, efficient representation that the interpreter can quickly step through.

We generate our bytecode by doing a light-weight compile of the syntax tree, where we make a runtime representation of each declaration. This representation includes an array of bytecode values for each function or computed variable it contains.

Generating Bytecode from Statements

Let’s explore how we map statements to bytecode. To start, we'll create an Operation type that represents the different types of operations we'll need the interpreter to support. These will be close to, but not 1-to-1 with, the Swift language. We can start with a few of the simpler statement types like break and continue. We'll encode each as a single byte:

enum Operation: UInt8 {
    case `break`
    case `continue`
    ...
}

Our bytecode will need additional data besides just the operations themselves (e.g. the arguments to the operations), so let's introduce a more general type for the bytecode itself:

struct Bytecode: RawRepresentable {
    var rawValue: UInt8

    init(_ operation: Operation) {
        rawValue = operation.rawValue
    }

    init(_ value: UInt8) {
        rawValue = value
    }
}

Then we can add a method to go from a SwiftSyntax statement to creating bytecode:

extension StmtSyntax {
    func appendBytecode(_ bytecode: inout [Bytecode]) {
        if kind == .breakStmt {
            bytecode.append(Bytecode(.break))
        } else if kind == .continueStmt {
            bytecode.append(Bytecode(.continue))
        } else if let statement = self.as(ExpressionStmtSyntax.self) {
            statement.expression.appendBytecode(&bytecode)
        ...
        }
    }
}

Now we can create bytecode from a function by pulling out its body's statements:

func createBytecode(function: FunctionDeclSyntax) -> [Bytecode] {
    var bytecode: [Bytecode] = []
    let statements = function.body?.statements
    statements?.appendBytecode(&bytecode)
    return bytecode
}

When the interpreter runs, it can just loop over the bytecode and switch on each operation type, which we'll examine in a bit.

Expressions

Statements are the necessary structure, but expressions are where the real action happens. Every Swift program boils down to evaluating expressions: literals, operations, function calls, member accesses, and so on. So next, we'll discuss converting expressions into bytecode.

Let’s start with the simplest expressions: literals.

An integer literal like 42 can be represented directly in the bytecode. A byte can easily represent a number, as a UInt8. To be able to represent the full 64-bit space of integer values, we'll need to combine together 8 of these UInt8s to represent all of the necessary bits. Since this means we'll need multiple bytes, we can't express this as an initializer on Bytecode, so instead we'll make an append-style method on arrays of Bytecode:

extension [Bytecode] {
    mutating func appendUInt64(_ value: UInt64) {
        // Represent the value in 8 bytes worth:
        append(Bytecode(rawValue: UInt8((value >> 56) & 0xFF)))
        append(Bytecode(rawValue: UInt8((value >> 48) & 0xFF)))
        append(Bytecode(rawValue: UInt8((value >> 40) & 0xFF)))
        append(Bytecode(rawValue: UInt8((value >> 32) & 0xFF)))
        append(Bytecode(rawValue: UInt8((value >> 24) & 0xFF)))
        append(Bytecode(rawValue: UInt8((value >> 16) & 0xFF)))
        append(Bytecode(rawValue: UInt8((value >> 8) & 0xFF)))
        append(Bytecode(rawValue: UInt8(value & 0xFF)))
    }
}

(Note: It's possible to optimize this more for common small integers by representing small integers within a single byte.)

With the ability to write a full 64-bit value, we can easily write Ints and Doubles into the bytecode array by just converting them into a UInt64:

extension [Bytecode] {
    mutating func appendInt(_ value: Int) {
        appendUInt64(UInt64(bitPattern: Int64(value)))
    }

    mutating func appendDouble(_ value: Double) {
        appendFullUInt64(value.bitPattern)
    }
}

With that, we have all the pieces we need to create the representations for some literal types:

extension ExprSyntax {
    func appendBytecode(_ bytecode: inout [Bytecode]) {
        if kind == .nilLiteralExpr {
            bytecode.append(Bytecode(.nilLiteral))
        } else if let value = self.as(IntegerLiteralExprSyntax.self) {
            let number = Int(value.literal.text) ?? 0
            bytecode.append(Bytecode(.integerLiteral))
            bytecode.appendInt(value)
        } else if let value = self.as(FloatLiteralExprSyntax.self) {
            let number = Double(value.literal.text) ?? 0.0
            bytecode.append(Bytecode(.doubleLiteral))
            bytecode.appendDouble(number)
        }
    }
}

Interpreting the Bytecode

Now that we have our elements built up, we can write a basic interpreter to process them. First, we'll create the interpreter type itself, which will contain an array of bytecode to interpret. Then, we'll incorporate a program counter that tells us where in the bytecode we are. Finally, we'll make a stack where we can push and pop values:

struct Interpreter {
    let bytecode: [Bytecode]
    private var pc = 0
    private var valueStack: [InterpreterValue] = []
}

The values on the stack are just the runtime values we discussed last time.

Then we can make a method to loop over the bytecode, switch over the different operation types, and process them. For the literals, we push the value they create onto our stack.

extension Interpreter {
    mutating func evaluateOperations() -> InterpreterResult {
        while let operation = nextOperation() {
            let result = evaluateOperation(operation)
            if result != .normal {
                return result
            }
        }
        return .normal
    }

    mutating func evaluateOperation(_ operation: Operation) -> InterpreterResult {
        switch operation {
        case .break:
            return .break
        case .continue:
            return .continue
        case .nilLiteral:
            valueStack.append(.nil)
            return .normal
        case .integerLiteral:
            valueStack.append(.native(nextInt()))
            return .normal
        case .doubleLiteral:
            valueStack.append(.native(nextDouble()))
            return .normal
        ...
    }
}

The result we return is just metadata about whether execution ended in any unusual way, which we need for loops, function calls, etc.

The final piece we need for the interpreter is a way to extract the necessary values from the bytecode array. This is effectively the inverse operation of what we did earlier to encode those values:

extension Interpreter {
    mutating func nextOperation() -> Operation? {
        let result = pc < bytecode.count ? bytecode[pc] : nil
        pc += 1
        return result.flatMap { .init(rawValue: $0.rawValue) }
    }

    mutating func nextInt() -> Int {
        Int(Int64(bitPattern: nextUInt64()))
    }

    mutating func nextDouble() -> Double {
        guard let value = nextUInt64() else { return 0.0 }
        return Double(bitPattern: value)
    }

    mutating func nextUInt64() -> UInt64 {
        if pc >= bytecode.count - 7 {
            print("ERROR: Attempt to read past bytecode")
            return nil
        }
        let result = UInt64(bytecode[pc].rawValue) << 56 |
            UInt64(bytecode[pc + 1].rawValue) << 48 |
            UInt64(bytecode[pc + 2].rawValue) << 40 |
            UInt64(bytecode[pc + 3].rawValue) << 32 |
            UInt64(bytecode[pc + 4].rawValue) << 24 |
            UInt64(bytecode[pc + 5].rawValue) << 16 |
            UInt64(bytecode[pc + 6].rawValue) << 8 |
            UInt64(bytecode[pc + 7].rawValue)
        pc += 8
        return result
    }
}

And now we have a working (but limited) bytecode interpreter!

What’s Next

So far we've covered how to get from source to basic, runnable bytecode. Next time, we'll look at encoding and evaluating more advanced expressions like function calls and initializers and how that ties into calling framework APIs that we saw previously.

Follow our updates here and on social media, and if you haven’t yet, give Bitrig a try, it’s the easiest way to see this in action.

Did you like learning about how Bitrig's interpreter works? Want to see it up close? We're hiring: join us!

To make it possible to instantly run your app, we built a Swift interpreter. But it’s an unusual interpreter, since it interprets from Swift… to Swift. One of the top questions we’ve gotten is how it’s implemented, so we wanted to share how it works. To make this more accessible and interesting, we simplified some of the more esoteric details. But we hope you’ll come away with a high-level picture of how the interpreter works.

The Swift project helpfully provides a way to reuse all of the parsing logic from the compiler: SwiftSyntax. This made our job a lot easier. We can easily take some Swift code and get a parsed tree out of it, which we can use to evaluate and call into to get dynamic runtime values. Let’s dig deeper.

We can start with generating the simplest kind of runtime values. For any literals (strings, floating point numbers, integers, and booleans), we can create corresponding Swift instances (String, Double, Int, Bool) to represent them. Since we’re not compiling this, we don’t know ahead of time what all the types will be, so we need to type erase all instances. Let’s make an enum to represent these runtime interpreter values (since we'll have multiple kinds soon):

enum InterpreterValue {
    case nativeValue(Any)
}

Next, we'll expand our interpreter runtime values to be able to represent developer-defined types, too. Let’s say we have a struct with two fields: a string and an integer. We’ll store it as a type that has a dictionary mapping from the property name to the runtime value. When an initializer gets called, we simply need to map the arguments to the property names and populate the dictionary.

enum InterpreterValue {
    case nativeValue(Any)
    case customInstance(CustomInstance)
}
struct CustomInstance {
    var type: InterpreterType
    var values: [String: InterpreterValue]
}

But, what happens when we want to call an API that comes from a framework, like SwiftUI? For example, let’s say we have a call to Text("Hello World"). We don’t want to rewrite all of the APIs, the whole benefit of making a native app is being able to call into those implementations! Well, those APIs are available for us to call into since the interpreter is also written in Swift (naturally!). We just need to change from a dynamic call to a compiled one. We can do that by pre-compiling a call to the Text initializer that can take dynamic arguments. Something like this:

func evaluateTextInitializer(arguments: [Argument]) -> Text {
  Text(arguments.first?.value.stringValue ?? "")
}

But of course, we need more than just the Text initializer, so we'll generalize this to any initializer we might be called with:

func evaluateInitializer(type: String, arguments: [Argument]) -> Any? {
  if type == "Text" {
    return Text(arguments.first?.value.stringValue ?? "")
  } else if type == "Image" {
    return Image(arguments.first?.value.stringValue ?? "")
  ...
}

We can follow this same pattern for all other API types: function calls, properties, subscripts, etc. The difficult part is that there are a lot of APIs. It’s not practical to hand-write code to call into all of them, but fortunately there is a structured list of all of them: the .swiftinterface file for each framework. We can parse those files to get a list of all of the APIs we need and then generate the necessary code to call into them.

One interesting thing about taking this approach to its most extreme is that even very basic operations that you might expect any interpreter to implement, like basic numeric operations, can still call into their framework implementations. So this kind of interpreter doesn’t know how to calculate or evaluate anything itself, and is really more of a glorified foreign function interface, but from dynamic Swift to compiled Swift.

One last important challenge is how to make custom types conform to framework protocols. For example, how do we make a custom SwiftUI View? Well, at runtime, we need a concrete type that conforms to the desired protocol. To do this, we can make stub types that conform to the protocol, but instead of having any logic of their own, simply call out to the interpreter to implement any requirements. Let’s look at Shape, a simple example:

struct ShapeStub: Shape {
    var interpreter: Interpreter
    var instance: CustomInstance

    var layoutDirectionBehavior: LayoutDirectionBehavior {
        instance.instanceMemberProperty("layoutDirectionBehavior", interpreter: interpreter).layoutDirectionBehaviorValue
    }
    func path(in rect: CGRect) -> Path {
        let arguments = [Argument(label: "in", value: rect)]
        return instance.instanceFunction("path", arguments: arguments, interpreter: interpreter).pathValue
    }
}

Coming back to View, this works the same way, with a little extra complexity because of the associated type that we have to type erase:

struct ViewStub: View {
    var interpreter: Interpreter
    var instance: CustomInstance

    var body: AnyView {
        instance.instanceMemberProperty("body", interpreter: interpreter).viewValue
            .map { AnyView($0) }
    }
}

And now we can make views that have dynamic implementations!

That’s a broad survey of how the interpreter is implemented. If you want to try it out in practice, download Bitrig!

If there’s more you want to know about the interpreter, or Bitrig as a whole, let us know!

Did you like learning about how Bitrig's interpreter works? Want to see it up close? We're hiring: join us!