Hi HN! We're back with another post describing more detail about how we built Bitrig's interpreter for Swift in Swift, this time going into how we're converting the code into bytecode.
Yeah there was definitely some back and forth about it before we were eventually approved.
In a sense, this isn't very different from what React Native does (run interpreted code that calls out into native code), just with Swift instead of JavaScript. There used to be JavaScript-specific requirements in the guidelines, but that has been loosened since Swift Playgrounds was released. Now there are Python IDEs, Jupyter Notebooks, and other apps running arbitrary code in the App Store.
There's definitely a cost: everything is type-erased and there's a lot more indirection than there would be if the code was compiled. But you usually don't hit performance issues because most app code (especially in the UI) is just a thin layer calling into the OS frameworks. The framework code does the heavy lifting and is all compiled.
The places you can hit performance issues are things like when the app itself has a tight loop that's doing a lot of work.
I refer to Swift as a "compiled language" because no officially provided interpreter exists for it.
Bitrig runs Swift apps which are dynamically generated by an LLM on the iPhone, despite the iPhone strict security provisions (e.g. inability to write executable pages of memory). The way we do this is by parsing the generated Swift code and mapping that to the compiled calls to the libraries that come in the OS. It's pretty weird, but we think it's worth it to get the ability to immediately render the generated code on the phone.
That's not really been something we'd been considering, but yeah I think we probably could. We're primarily using the interpreter to render SwiftUI views, but it supports running arbitrary Swift expressions or statements.
Yeah you could! The only caveat is that either the whole app, or at least the part of the app showing the view you want to replace, would have to be running via the interpreter.
We're very interested in using the interpreter to improve the Swift developer experience in more ways like that.
Thanks! Yes, it works just as well with UIKit. Fortunately Xcode can synthesize a .swiftinterface for Obj-C frameworks bridged into Swift, so we use that to generate a compiled interface for UIKit (and other Obj-C frameworks).
Hi HN! Since we launched Bitrig (https://news.ycombinator.com/item?id=45041185), we've gotten questions about how it's able to run dynamically generated Swift code. I wrote up this post to answer that. Let me know if you want to know more about any aspects of it.
Yes, we think that could be a really cool way to allow mocking up changes to parts of an app, especially for non-technical members of the team. We're not set up for that yet, but it's on our roadmap.
Thanks, we'll have to update the Contact Us link to work more generically. The Send Feedback link is when you're inside of a project, and you tap the ... in a circle button. It uploads your feedback and code directly to us, so is the best way for us to directly debug when we're not rendering your code correctly.
I'll take a look at camera access and see what's going wrong there.
Yeah this is an area we want to make a lot better. What we're currently thinking is giving the model a way to more explicitly call out that it is adding a call to something that needs an API key, which would add something to the UI to allow you to just paste in your key.
I think there's also work when need to do in the system prompt to guide the model away from all of the placeholder data (or at least so that when it adds it there's a better affordance to transform it to real data).
Yeah that’s been my experience too. You can edit the Swift code directly in bitrig, though editing code on a phone is not the best experience. We’ve had a lot of requests for a Mac app. Stay tuned ;)
You can get a compiled build of your app from bitrig: go to Distribute App which will build your app on our server and then upload it to TestFlight for you (this requires a paid Apple Developer Account). This lets you install the compiled app on your Home Screen. You could also always export the code if you want to build it yourself.
There’s still a lot to do to make this work really great for the Swift ecosystem, and that’s where we have the most expertise, so that’s what we’ll be focused on for now.
That said, we think this same approach could work really well on Android, and it’d be interesting to expand there too.