Swift Package Indexing

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.