Swift WASM

Hold on. I'm still, like, too tickled to actually make enough words out of my mouth.

What's up, everybody? Welcome to the compiles riff podcast. Yes. We we nailed it. We got it.

We've been practicing. It's taken a little while. This episode, we are gonna be talking about SwiftWASM or depending on how you wanna pronounce it. But first of all, Geoff, how are doing, buddy? What's 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 gonna talk about tonight.

We are. You have been playing with some something that I've not messed around with at all. So I'm gonna have questions. Unsurprisingly, you are gonna 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 put in.

Yeah. Like like 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. Right? That that's how

it works. Yeah.

That's what I found.

Ask me anything. I gotcha.

There you go. Alright. 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 I do two joke streams a year. Do my annual April Fools Day stream and my annual Halloween stream where I I do something a little bit ridiculous. And several years ago, was like, oh, I'm gonna show everybody how to build a app for Windows in Swift.

And I I 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 gonna 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 Yeah. I was gonna say not to be confused. We're we're not saying server side. Right?

Let me

be Not server side. No. This is client side Swift on the in the browser. Anyway, so the shenanigans around the 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 that was the It's horrible, you know, mad science way of building a Windows app in Swift and something akin to Swift UI at the time.

I I mean, if that doesn't scream performance, I don't know what does for

it. Fantastic. Anyway, so that was 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 production yet. And there wasn't too much effort behind it, and and it seemed like it was just like, okay.

This is kinda it's fun to see, but it's not really serious yet.

And to be clear, this is an open source project. Right? Yeah. Yeah. Yeah.

This was an open source project that some people were kinda just patching together to to get it to work. Anyway, fast forward to last Friday, and in and and, you know, this is gonna 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 who it is.

Of course not. Yeah. Using SwiftWasm. And so I took a look at that, and it seems like they've improved a lot of the problems that existed with SwiftWasm in the past, and we'll get into what those problems are and how they fix them. But 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 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 gonna talk about.

Alright. 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 and and, I guess, making that sort of an official part of the platform, which is nothing but good news in in my opinion. I you know, I'd love Swift everywhere. I'm sure most of us would.

But this is not part of that project. Right? This was this is a separate thing still, but it just happens to now be part of the official tool chain. Did I 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 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 tool chain, and they are working towards everything that they need to make it a fully supported platform. It's just not there yet.

Got it. Still nothing but good news, though. Yeah. Any direct any movement in any of these directions, I think, is a good thing personally. You know, people anytime you I feel like we can project Swift as the Swift language and somewhat

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, 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 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 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 a a little side note there. All those people out there that are like, you know, and every other day it's us too, x code. Yeah. You don't need it for this. Yep.

You you not only do you not need it, you actually cannot use it for this yet. If you Oh, interesting. 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 this is kind of where I was like, this is not not a % official yet. Okay.

You install the official Swift compiler tool chain, And that's the same Swift compiler tool chain that you would use on Linux. That's the same Swift compiler tool chain you would use anywhere else. It is coming from swift.org. It's it's the standard Swift tool chain. However, none of this works with the tool chain 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, you know, kinda like RVM or PYM 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. Yep. 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 tool chain for doing any of this development. It was it was all done inside Emacs with the eGLUT and Swift LSP work to give me, you know, autocomplete, stuff like that. And, yeah, it worked great.

Hey, folks. If you like what you're hearing in this podcast and you wanna 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/compileswift, 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 go to swift.org. You download it from there, following the instructions for your appropriate platform, I'm guessing, and then code editor of choice. Did I miss anything? I mean, that sounds pretty pretty straightforward.

No. No. That that that's basically right. Yeah. Go install Swiftly, the new Swift version manager.

Link in the show notes, folks.

That's 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 gonna install the latest version for You don't have to pick a special SwiftWasm 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 in it, 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 wanna build this for Wasm. And it just goes ahead and runs that build, And you have a dot WASM file there.

Okay.

And then you need a different tool. This is where it gets a little bit complicated, is you need a different tool to run WASM code locally. I've 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 WebAssembly code and on the command line, basically.

Okay. So when you did this, when you were trying this out earlier today as we're recording this, how did you run it then? You was you you and we'll get into what you built. But you were running it at the the terminal as a terminal app then? Or because I I I saw a screenshot that you shared.

So at some point, you

Most so the very first version of it that I built was just, you know, the the bog standard hello world

Mhmm.

Command. It's literally what's what's very neat is the documentation for SwiftWasm has you change zero Swift code whatsoever. You literally run Swift package in it. That gives you a standard hello world program. That just gives you a standard hello world program.

You know, if you run this on your 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 WebAssembly.

Okay.

And so then, yeah, you talked about where am I actually running this. They do link to another tool called WasmTime, and that tool is there to run WebAssembly code on the command line and use 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. Alright. 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 wanna 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 the timeline, but maybe I'll try and make that happen. Moving on, you've got all your tools installed, you had everything else ready to run. You ran the Hello World, and everything was good.

So tell us what you actually, you know, built with it and and as an exploration here. I guess you were doing this as forgive me if you already mentioned it, but 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 a little more, man.

Like, we ever need excuses as developers. Right? You know? Like, oh, look. Shiny light.

Let's install it.

Yeah. So yeah. I 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. 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 as a bridge between the two to essentially, what, add the interaction between the Wasm and and the browser? Is that

correct? Yeah. There 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. Good.

Perfect. That was gonna be my next question because I'm sure, like, everybody, I'm like, oh god. Now I gotta write JavaScript, but the answer is no.

The the the answer, you do need to write two lines of JavaScript. You you and Even I can do

that without That's true. There you are. Yeah. Yeah.

Yeah. One thing that you do need from the website is you need the actual 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 inside 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, run. 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 gonna be essentially, you know, whatever you wanna call it in 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?

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. They actually just say NPX serve a thing. 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.

It's like Python dash m simple HTTP server and then host everything in a certain folder. You you need something that can just

host Serve up a page. Files in a folder. Got

it. You you don't you don't need to build yeah. You don't need to build anything with Express or you anything like that. You don't need a whole back end server. You just need, can I run can I host basic HTML files?

Like, that that's like Well, that's good. I used one called I used one called Kadi. I it's my favorite. It's just, like, super simple to use and super performant. You just install it.

You say caddy file server. Boom. You're done and it's hosted.

Okay. So don't wanna 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 dot JS file and a dot HTML file. That's that's your distribution.

Like Okay. That's all

you need. Enough. Yeah. Alright. Alright.

Sorry. Yeah. I distracted you there. So, yeah, back to to what you were building. Go go for it.

Yeah.

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 command line working and then get 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 as you would expect in 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, 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 SwiftWasm?

Well, the other thing there too is 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, you know, having 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 you had to rewrite? Because I mean, is swift at the end of the day.

Right? Alright. 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 any of 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 gonna give you one free bag of coffee by going to peterwhidom.com/coffee. 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 gonna go to to PeterWhidom.com/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 so many good coffees that I just would never have come across, heard about, or experienced without this service. Trade coffee is 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 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. I've 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 PeterWhidom.com/coffee. Get your free bag of coffee today. If you're a coffee lover, you're gonna really appreciate this service. I have been using it for years at this point and thoroughly recommend it.

Yep. 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 gonna 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 past. Link in the show

notes. 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 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 encoding of the barcodes. Okay. So I encoded the barcodes down to basically vector drawing calls.

And then turning those vector drawing calls into an actual display, 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.

Cool.

On the app itself, those vector drawing calls then get turned into SwiftUI, uses SwiftUI's paths and rects and all of that in order to render it out on the screen. In 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 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 HTML.

And it works. And it displays the barcode in a web browser.

Great. Yeah. No. Actually, so you essentially removed a step. Right?

Yeah.

Yeah. I really did. Yeah. Because I I was already rendering it to SVG in order to then convert that SVG to PNG. And probably couldn't do that in the local browser because, you know, where are you writing that temporary

PNG to? Yeah.

Yeah. 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 I 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 what are we talking here then? Like, two, three hours from from beginning to Yeah.

Two two hours two hour yeah. 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 ninety 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 gonna name names. I can guess who it was. And does the number four seventeen? Exactly.

So I mean, honestly, that that does go into something else that I did work. The PDF four seventeen code for rendering barcodes sorry. PDF four seventeen is a type of barcode. You've seen it on the back of your driver's license. If you have a driver's license, you know what it looks like.

We're not gonna get into the complicated ways of rendering that barcode. 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 BigInt library so that I can handle gigantic numbers. And all of that code, all I did was just say, This is a dependency for my app, my SwiftWasm app. And it was able to pull in those dependencies and compile them for SwiftWasm 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 and, you know, you did say that when you essentially initialize a project for this, it's kind of by way of, creates, what, a Swift package. So does this can I use Swift packages, you know, from Swift package management so on? I can just pull those in like I would any other dependency even.

Assuming that that's That's what

the it's just that they don't rely on any Apple frameworks that only run on iOS or whatever. Yeah. As long as they are PureShift frameworks that you can pull in with Swift Package Manager and run them on an arbitrary OS. Yeah. They just work.

Nice. So follow-up question to that. Because we're not using, we have the benefit of not using Xcode and the downside, which is we don't have the debugger, how is your debugging experiences with this? Presumably using like you said, you used Emacs, but my code editor of choice, how what's the debugging experience like?

Yeah. So I I know they do have a pretty cool looking Chrome extension for debugging WebAssembly code for debugging, specifically Swift WebAssembly code. Okay. And it looks like you can set breakpoints. It looks like you can view the stack trace, etcetera, etcetera.

I did not have cause to use that in this stream because mostly all of the code that I had was already existing code, so it was already debugged. I got all the bugs out of it, you know, when I read

it Yeah.

Several months ago. So I wasn't doing anything complicated enough or new enough in this to need a debugger right now. It does look like they have a fairly cool debugging system, but yeah, I did not have time to get into it.

So it sounds like then, and this is just an observation from the outside, it sounds like if you're someone who's familiar with debugging web code, I mean, Chrome tools, right, probably familiar territory for those kind of folks. But

we we

don't know for sure, but it sounds like if you're doing that in the Chrome DevTools, you're probably on a home turf there. Yeah.

Yeah. And, I mean, it like I said, it it looks like you can do everything that you would do with normal web code. You just do it in dot Swift files instead. Set breakpoints, print stuff, do whatever you want.

Alright. So you had a good successful experience. You you got your app working and everything else. Are there any gotchas or or downsides? And I get it.

You're you're obviously not looked into everything on this. But from your sort of early status of 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 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 network requests and whatnot. The other thing that's really missing is any sort of multithreading support. So you have the Swift async await concurrency stuff, but it's all still jumping around on a single thread. Okay.

So there's no real multithreading in SwiftWASM. Code that you've written that is using async await, it will technically work. It's gonna be slower. It's gonna not really

Won't be performant?

It's not it's not going to be actually concurrent, I guess, 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 any 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 gonna happen.

No. It it it will just fail.

Okay. That's what I was gonna ask. It's like, you don't wanna deploy it and, like Yeah. Am I just assuming that it's working?

No. No. No. It it'll fail. Okay.

Cool. Time for a break.

Hey, everybody. It's Peter Widom here from the compulsive podcast. I wanna tell you about Setapp. Setapp is a service that provides a subscription fee of just $10 a month, and you get access to over 200 Mac applications, and it's also available now on iOS as part of that deal. I use the service because it just has a ton of really good first rate apps that I use all the time.

And 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 Setapp 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 PeterWidham.com, p e t e r w I t h a m Com forward / 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 that's the the that's the stuff that's missing. Is it is things like that. The other big one that's missing that I 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 multithreading stuff. Nothing's like counting ticks in

the background.

Yeah. But, yeah, that's just unavailable. So that that one's also not available there. And so that would kind of a bummer if you're relying on that to to do stuff.

That that actually is quite a big one. 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 SwiftWasm, 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 take a guess at the file Oh, gosh.

Okay. So I'm gonna go what I think would be like a real outside number and say 400 k. It's like a crazy number.

You're off by a couple or order of magnitude? Yeah.

Oh my god. Really?

That was 62 megabytes. Oh, okay. That's

Crunch that cell phone network.

They have have, theory, fixed this using the newly supported relatively newly supported Swift for embedded frameworks. So Okay. 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 FlappySwift project that I mentioned at the top of the stream, that was only a hundred k Okay. Which is still large, but not unreasonable large, especially for a full game

being there. Right.

Yeah, it 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 it's a little ridiculous.

So You know what, though? I'm gonna give them I'm gonna give them the now here of, okay. It's not early days, but fair to say optimization has not been a priority. But I am surprised that a lot of these things, these kind of tools in that now, when they do an export release build, they do a lot of crunching to reduce the file size. But maybe they've just chosen to focus on either 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 works.

Definitely download and cache that file. Right? Damn. Yeah. Jeez.

Okay. Well, that that definitely counts as a downside, but maybe only in the near future. Next couple of years. Alright, anything else that we've not covered on this? Would you recommend okay, so

I do recommend checking it

was gonna say, recommend checking it out. Clearly sounds like it's like, you probably don't wanna 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 Like, you you can get that into, 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. It might be worth looking into. Like I said, that one that I saw that kick started this again, 100 k for an actual game that you can play in your browser.

Not bad. 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 I I'm excited about it, at least.

Cool. I mean, I don't know about JavaScript frame. You know, I've noticed that there's people are reluctant to invent JavaScript frameworks. So I I don't know if that'll happen, but maybe.

Sure.

Oh my gosh. That'd be a hundred by next week. Yeah. Alright. Cool.

This has been fascinating, Geoff. I 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 wanna 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, Geoff, where can folks find you?

You can find me, as always, on cocoatype.com.

There you go. And you can find me

Got links to all the places.

Yep. And you can find me at peterwitham.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 wanna 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/compileswift, 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.