How we built an interpreter for Swift • Hacker News Board

Re: How we built an interpreter for Swift

#21

Post by mtlynch » Thu, Sep 04, 2025, 7:55 PM UTC

jacobx wrote: post #20

mtlynch wrote: post #18

> Bitrig dynamically generates and runs Swift apps on your phone. Normally this would require compiling and signing with Xcode, and you can’t do that on an iPhone. > 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. I can't understand what they're talking about, and I don't know if it's because I know too little abou…

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…

Thanks for the reply!

I think that's a more accessible explanation. Consider folding that into the article's introduction.

Is the idea that your interpreter is signed, and then you translate the user's arbitrary unsigned Swift code into calls to other already-signed code that ships with iOS?

Re: How we built an interpreter for Swift

#22

Post by nxobject » Thu, Sep 04, 2025, 8:15 PM UTC

mtlynch wrote: post #18

> Bitrig dynamically generates and runs Swift apps on your phone. Normally this would require compiling and signing with Xcode, and you can’t do that on an iPhone. > 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. I can't understand what they're talking about, and I don't know if it's because I know too little abou…

> I also don't understand what it means to "interpret" Swift to Swift. Do they mean they compile Swift to Swift (or the more modern "transpile" which means the same thing)? But it sounds like they're doing something dynamically at runtime, so it sounds more like decompiling machine code back to Swift, but the rest of the post doesn't match that interpretation.

My understanding is that this system walks the syntax, creates autogenerated wrappers to API structures/functions, and simply invokes them as the syntax directs – as it says, a "glorified FFI". It is not a full free-standing Swift runtime, but it's a very clever hack.

Re: How we built an interpreter for Swift

#23

Post by daft_pink » Thu, Sep 04, 2025, 8:57 PM UTC

Is apple going to block this?

Re: How we built an interpreter for Swift

#24

Post by nomel » Thu, Sep 04, 2025, 9:04 PM UTC

Very very neat.

What's the performance like?

Re: How we built an interpreter for Swift

#25

Post by jacobx » Thu, Sep 04, 2025, 9:15 PM UTC

nomel wrote: post #24

Very very neat. What's the performance like?

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.

Re: How we built an interpreter for Swift

#26

Post by ks2048 » Thu, Sep 04, 2025, 9:20 PM UTC

It looks like it is in the App Store, so I guess my question is already answered - but I wonder if they had trouble or concerns getting it accepted.

Section 2.5.2 in "App Review Guidelines" (https://developer.apple.com/app-store/review/guidelines/):

    2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.

Re: How we built an interpreter for Swift

#27

Post by ardit33 » Thu, Sep 04, 2025, 9:28 PM UTC

ks2048 wrote: post #26

It looks like it is in the App Store, so I guess my question is already answered - but I wonder if they had trouble or concerns getting it accepted. Section 2.5.2 in "App Review Guidelines" ( https://developer.apple.com/app-store/review/guidelines/ ): 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute c…

yeah, this is the exception since it is a dev tool. Not sure Apple will approve a regular app doing it.

Re: How we built an interpreter for Swift

#28

Post by jacobx » Thu, Sep 04, 2025, 9:35 PM UTC

ks2048 wrote: post #26

It looks like it is in the App Store, so I guess my question is already answered - but I wonder if they had trouble or concerns getting it accepted. Section 2.5.2 in "App Review Guidelines" ( https://developer.apple.com/app-store/review/guidelines/ ): 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute c…

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.

Re: How we built an interpreter for Swift

#29

Post by zapzupnz » Thu, Sep 04, 2025, 9:36 PM UTC

daft_pink wrote: post #23

Is apple going to block this?

It's already on the App Store and meets all their criteria for a development app, so I can't see any reason why it would be blocked.

Re: How we built an interpreter for Swift

#30

Post by Rohansi » Thu, Sep 04, 2025, 9:43 PM UTC

jacobx wrote: post #28

ks2048 wrote: post #26

It looks like it is in the App Store, so I guess my question is already answered - but I wonder if they had trouble or concerns getting it accepted. Section 2.5.2 in "App Review Guidelines" ( https://developer.apple.com/app-store/review/guidelines/ ): 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute c…

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…

The root of these restrictions is to try and prevent people from using dynamic code to bypass App Store reviews. If you're planning to change the functionality of your app then you must submit it for review.