Inspired by a recent YouTube comment left on the previous episode, Dave and Sven talk about cross-platform Swift development with Visual Studio Code, Windows and Wasm compatibility, and about how Dave should have answered a question about adding a package into the Swift Package Index!
News
News
- Swift Extension for Visual Studio Code introduction blog post
- Getting Started with Swift on Android
- More Than Just Code podcast episode with Dave
Packages
- Model3DView by Freek
- Pow by Robb Böhnke
- Gestures by Mikhail Vospennikov
- ScintillaLib by danielle
- NSAttributedStringBuilder by Jasmin Eilers
- SwiftUICoreImage by Dan Wood
Creators & Guests
What is Swift Package Indexing?
Join Dave and Sven, the creators of the Swift Package Index open-source project, as they talk about progress on the project and discuss a new set of community package recommendations every episode.
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.