So we had a YouTube comment this week, which asked us a question, which I think we should kick off this week's show by answering it. So the comment was from Encapsulatio, or Encapsulatio, I'm not quite sure how to say that. And it's about Swift on Linux and Windows. So we talked a little bit about Swift on Windows, and I think probably a little bit about Swift on Linux in the last episode.
And this comment says, "Does Swift work on Linux and Windows just as well as on Mac when it comes to a developer experience? What about developing apps that work on Android? Can you talk about cross-platform development in Swift and also cross-platform compilation of Swift software?" So I think the answer to that is yes, we can. (laughing) Well, we can certainly try. Well, we can certainly try, yeah, exactly. So let's try, shall we? - Yeah, because can. Have we actually?
Have you made any attempts to run Swift on Windows or Android? - On Windows, no. On Android, no. On Linux, kind of. - Yeah, I feel more comfortable about that side of the fence. - Yeah, and I think that's probably potentially where we should focus, because, and I do think that the question, 'cause there was a follow-up post afterwards and it did talk about Linux specifically.
So I think the question is mainly around Linux rather than Windows and Android, but we should potentially touch on those too. - Well, the good news is if we talk about Linux, I guess a lot of it will apply to Windows because as we probably get into it fairly quickly, the primary editor on Linux is gonna be VS Code, which is a first-class citizen on Windows, right? - Exactly, yeah.
And in terms of developer experience, which is what this question is primarily about, I think that is really all we probably need to say. As far as I know, VS Code works on Linux. It certainly works on Windows. It definitely works also on Mac. - So there is a relatively official these days extension for VS Code, which I think is under the stewardship of the server work group, is it? Or is it completely independent? - It is.
I think it has moved into the official servers, Swift account and is officially maintained, I believe. - Yeah, I thought so, yeah. - And the maintainer is Adam Fowler. We should mention him because he's done a lot of work there to make that really nice. - An enormous amount of work, yeah. And yeah, so that extension is available in the VS Code extensions store, if it's called the store, but whatever you install the extensions from, it's available there.
And it comes along with a whole load of stuff by default. So it hooks into the LSP, which is the language server protocol, is it? - Yes. - Yes. - We've done our homework. - As you can tell, this podcast is excruciatingly researched. (laughing) Language server protocol, yeah. So that gives you things like completion and highlighting and that kind of stuff.
And then there's also some extras in that extension that do, for example, when you open up a Swift package with VS Code, it does a dependency resolution for you. There are also some commands in there that you can build and test your package. So I would say it's a pretty good experience. In fact, I would say it's actually getting on for a great experience to develop Swift in VS Code with that extension installed. And of course you can then do that on all those platforms, Linux, Windows, and Mac.
- Yeah, and just to extend that a bit, VS Code, I've been using it a couple of times because while we do development mainly on the Mac for the SPI server project, we deploy on Linux. So we sometimes have the need to actually run the, or compile and test on Linux, because sometimes there might be small differences or things that we're debugging that might only happen on Linux. So we have a certain need to actually run it on Linux ourselves as well, not just when we actually deploy the server.
And that's when I use VS Code and even Nova recently, because that also has now a Swift extension with LSP support. So while it doesn't have the test runner stuff, it does have the autocomplete and the pop-up stuff for the autocomplete, so that's quite nice. And VS Code brings in addition the little test runner UI, like on the Mac you have these little diamonds that you can click. I believe that also works on Linux.
I don't try that often because of the nature of things I tend to do when I get to that point, but I believe that is now supported and should be working so you can run tests that way individually or just all of them. That's quite nice. - And I think it is worth saying that, as far as I know, both of our experience with running this extension in VS Code is running the extension in the Mac version of VS Code.
And as you say, you can run those developer containers to run the software that you're working on under Linux inside a container. But certainly I haven't tried all of this in VS Code on different platforms, although I do believe it all works. - Yeah, I imagine that might even be a good way to get started on Windows while support is probably not there fully. There was just recently someone said they tried using Swift on Windows and didn't have a great experience.
And a better experience for now might be to run the same way we do on the Mac. You run VS Code and then you run a dev container with the Swift image of a Swift image as a Linux container on Windows. I would imagine that works just the same as it does on the Mac. I haven't tried that. I don't know how good the experience is in Docker for Windows, but I would imagine that would work the same way. - All of the component pieces are certainly available. - Yeah, yeah, definitely.
So that's certainly probably the easiest way to get started. And if you're worried about performance, that's actually an interesting thing I found out the other day because I ran our test suite in a Linux container on the Mac. This is an Apple Silicon Mac. And to my surprise, the tests actually run faster in the container. So in Xcode, they run in, I think, like 60 seconds and in the container, it ran in 40 or 45 or something like that. It was a noticeable difference.
- I was gonna say, that's quite a significant difference. - That's why I actually timed it because I noticed, yeah, it was really, I posted about it because I was so surprised that it was so much faster. I think it might be the terminal output. So the console in Xcode is pretty slow, I believe. And I wonder if that's the reason. I haven't actually tried running it in terminal on the Mac to see if that makes a difference. - Well, maybe rather than upgrading my Mac, I should switch to Linux.
- Well, good luck. (laughing) - Yeah, so I think, and I was gonna, so I'm glad you brought up Nova because I know you've been using it recently and I'm glad to hear that at least some of that is going across to other editors. I don't know of any others apart from VS Code and Nova. I mean, almost certainly you can get this working in Emacs because you can get anything working in Emacs, right? (laughing) But I haven't heard of any other editors that have at least advertised.
I know other editors do use the LSP, but I haven't heard of any others kind of advertising support for Swift. So if you do know of any, then please drop us a comment either on the YouTube video or actually I don't think we have comments on the podcast, do we? So yeah, if you know of any, then drop us a comment on the YouTube video. - Yeah, and I believe that there should be a fair number because LSP seems to be like the common way to do this sort of thing these days.
And that should open up support for quite a number of editors. - And like I say, there is that certainly, that LSP is in a lot of editors. But if it does more than that, because I think that's where code stands out, right? - Yeah. - So yes, thank you to Adam and everyone else who worked on the VS Code plugin because I'm sure there are more people. It's something I use, 'cause I use code to develop all the JavaScript and CSS for the package index.
And so when I'm doing that, in fact, I was doing it this afternoon, I also ran the server through VS Code. And so that's the situation in which I use VS Code kind of in anger to do real work. When I'm working purely on Swift code, I do still do it in Xcode. I find that experience is still noticeably better than VS Code, but it's certainly not something you're hobbling along with, it's a real, it does work.
- It does, and there are people, especially those who work just exclusively on Linux, who use it as an everyday tool and do say that it's working great. So I think it's a viable approach to use Swift on Linux. I don't think you're that, you can have a great experience, I believe. - Yeah, absolutely, yeah. And then the final part of the question is Android. And I am gonna basically say that I'm not very well up on making Android apps in Swift.
I know there was a project, and in fact, I'm sure that project has continued. I know there was a project that got some way towards that, but I don't know the current status of that. - Yeah, me neither. It popped up, but it was quite a while ago that there was some activity around Android support. And I don't know where that went. I don't think it's, in the hierarchy of next platforms, I believe Windows is probably the closest to seeing proper support.
And then Wasm is the other one that comes to mind. I think that's the order in which we'll see new platforms appear in our compatibility matrix for sure. - Sure, yeah. The only other thing to mention here is it's not running Swift on Android, but actually one option for creating cross-platform, at least backend logic, is Kotlin Multiplatform.
So Kotlin is the language that you might develop any Android app in, which I believe is sitting on top of Java still, but it's a very different language than Java. Much more modern, much more like Swift actually. And Kotlin Multiplatform is a technology that allows you to share Kotlin code between Swift and your Android applications. And that I believe is really quite far along. You know, that's usable. - Right, is that sort of like in spirit, like the C++ support in Swift?
Does it just mix objects and call from one language to the other, or how does that work? - Really great question, yeah. And we'll leave it there. (laughing) Really, really just a great question, yeah. - We might have more of that in the future perhaps. - I think what we're really acting as here is the inspiration to Google and go and search. - And maybe there's someone listening to this that's saying, "God damn it, I know this." - Completely uninformed podcast hosts, yes.
Actually, no, not completely uninformed, only dangerously uninformed. - Speaking of questions, Dave, how do you add a package to the Swift package index? - How do you add a package to the Swift? You go to the add a package page. - That's totally out of the blue, isn't it? (laughing) How do you add a-- - I wasn't expecting that question, but yes, you go to the add a package page. - Exactly, no one expects the Spanish inquisition. (laughing) - Is it a trick question?
- No, it is a very straightforward question, which you have actually answered recently, which is why I'm bringing it up. - Yeah, you go to the add a package page on the package index site, and that takes you to a GitHub issue that starts a workflow that adds the package to the list, and I'm completely blanking on why I might, why this might be relevant. - So you went on a competing podcast the other day, well, I listened to it. You were on the "More Than Just Code" podcast with Tim Mitra.
- I was on the "More Than Just Code," yeah, absolutely, yeah. - You were, you were, and you've been asked this very question, and I was the one listening and almost shouting, "Dave, no, it's easier, it's easier, it's easier." - What did I say?
- Well, you were kind of apologetic that it is, that it uses Git and is a bit complicated, and you said there's a button to click, and then you add the URL and stuff, and I thought this whole time, no, it's actually easier, it's actually easier than that, and I wanted to just bring that up, not to shame you or anything, because it is, that's how we-- - That's just a happy side effect, right? - (laughs) Exactly.
(both laughing) No, because I wanted to bring it up because I don't think many people know it, and it's sort of hidden, right? There is no UI for that, really, but actually, I find the easiest way, and that's how I add packages to the indexes. If you are on a GitHub page, you just replace GitHub in the URL with Swift package index, and then you land on a page which has a button, and then you just click buttons from there.
You have no typing to do whatsoever because it pre-fills the pull request that we then open with the URL already put in because you've just come from the site. So to explain what's happening there, if you replace the GitHub in the domain name with Swift package index, we go to a package page stub. We obviously don't have the package yet. Well, if we have it already, you're already done, right?
You land on the page and you see, all right, there's nothing for me to do because the package is already there.
If it isn't, instead of rendering a 404, what we do is we show a page which has a button where you can either go back to the GitHub page if you landed there in error, or you can click a button there that says add this package, and then it opens up a pull request with everything filled in, and that's why I wanted to bring it up because I find that's actually the easiest way to do it because you can both check if it's already there and then add it in one step.
There's no fiddling around to do, and that's why I find it really easy. And if you want, you can even go further, and that's what I do. I have a little bookmarklet that does a replacement of the, and you wrote this, actually, this bookmarklet. So it does a replacing of the GitHub in the domain name via JavaScript. So all I do is click buttons. I don't ever do replacement typing. I'm not sure how we could better expose that or make that bookmarklet easier to install.
I mean, I'm not sure if people add lots of packages that they might want to keep that bookmarklet around, but I do because I often add packages this way. But even so, I think it might be just easier to just try a TypeSwift package index over the GitHub in the domain to get it all started. I don't know. - So yeah, I'm not sure how we could make that process more visible. I deliberately don't mention that process.
It is also the process I use to add packages to the index, and it is by far the easiest way, but that manual step of either knowing that you can do it with a bookmarklet or manually typing in Swift package index to replace GitHub is enough for me to not exactly keep it secret, but not talk about it because it feels like a cheat code for adding packages to the package index.
(laughing) I think the point that I was talking, I don't remember exactly what I said just 'cause I don't remember many things. (laughing) There are many things I don't remember, but I don't remember exactly what I said with Tim.
But I think the point that probably came up was that that process of the whole package list JSON file is like there are some problems with that file and it adds some friction to, no matter what this process around getting something into that file is, it adds some friction to that process, but that it's important because that's the only record of who added what package to the index.
And it's good just to have a little bit of a trail of like where did each package eventually kind of originate from. But when we've been kind of making it easier over the years, but actually the mechanism that we've used to make it easier and I should credit James Sherlock here who did a lot of the work to initially get this working. What we've actually done is we have made that process easier but we've added various different ways to do the same process.
And that in itself kind of makes things a little bit more complicated. Like we still get pull requests that are people cloning the repository, editing the file, because that was the very original way of doing it. And there's probably some blog posts and stuff out there that say, this is how you should add a package to the index. And so people follow that.
And I do feel like we're kind of, it's a pain point of the package index that I don't know how we can easily fix it, but it has been on my mind a little bit recently. So there's probably a bit of latent guilt when Tim asked me a question. I wanted to confess my sins on the podcast. - I don't know. - The sins of adding a package.
- I see the upsides probably more than the downsides here because even if the list was in a different format and maybe not hosted in a GitHub repository, we'd still probably want to have some sort of audit trail who added it and that. - Yes. - Sort of complexity doesn't go away. In fact, I think using GitHub here is making it easier because otherwise, would you want to ask people to create an account to add a package? I feel like that's worse.
So I can't think of lots of ways to make that actually smoother than it already is. - Yeah, so this is entirely why it is still this way. And I think your point is well-made that you don't want to get people to add, create an account simply to add a package. I think there is gonna come a time where there are several reasons you might want an account with package index.
And as that happens, if that happens, and it's definitely not a foregone conclusion that it will happen, but that might be the change, the point that we need to change how we do it. But you're right that the kind of audit trail for want of a better word is the reason, that's it. That's the only reason that it's like this. - Yeah, and another upside is that the list is available.
If anyone wants to use that list for anything, like analysis or just have a list of all packages that are in the index, that's the place to go. And we don't have to deal with any requests around it. It's all right there. So that's certainly a strong reason to keep it open like this, which any other system would then have to replicate or offer in some way. - That's great. Okay, shall we do some package recommendations? - Let's do it. - Yeah, I can kick us off.
And my first package this week is from Jasmine Eilers and it's called NSAttributedStringBuilder. And this is a package that's been around for only a few weeks. It's about a month old. And it is a result builder type package. So it allows you to create NSAttributedStrings by defining kind of methods on string objects. So you could say, for example, hello.font and then give it a font.italic.foregroundcolor.underline. It supports images. So you can say, give it a, there was an image example here.
I was looking at it earlier. Oh yeah, here we go. There's a .image method that you can call on a string, which says, you know, here's a UI image or whatever it is. And add that into the attribute to string. You can put new lines in there. You can add other attributed strings if you've already got attributed strings. And of course, out of the result of this comes a newly formed attributed string that you can use all over the place.
And I mean, there are lots of ways to generate attributed strings these days. Foundation has markdown parsing these days and certainly has some level still of HTML parsing. But if you just want to generate some attributed strings to pop in your project, that default syntax for it, I've written many lines of attributed string code in my time. And this certainly seems like a significantly easier way to put together a kind of native attributed string. - Nice, that sounds really nice.
I haven't actually used an attributed string that much, but I have seen examples. So you have to do lots of sort of range stuff, right? Where you, when you have bold and italic and that sort of stuff, don't you? You have to fiddle a bit like. - Yes, lots of ranges.
I have also just noticed at the bottom of the readme file, which I didn't see when I was looking at it originally, it says this project is inspired by Ethan Huang's project, NSAttributedStringBuilder, which has the same and svdo/swift-richstring. So there are a couple of projects here. And actually we were chatting just before we recorded the podcast.
And one of the things that I said was, I have a feeling that we've talked about this before and we haven't, but it's possible we talked about one of these other ones before. - We might have, because I've seen a couple of packages like this. And I think it's a great example where a builder can help construct these things because they are sort of fiddly to get right.
And I think that's where these kinds of builders help lay out things in a better way than by sort of low level fiddling with properties and stuff. - And we do have both of those packages in the index. So that is RichString by Stefan van den Oord and a package with exactly the same name, NSAttributedStringBuilder by Ethan Huang. - My first pick is a pick you have probably seen. You might even have it in the list, but I'm going first dibs. And the package is called PowPOW by Robb Böhnke.
You probably know this package, right? - I am aware of this package and I did see the news about this package, yeah. - So the news this week, this is actually a now open source version of the package that was previously a licensed package that you would buy. And what it does, the tagline is delightful SwiftUI effects for your app. And if you've followed Rob on Mastodon or perhaps elsewhere, that's where I've seen it.
He's been posting amazing examples of what this library can do, like animations, transitions, that sort of stuff. Really delightful ways of enhancing your UI and a particular SwiftUI here with all sorts of modifiers and things that make it really interesting and fun. So that's what this package is about, enhancing your SwiftUI. There's a great site with examples of all the effects that are available. I did try to run it in a playground.
Unfortunately, it doesn't work with our trying to playground mechanism. I believe that's, I mean, it runs, but it doesn't show anything. I think that's because it uses, it needs to run on device or at least on a proper simulator, not just in the playground. It seems like this is running on a layer that's not present in Swift playgrounds. That's my speculation. But the example page should help give you a preview of all the things that are available. And it's extensive.
There's lots of stuff you can do. And it's just a great package and people seem to be really excited that it's now available. - And by the sound of it, your cats are also big fans of this package. - Yeah, absolutely is. And I say that to save me the pain of trying to edit those out. - This is going to be the case for a bit because apparently I've been, the server has been lacking around here. - Yes, I think so.
So I did see that this went to be a kind of freely available open source project this week. And I mean, the work that Rob does in many different aspects of Apple platform development is remarkable, but this is another great example of the work that he does. And I think it's also worth mentioning that the reason that it went, that the transition to free and open source this week was that it's effectively being sponsored by Emerge Tools who were previous sponsors of the Swift Package Index.
And I took a quick look into the kind of, not the details of it, of course, but it looks like Emerge Tools are actually sponsoring quite a number of Swift packages in the kind of package ecosystem. So that is definitely to be encouraged. And we had a great experience working with them on the Swift Package Index too. So it's great to see this happen. And I'm happy that more people will get to use this package. - That's fantastic.
I was about to ask if you know any, because I didn't know of the details why or how that came about. I only saw that it ended, it's hosted in the Emerge Tools GitHub account now, but that's great. That's great news. - Yeah, so I think, you know, open source needs more funding and this is a way for that to happen. And there's obviously a kind of logo in the header of the readme file there and various links and stuff.
And if that's what it takes to make open source development, you know, a more practical and comfortable thing to do, then that's great. - Yeah. - My next package is by Mikhail Vospennikov and it's called Gestures. And it's been around for about a year now. And this is a enhanced gesture API for SwiftUI. So obviously SwiftUI supports all of the standard kind of gesture recognizer type gestures that you would have used in UIKit or, well, UIKit basically.
But there's still quite a lot of work you need to do with kind of interpreting the gestures and seeing, you know, what trigger point, like if you have a swipe gesture, you'll obviously get the coordinates of where you're swiping to and the distance and stuff like that. But it's your decision on what to do. And actually in reality, there are a bunch of really common things that you might want to do.
So for example, you might want to add a swipe gesture that only actually triggers something when you've moved more than at least 15 points within the kind of context of that swipe. And this is what that package does. So it adds a whole set of extensions to SwiftUI gesture API that help you locate gestures and do things like trigger on minimum distance and that kind of stuff.
So yeah, it gives you coordinate information, it gives you location information and very easy to integrate in your project. And as it says in the readme file, it's a lightweight package. So I don't think this is a huge amount of code that you're adding to your project. - Nice. Right, my second pick is called Scintilla Lib and it's by Danielle. That's all I have as far as author information goes.
And this is, I'm taking a page from Dave's book of package picks here, 'cause that's a dependency package you probably won't need or won't use as a dependency. (laughs) But it's a fun project to poke around in and run the examples of. What it is, it's a ray tracer ported from Clojure to Swift.
And what it does, it's intended to be used more like a library rather than like an app or anything, but you can run it as an app and it has a little render view and UI where you can actually just render the thing and get some output. And it ships sort of like a Swift UI type DSL where you can describe the scene, like your objects, your camera, and then you can run it and you get a screen that shows the rendered output. And I found that really nice.
It gives you something to play with and give you a little playground to try ray tracing if you're new to this or if you want to play around with that. A really fun little project that I ran. Also something that doesn't run in a playground, but it is very easy to just stick the examples in a command line app. So there's a description in the readme how to set this up.
Effectively just create a blank Xcode project, command line project, and then paste in the main thing, the admin decorated result builder thing. And it is a bit like an app that you create in Swift UI that you then create in this DSL and you run it and you get this window and it shows the rendered output. Really nice little thing to play around with ray tracing. - I have so many questions. Does it do its own ray tracing or is it using metal or? - That's a great question. (laughing) - Revenge.
- It opens a window, there's a, now it draws it line by line. So there's something happening. There's not a whole lot of cause firing when that happens. I don't know under the hood if it's accelerated. I suspect it isn't. I think it would be faster if it was. This seems to be a port from Clojure. So I don't, I'm too honest.
I don't know how that would work if on either end, if it was accelerated, but I would imagine if it's, if it's ported from another language, it sounds more like it's a pure software ray tracer that is then ported one to one. But that's just me speculating without knowing a whole lot about ray tracing and the mechanics of all that and metal for that matter. - Sure, well, certainly I didn't actually spot that one going through. So I am gonna go and have a look at that after the show.
My final package this week is kind of along the same lines. It is called Model 3D View by Freek, F-R-E-E-K. And what I really liked about, so the package description is render 3D models with SwiftUI effortlessly. And what I kind of liked about this is that it describes itself as image view for 3D models, which is an interesting way to think about it because we use image views all the time just to, you know, pop an image on the screen.
And we don't really need to think about any of the stuff that needs to happen to get that image on the screen. And this Model 3D View package basically does the same for 3D models. Now, I know that SwiftUI has native support for USDZ models through the QuickLook framework, I think. But this also supports something called GLTF models, which is Graphics Library Transmission Format, which I believe is something that came out of WebGL.
And again, I would ask you please, no detailed questions about this because my knowledge of this is a Wikipedia article. (laughs) We are making the least researched podcast in the history of podcasting here. But yes, it supports GLTF files and you can pop a skybox in there. So you can have a kind of a 3D background or a 2D background inside a skybox. You can change lighting, you've got some interactive camera controls.
And the best bit about it, as far as I'm concerned, is you can pop a Model 3D View into your SwiftUI View and the only parameter you need is to pass the model file name in. And there you go. You can then, if you want to, you can transform it, you can rotate it, you can scale it, you can transform it. You can give it a new camera. You know, there's lots of different things including interactive cameras. And as I say, like things like skyboxes and stuff like that.
But I liked the description of this as like, well, this is image view for 3D objects. And that I think is a really nice utility to have inside apps these days. In the frequently asked questions, there's a question here. Can I use this to make a 3D game? And the answer is in bold, no. (laughing) So yeah, so it's not, this is not a 3D framework. This is just, as I say, image view for 3D. - Nice. Did you mention the, I think you mentioned a couple of formats like 3D, but Model 3D wasn't a format.
It's a placeholder for any sort of supported 3D format, right? - Yes. I'm not sure of the full list of formats it supports, but I know it supports this GLTF because it calls it out specifically. So, but yeah, Model 3D view is the name of the view that you would insert into your SwiftUI view hierarchy. - Nice. Yeah, it's interesting with these, that has largely gone away, right, with the graphics format, display format.
I remember back in the day, one of the most used programs on my Mac was graphics converter. To convert between all the different formats that you would find on the internet. And you couldn't actually display unless you use that tool or converted it with that tool to a format that the Mac could display out of the box. So we've come a long way where anything is really supported, isn't it, with 2D graphics at least? - Without even, you don't even have to think about it anymore.
You just kind of say, images are as easy to work with as text. Whereas I remember in my very early days writing Object Pascal to decode Windows bitmap files and having to read byte by byte. And yeah, it was a very long time ago. - It's interesting with live text, it goes even further that they're not, they're sort of sometimes even equivalent to text, right?
I've had cases where I had something and I took a picture and then copied the text out in like a router password that I didn't want to type. Where it's become almost synonymous in some regards. There's a little bit of friction still in taking a picture and using it as text, but it's surprisingly little friction these days. It's amazing. - Yeah, I use that all the time too. - Right, my third pick is called SwiftUI Core Image by Dan Wood. And this is a really interesting package.
So what it does as the name pretty much says already, it integrates Core Image into SwiftUI and gives you a sort of modifier based way of applying or creating image pipelines and preview them. Like for instance, in a playground. So this is something that you can actually use with our Try in a Playground feature. And it's really nice to take an image and then create these pipelines, like apply a sepia filter, a Gaussian blur, or something like that.
So all the things that you know from Core Image. And I've not used that a lot, but Core Image is a different beast, right? It's a completely different API. So having that available and being able to use that on regular SwiftUI images is really nice. And it has dozens and dozens of modifiers. So it looks like it's a really extensive coverage of the Core Image API.
It has some nice examples as well, and is an all around great package if you have that sort of a need to create a Core Image pipeline and play around with transforming images. - And there's a whole load of stuff that Core Image can do that you would probably be surprised at. It's an API which has been around for a long time, but it's a very powerful API. - Yeah. So, yep, there you go. SwiftUI Core Image by Dan Wood. - And so I think that brings us to the end of today's episode.
And actually this will be, as I mentioned, at the end of last week's episode, or the last episode that we published. This will be the last podcast that we record in 2023. So I wanna wish everybody happy holidays and thank you for listening this year. It's been something that I've really enjoyed doing again this year, and I'm happy to see that it's gaining some traction and people mention it more and more. And so really happy to kind of see it find its feet a little bit.
Because when we started this, we didn't really know what it would become. We started this actually as Twitter Spaces, and it was a very low effort affair at the beginning. We just jumped on, no attention paid to audio quality or indeed the quality of the content that we talked about, which has remained, as you've heard today. But we didn't really know where it would go. And as we come to the end of 2023, I think it's worth just kind of saying thank you so much for listening.
Please do, if you enjoy it, please do share the podcast with other people and we'll be back next year. - Yeah, thanks for listening. Do let us know if you have questions, comments, always love to hear what people think or if you have questions, ask us and we'll address it. And yeah, happy holidays and see you next year. - See you next year. Bye-bye. - Bye-bye.