Swift WASM
41:05 Share

Hold on, I'm still like too tickled to actually get words out of my mouth. What's up everybody, welcome to the Compile Swift podcast. Yes, we nailed it, we got it, we've been practicing. It's taken a little while. This episode we are going to be talking about Swift Wasm, or depending on how you want to pronounce it. But first of all, Jeff, how you doing buddy? What's been going on in your world?

Hey, Peter. I've been doing just great. I've been playing with some new stuff, and I think that's what we're going to talk about tonight. We are. You have been playing with something that I've not messed around with at all. So I'm going to have questions. Unsurprisingly, you are going to be the subject matter expert on this. You are an expert by now. You had a couple of hours, right? Definitely, yeah, about three hours that I played with it.

Yeah, like all good frameworks, you become an expert once you've installed it, you've installed the packages, you've done a Hello World, you're an expert now. Yeah. Entirely, yeah. That's what I've heard. Ask me anything. I got you. There you go. All right. So tell us, what have you been messing around with today? So, yeah, this is actually something that I've played around with in the past. Several years ago, I did a...

joke stream. I do two joke streams a year. I do my annual April Fool's Day stream and my annual Halloween stream where I do something a little bit ridiculous. And several years ago, I was like, oh, I'm going to show everybody how to build a

App for Windows in Swift. And this was several years ago at this point for one of the Halloween streams. And the way that I did it was I was like, oh, I'm going to use Swift Wasm for people who are not familiar with this. This is a way of compiling Swift to run in the browser.

Okay. On the front end. Not to be confused, but I was going to say not to be confused. We're not saying server side, right? Let's be clear. Not server side. No, this is client side Swift in the browser. Anyway, so the shenanigans around the Swift for Windows app were that I was building a Swift WebAssembly app

then running it inside of Electron and running that on Windows. And that was the horrible, you know, mad science way of building a Windows app in Swift and something akin to SwiftUI at the time.

I mean, if that doesn't scream performance, I don't know what does. Fantastic. Anyway, so that was what I had played with several years ago. And I, you know, it seemed like Swift Web Assembly was an interesting project, but not really ready for production yet. And there wasn't too much effort behind it. And it seemed like it was just like, okay, this is kind of, it's fun to see, but it's not really serious yet.

To be clear, this is an open source project, right? Yeah, yeah, yeah. This was an open source project that some people were kind of just patching together to get it to work. Anyway, fast forward to last Friday, and this is going to sound silly when I was like, oh, this is what finally made it sound serious. In the wonderful iOS Dev Weekly newsletter, there was a link to a game called Flappy Swift.

which was Flappy Bird written in Swift running in the browser. Oh, shocking. Using if that's not marketing, I don't know. Of course not. Yeah. Uh, using Swift wasm. And so I took a look at that and it seems like they've improved a lot of the problems that existed with Swift wasm in the past. And we'll get into what those problems are and how they fix them. Um, but, uh,

It also turns out that there's been a lot of work in making this an official project for the Swift team. And so a lot of this has now been actually upstreamed into the main Swift compiler and being able to do a lot of this work from scratch.

a standard version of Swift whereas before it was very much you had to kind of go install your own custom tool chain this is now inside the standard Swift tool chain and so I went okay this is it seems like a lot has changed since the last time I looked at this let's go take a look at it again and see how it is these days and that's what we're going to talk about

So we know a while ago Apple was posting positions for folks who were basically interested in working with them, for them, Swift on Windows. And I guess making that sort of an official part of the platform, which is nothing but good news in my opinion. I'd love Swift everywhere. I'm sure most of us would. But this is not part of that project. This is a separate project.

But it just happens to now be part of the official tool chain. Did I understand that correctly? Yeah. This is not quite as fully supported yet as, say, Windows is as an official platform for Swift, that it's not yet an official supported build target. But it is something that they are working on getting it to that point where they are... All of the stuff to support WebAssembly is...

upstream it's all part of the main swift toolchain and they are working towards everything they need to make it a fully supported platform it's just not there yet got it still nothing but good news though yeah um any direct any movement in any of these directions i think is a good thing personally um you know people anytime you i feel like we can project swift as the swift language and

I don't want to say disassociate, but make it clear that, hey, Swift, it doesn't just mean Apple devices, right? Because that's a problem. Correct. Yeah. Yeah. And definitely, I think this is another approach to it. I mean, we've talked about Swift on the server in the past. And so with this, you can kind of have an entire front end and back end, both sides of the coin app built together.

entirely in Swift and you can have built it entirely on Linux, never touching a Mac. You can run it always only ever on Linux, never touching a Mac. And you know, everybody in the world can use this app and can have it distributed to them as long as it's just running in a browser. So there's no reason for this to touch Apple at all anymore if you really don't want to. So a little side note there is,

All those people out there that are like, you know, and every other day it's us too. Xcode. Yeah, you don't need it for this. Not only do you not need it, you actually cannot use it for this yet. Oh, interesting. If you get into the Swift developer, or sorry,

If you get into the Swift WASM documentation, one of the very first things that they do, and this is kind of where I was like, this is not 100% official yet. Okay. You install the official Swift compiler tool chain.

And that's the same Swift compiler toolchain that you would use on Linux. That's the same Swift compiler toolchain you would use anywhere else. It is coming from Swift.org. It's the standard Swift toolchain. However, none of this works with the toolchain that is distributed with Xcode yet. And thankfully, Apple's made this relatively easy in recent days. They introduced a new tool called Swiftly, which works kind of like RVM or PyEnv or any of those types of tools.

It allows you to install and manage different installations of Swift itself. And so you use that in order to install the tool chain that you need. I actually like this idea that it is separate from anything, for example, that Xcode may use. And I can manage it that way because, you know, like many of us,

have multiple versions of Xcode. It suggests that maybe I could have multiple versions of this to switch between, which again, you know, I'm actually very interested in trying this out on Linux. Something like that. I like that self-contained idea. Keeps the installation simple. Keeps cleanup simple as well, right?

Absolutely. And yeah, to further go in on this, you know, I didn't do it on Linux because I don't have a Linux install up and working that I can do development on. I think the only Linux install in my house is the Steam Deck. But I did do all of this on my Mac in Emacs. I did not use Xcode at all. I didn't use any Mac specific software.

tool chain for doing any of this development. It was all done inside Emacs with the EGLOT and Swift LSP work to give me autocomplete, stuff like that.

And yeah, it worked great. Hey folks, if you like what you're hearing in this podcast and you want to help this podcast to continue going forward and having great guests and great conversations, I invite you to become a Patreon supporter. You can go to patreon.com forward slash compile swift, where you will get ad free versions of the podcast along with other content.

Walk us through, and I'm sure it'll be quick, the very simple install process for these tools then, right? Go to Swift.org, you download it from there, follow the instructions for your appropriate platform, I'm guessing, and then code edit to your choice. Did I miss anything? I mean, that sounds pretty straightforward, right?

No, that's basically right. Yeah, go install Swiftly, the new Swift version manager. Link in the show notes, folks. That's a fairly straightforward install. Get that installed. Use that to install the latest version of Swift. In fact, actually, the first time that you run Swiftly, it just goes ahead and goes, I'm just going to install the latest version for you. You don't have to pick a special Swift WASM version. You just install latest.

And from there, it's exactly the same as building any other non-Xcode Swift package. You just run Swift package init, and that sets up a package. And then what's different to get it to build for Wasm is you just pass in a specific Swift SDK parameter, and you say, I want to build this for Wasm. And it just goes ahead and runs that build, and you have a .wasm file there. Okay. And then you need...

a different tool. Okay. This is where it gets a little bit complicated is you need a different tool to run WASM code locally. Uh, I have not yet gotten into the point where we're able to run this in a browser yet, but there are command line tools that can run, um, web assembly code and on the command line. Okay. So when you did this, when you were trying this out, um, earlier today, as we're recording this, um,

How did you run it then? And we'll get into what you built, but you were running it at the terminal as a terminal app then? Because I saw a screenshot that you shared. So at some point you...

So the very first version of it that I built was just, you know, the, the bog standard hello world command. It's literally, um, what's, what's very neat is the documentation for Swift. Has you changed zero Swift code whatsoever. You literally run Swift package in it. That gives you a standard hello world, uh, program, uh, that just gives you a standard hello world program. You know, if you run this on your, uh,

machine today in your terminal today, it will give you the same hello world. You just Swift run. It'll, it'll print hello world. All this is doing is saying, Hey, that standard package that you always get, if you just compile it with this extra flag, you'll get a version of it that you can run in web assembly. Okay. And so then, yeah,

you talked about where am I actually running this? They do link to another tool called Wasm time. And that tool is there to run web assembly code on the command line and use a command line output. That is what I did to run the original hello world project.

Not in the browser yet. Browser takes a little bit more work, but just making sure that you have built actual WebAssembly code and you are able to run this actual WebAssembly code. They have you do all of that on the command line. Okay. All right. Maybe. No promises here, folks, but...

Maybe at some point one of us will try and get a video showing how this all works. In fact, actually, it's probably a good excuse because it's been a very long time since I made a video on YouTube. And I'm actually thinking I want to try this on my Linux install on my laptop to validate why I've got it installed on the laptop. So maybe I'll try and do that. No promises on a timeline, but maybe I'll try and make that happen.

Moving on, you've got all your tools installed and you had everything else ready to run. You ran the Hello World and everything was good. So tell us what you actually built with it as an exploration here. I guess you were doing this, and forgive me if you already mentioned it, but it's kind of a proof of concept of this is a thing that could be used.

for for doing this right yeah so what did you what did you build basically just wanting to play with the technology yeah right like we ever need excuses as developers right you know like oh look shiny light let's install it yeah

So yeah, I basically just wanted to get out like, okay, let's see what I can build for the browser and see what I can run in the browser. And so that's the next step of everything is, okay, let's get this WebAssembly code and let's talk to the browser in some way. And so one current limitation of WebAssembly, and this is true whether you're writing in Swift, this is true if you're writing Python compiled to WebAssembly, any language that exists is

You do need interop with JavaScript to really control anything in the browser because WebAssembly does not have access to the DOM. And so you can't actually output anything to the browser without having some integration with JavaScript. So are we talking about like JavaScript as a bridge between the two to...

Essentially, what, add the interaction between the WASM and the browser? Is that...

Correct, yeah. There is a need for JavaScript to act as a bridge between the two. However, thankfully, the Swift WASM project has produced a Swift framework that handles a lot of that for you and kind of integrates a JavaScript bridge into Swift itself using the Swift dynamic member lookup stuff. And so you're able to have Swift code that is...

interacting with JavaScript directly. And you can...

You use this JavaScript kit, you import that, and you're then able to interact with DOM objects inside of Swift code. And so you don't actually need to write any JavaScript code in order to have that bridge there. It is all going over JavaScript. It's not compiled down to native WebAssembly in that point, but it is you yourself are not required to write any JavaScript code. Perfect. That was going to be my next question because I

I'm sure like everybody, I'm like, oh God, now I got to write JavaScript. But the answer isn't that. No. The answer, you do need to write two lines of JavaScript. Even I can do that without screwing it up. Yeah. The one thing that you do need from the website is you need the actual code.

area that you load it. And so what you do need is you need to write an HTML page, basic HTML, whatever you need there. And then it's got a script tag and in Skype, that script tag are your two lines of JavaScript. You need to import your WASM module and you need to tell that module to run. So it's basically import,

And those are the two lines of JavaScript you need to write. And after that, everything else is inside of your Swift code. Okay. So, I mean, that actually should be very familiar to just about anybody that's certainly done any web work, right? At some point, there's going to be essentially, you know, whatever you want to call it in whatever world you live, insert this between the div tags and iframe or whatever. It's kind of the same thing, right? Just inject this content here, right? Yep.

So do I need to be running a local server of some kind for this or does it just spin it up?

Um, what, what was your experience there? You do need a basic file server. It doesn't need to be anything complicated. You don't need a whole server. Um, they actually just say, uh, NPX serve a thing. Um, I don't think Python is still pre-installed on a machine anymore, but that was also a thing that you could always do in the past is like Python dash M simple HTTP server. And it would host everything in a certain folder. Um, you, you need something that can just

host files in a folder. You don't need to build anything with Express or anything like that. You don't need a whole backend server. You just need, can I run...

Can I host basic HTML files? That's all you need. Well, that's good. I used one called Caddy. It's my favorite. It's just super simple to use and super performant. You just install it. You say Caddy file server. Boom, you're done. It's hosted. Okay. So I don't want to jump ahead here, but it sounds like that will actually make distribution of this thing a lot easier as well.

Yeah, because all you have to do is be able to host a .js file and a .html file. That's your distribution. Okay, that's simple enough. Yeah, all right. All right, sorry. Yeah, I distracted you there. So yeah, back to what you were building. Go for it. Yeah, so again, mostly I was just playing with what it is that Swift was able to do. But after getting the hello world of the command line working and then getting...

and then getting a hello world in the browser working, I wanted to see, okay, what is some code that I have that could in theory just work and wouldn't require any sort of rewriting. And so I went to my app bark and I already had some code there that was running both on iOS and then also in my server on Linux. And that,

That's the barcode rendering code so that I can, A, render it on the local app, as you would expect in SwiftUI. But then I also have a different version of that that renders out to PNG so that I can generate Apple Wallet passes. And so it's like, okay, I've already got this running on iOS and on Linux on the server.

it should be fairly straightforward to have this code running in the browser as well. And that way, you know, uh, I could have a, you know, web app version of bark and have that displaying your, your barcodes. However, I don't have a real plan to do anything like that, but it was just more like, what is the code that can do something obviously cool and probably won't take too much effort to port it to Swiftplasm. Well, the other thing there too is, uh,

um when i'm playing with new technologies and that i do like to go with something that i've either built before where it's like okay i know what this thing should do and i know how i build it to do it and essentially just can i port this over to whatever this new technology is without

I happen to turn this into a project plan or anything like that because it's building what I've done before. Now, just and maybe I'm a little too early here, in which case we'll come back to it. But can you use the code from your app to in this or is it basically no, you do you had to rewrite because I mean, it is Swift at the end of the day, right?

All right here it is the one thing that I cannot do without every day and that is my coffee. Anyone that knows me or anyone that's listened to it in my podcasts or anything else knows that I absolutely cannot operate without my coffee and I love good coffee. So here's the deal I'm going to give you one free bag of coffee by going to peterwidom.com forward slash coffee and

There is a wonderful company out there that follows the fair trade practices, helps out a lot of independent roasters of all sizes, and the operation is simple. What you do is you're going to go to peterwhitam.com forward slash coffee. You sign up there. You get a free bag of coffee sent to you. Yes, in return, they say thank you to me by giving me some coffee, but that's not the reason I'm doing this. The reason I'm doing this is because I have found something

So many good coffees that I just would never have come across, heard about, or experienced without this service. Trade Coffee is just fantastic. You know, there are plenty of places out there. We all know them that supply coffee, good coffee.

You can go to the store, get the coffee, but there is nothing better than discovering new independent roasters and supporting them, discovering new flavors of coffee, new grinds for you can set it up. It's very smart. You tell it the kind of coffee you like. And over time, it gets better and better as it trains in on your selections and your choices and gives you exactly the coffee you're looking for and recommending new ones that will be very similar.

Every time I get a new packet of coffee, I go through and afterwards I try the coffee. I go through the service and I say, look, I loved this coffee. I thought this coffee was okay. Or I say, look, this was really not for me. And every time I do that, it makes the service a little more accurate on the next selection for me.

So again, just go to peterwhitam.com forward slash coffee. Get your free bag of coffee today. If you're a coffee lover, you're going to really appreciate this service. I have been using it for years at this point and thoroughly recommend it. Yeah, it is Swift at the end of the day. So the only changes that I had to make when pulling it over were removing the parts of it that were specific to other frameworks. Okay. And so...

What I'm going to say there is some parts of this code did render specifically to SwiftUI. Mostly that was not really relevant because obviously a lot of this is running on Linux, which is not there. But some of the code that was on Linux that I pulled over was directly reliant on Hummingbird code. Hummingbird being the Swift on the server framework that we've talked about in the past. And so I needed to remove any references to Hummingbird as well.

And so once I had done that, I really didn't need to do anything else. I just needed to remove, hey, this reference is SwiftUI. Hey, this reference is Hummingbird. And once I had those references removed, it more or less just worked. Okay. So if people have followed your advice in the past, not my advice, nobody ever followed my advice.

If they followed your advice in the past with separation of concerns and everything, you could potentially take the all important business logic over from whatever another platform, another app, but you could essentially work with that. Yep. And so that's what I'd done in the past. And I was already just doing some kind of like basic removed from the actual display process.

of the barcodes. So I encoded the barcodes down to basically vector drawing calls and then turning those vector drawing calls into an actual display and

That part is separated out. And so all of the stuff that encodes the code to vector drawing calls that I was able to just pull straight over on the app itself, those vector drawing calls then get turned into Swift UI uses Swift UIs paths and recs and all of that in order to render it out on the screen in SwiftUI.

my Linux code in my server side code. Sorry. I render it out to SVG and then I just take that SVG and I use a converter program on my Linux box to just convert that SVG to a PNG and use that PNG for the, the Apple wallet pass. Okay.

What I was able to do in this case was take that intermediary SVG, and because you can just put SVGs in line in HTML, I just took that SVG code that was output, sent it straight to HTML. And I said, you know, put a div in here, fill that div with this SVG. There it is. It's displayed on screen. And that just worked. I just took this SVG code that I was already...

spitting out anyway for my Apple wallet code and just put that directly on screen in, in HTML and it works and it displays the barcode in a web. That looked great. Yeah. No, actually. So you essentially removed a step, right? Um, yeah. Yeah, I really did. Uh, yeah. Cause I, I was already rendering it to SVG in order to then convert that SVG to PNG. And, uh,

uh probably couldn't do that in the local browser because you know where are you writing that temporary exactly um but yeah i could just display the svg directly because that's just html code and yeah that worked exactly as i expected awesome so um i did i did catch a little bit of the stream i was i was lurking in the background while i was eating all told what are we talking here then like a

Two, three hours from beginning to serve it up. Two hours from nothing running to displaying a barcode on the screen. And honestly, it was less than that because two hours included...

stream request to support a specific type of barcode that it was not supporting on the server side. So I would say it was probably all told maybe 90 minutes between, you know, not having touched this at all to having it installed, having done the command line, hello world, having done the browser, hello world to having a barcode on screen. And so I'm not going to name names. I can guess who it was. And does the number four 17, uh,

exactly uh so i mean honestly that that does go into uh something else that uh i did work um the pdf 417 code for rendering barcode sorry pdf 417 is a type of barcode you've seen it on the back of your driver's license if you have a driver's license uh you know what it looks like uh we're not going to get into the complicated ways of rendering that barcode um

Anyway, that code relies on a different library that I've written that I can use across iOS and Linux. And that library itself relies on somebody else's third-party library to handle – it's a big int library so that I can handle gigantic numbers –

And all of that code, all I did was just say, this is a dependency on my, uh, for my app, my Swift Rasm app. And, uh,

It was able to pull in those dependencies and compile them for Swift WASM as well. And I didn't need to do anything to those other dependencies. It just worked. I was just able to pull in standard Swift dependencies and compile them for WebAssembly and run them in the browser. Interesting. So I do want to ask a question there because you mentioned that. And you did say that when...

you essentially initialize a project for this. It's kind of by way of a creates what a Swift package. So does this, can I use Swift packages, you know, from Swift package management and so on? I can just pull those in like I would any other dependency and,

assuming that it's just assuming that they don't rely on any apple frameworks that only run on ios or whatever yeah as long as they are pure shift frameworks that you can pull in with so package manager and run them on an arbitrary os yeah they just were nice so follow-up question to that because we're not using uh we have the benefit of not using xcode and the downside is

which is we don't have the debugger. How was your debugging experiences with this? You know, presumably using, like you said, you used Emacs, but my code editor of choice, what's the debugging experience like? Yeah, so I know they do have a pretty cool looking Chrome extension for debugging,

uh, web assembly code for debugging specifically Swift web assembly code. And it looks like you can set breakpoints. It looks like you can view, uh, the stack trace, et cetera, et cetera. Um, I did not have cause to use that in this, uh,

stream because mostly all of the code that I had was like already existing code. And so it was already debugged. Uh, I, I got all the bugs out of it, you know, when I read it several months ago. Um, so I, I didn't, I wasn't doing anything complicated enough or new enough in, um, this to need a debugger right now. It does look like they have a, uh, fairly cool, uh,

debugging system but uh yeah i did not have time to get into it so so it sounds like then and this is just an observation the outside it sounds like if you're someone who's familiar with debugging web code i mean chrome tools right um probably familiar territory for the for those kind of folks but we don't know for sure but it sounds like if you're doing that in the chrome dev tools you're probably on a home turf there yeah

Yeah, and I mean, like I said, it looks like you can do everything that you would do with normal web code. You just do it in .swift files instead.

Set breakpoints, print stuff, do whatever you want. All right. So you had a good successful experience. You got your app working and everything else. Are there any gotchas or downsides? And I get it. You've obviously not looked into everything on this, but from your sort of early status of getting this and trying it out, what do you think? Are there any downsides to this that really stood out?

Yeah, so there's still quite a few limitations on the Swift code that you can write and deploy in WebAssembly. If you go look at their documentation, there's a bunch of things that they basically say, like, you can't touch this part of code. I think the big one that people would be missing is all of the networking stuff. So you don't have URL session. You don't have any of those kinds of friends you have to go through.

JavaScript bridge to do like network requests and whatnot. Um, the other thing that's really missing is any sort of multi-threading support. So you have the Swift async await concurrency stuff, but it's all still like jumping around on a single thread. Okay. Um, so there's, there's no real multi-threading in Swift WASM. So code that you've written that is using async await, it will technically work. It's, it's going to be slower. It's going to not really, um,

Won't be performing? It's not going to be actually concurrent, I guess is the thing that I'm trying to say. Any code that you've written that is depending on dispatch, for example, that just won't compile. Yeah, you do not have dispatch at all. You don't have anything like that.

Question on that then. So for things like that, I mean, will it tell you and try to help you and say, hey, this is not going to happen? No, it will just fail. Okay. That's what I was going to ask. It's like, you don't want to deploy it. And like, am I just assuming that it's working? Yeah, no, no, it'll fail. Okay. Okay, cool.

Time for a break.

I use the service because it just has a ton of really good first-rate apps that I use all the time. For me, it's invaluable as a developer to have access to tools for things like APIs, for planning projects, writing emails, writing documentation, and you get all of these things, including database apps, all of that kind of stuff right there on the Setapps service for just $10 a month. You can use as many or as few applications as you need.

If you're interested in checking this out, go to peterwhitam.com, P-E-T-E-R-W-I-T-H-A-M.com forward slash set app, S-E-T-A-P-P. And you can see the details there. And it's got a link that you can go over and start using the service and see how it works out for you. I strongly recommend this to every Mac user. Break time over.

So that's the stuff that's missing. It is things like that. The other big one that's missing that I didn't quite understand why this one was missing is Timer.

It's just missing on WebAssembly. Yeah, that one seemed weird. I don't know why that's happening. Maybe that's related to the multi-threading stuff. Nothing's like counting ticks in the background. But yeah, that's just unavailable. So that one's also not available there. And so that was kind of a bummer if you're relying on that to do stuff. That actually is quite a big one. Yeah. Yeah.

Yeah. The other big downside that I think is mostly fixed, and this is a large part of why I wanted to try this out again, but have not gotten to this yet. And this counts as maybe definitely a downside and maybe definitely partially like just a complication is in the standard build that you get from,

Swift WASM, the WASM files that it generates that people would have to download on your end are gigantic. Oh. The file that I did to display that little barcode, take a guess at the file size. Oh, gosh. Okay. So I'm going to go what I think would be like a real outside number and say 400K. Okay.

It's like a crazy number. You're off by a couple order of magnitude. Yeah. Oh, my God. Really? That was 62 megabytes. Oh, okay. That's... So, okay. Crunch that cell phone, network. They have...

They have, in theory, fixed this using the newly supported, relatively newly supported Swift for embedded frameworks. So using Swift for, say, the Arduino, any of those kinds of things.

That said, that is kind of a separate way of building things. And so it requires a lot more setup to actually make that build happen. And I did not have the time to get into that today. It does look like it is relatively possible. And the flappy Swift project that I mentioned at the top of the stream, that was only 100K. Okay. Yeah.

Which is still large, but not unreasonably large. Especially for a full game. Right, right, right. But yeah, it definitely takes a lot more setup to actually get it to that point. Whereas, yeah, the standard build, the thing that took me no time at all to get set up, 62 megs. It's a little ridiculous. You know what, though? I'm going to give them an out here of, okay, it's not early days, but...

Fair to say optimization has not been a priority, but I am surprised that, you know, a lot of these things, these kind of tools and that now when they do a export release build, you know, they, they do a lot of crunching to reduce the file size, but maybe they've just chosen to focus in on other areas at this point. Let's hope. If you do the embedded Swift tool chain, it is supposed to be much smaller. It just, that is,

not straightforward to get hooked up the way that just the standard Swift build was. Definitely download and cache that file, right? Yeah. Jeez. Okay. Well, that definitely counts as a downside, but maybe only in the near future, next couple of years. All right. Anything else that we've not covered on this? Would you recommend? Okay. So I do recommend checking it out. I was going to say, recommend checking it out.

clearly sounds like it's like you probably don't want to think about this for production heavy usage or at all at this stage is that a fair if the embedded stuff works the way that it's supposed to and you can get to the like one-off uh like you you can get that into like a build script that you can run on your ci and have it doing everything that you need to do so that you don't have to ever touch it again um

It might be worth looking into. Like I said, that one that I saw that kickstarted this again, 100K for an actual game that you can play in your browser. That's not bad. I think that's exactly right. And I mean, if you've got that all written in Swift and that's code that you can have, your standard code and you can reuse code, you can do anything like that.

I think it's worth looking into. Like I said, or like you said, it is early days. I'm sure it will evolve in the future. There's a lot of things that are manual now, like the JavaScript bridge that probably people will start building frameworks for. But I'm excited about it, at least. Cool. I mean, I don't know about JavaScript. You know, I've noticed that there's...

People are reluctant to invent JavaScript frameworks. So I don't know if that'll happen, but maybe. Sure. Oh my gosh. There'll be a hundred by next week. Yeah. All right. Cool.

This has been fascinating, Jeff. I hope we've given folks something to think about. For those of you that love to explore and play with things, like every engineer ever, I think, give it a go. Try it out. Folks, we would love to hear your thoughts on this. If you've used this tool or if you are someone working on this project, we are...

we want to throw this invite out to you. We would love to have you come on the podcast and talk about it. That would be great. Other than that, Jeff, where can folks find you? You can find me, as always, on Cocotype.com. There you go. And you can find me... Got links to all the places. Yep. And you can find me at PeterWim.com. You can find this podcast, the Compile Swift podcast...

at compileswift.com that's what we got for you folks check out the show notes there'll be a whole bunch of links in there check out the discord as well and if you want to go the extra mile and support us on patreon like so many of you folks have shout out to you you supporters thank you so much we greatly appreciate it it really does make all the difference you can go to patreon.com forward slash compile swift and

And you get an ad-free version of the podcast episodes. And sometimes we like to throw out some extras in there for you as well. Plus, of course, we've got great members over there. That's it, folks. We will speak to you in the next episode. Goodbye.