Swift Package Indexing

Shall we start with the usual talk about

the weather?

Well, my weather has been different to

yours for the last week because I've

actually just got back from a little

holiday, which is very nice.

I went to Norway last week and the

weather was okay.

It was nice enough, but we did have a few

rain showers, but I don't think that's

what you've been experiencing in the

south of France.

No, I haven't.

But also you, right, at home, it was

actually quite hot, wasn't it?

in the UK during during your time away.

It was.

They had very hot weather here, which I

avoided. nicely done.

Yeah, it was good.

I mean, not to say that it wasn't on the

so I was on a cruise and on the sea days

it was actually very nice weather enough

to, enough to sit out and, you know, go

in the pools and stuff like that.

So it was nice weather on the way there.

But once we got there, we had mixed

weather, I would say.

Good stuff.

Well, let's let's tick the weather chat

off then. we've covered that.

Weather chat done.

Do we have anything else to talk about or

is that that's the end?

So we'll see you in a couple of weeks

right?

We do actually have topics, we're not

we're not just stretching the show, are

we?

So one thing we could definitely talk

about is the announcement of the

ecosystems steering group.

This actually happened quite a few weeks

ago well before WWDC.

And it's, as the name says, the ecosystem

steering group.

I was actually a bit, just going by the

name, I thought it might actually overlap

a bit more with, you know, what we're

sort of doing with the Swift package

index, looking at packages.

But the mandate is actually to guide the

evolution of widely used packages like

Swift Foundation, specifically, uncover

areas such as Swift PM dependency

management, build systems, and tooling

related to packages like Swift Format, and

editing, including ID editor integrations

CI, and deployment, and packages relating

to testing.

More package adjacent rather than

directly.

I think it even specifically calls out.

Or I think in my head, like I came up

with a summary, it's probably best

thought of that it covers aspects around

a healthy ecosystem, but not related to

the contents of the ecosystem.

So everything that sort of prepares the

ecosystem to flourish, you know, to

create the packages, but the packages

themselves, unless they're really

foundational, like Swift Foundation

they're not specifically part of the

mandate, you know, like unless, as I said

they're very specific, foundational in

that they are actually Swift Foundation

or Swift Format, Swift Testing. sort of, I

think the areas you could think of as

where you probably want to have one

canonical thing that handles it rather

than, you know, like five different post

gress drivers.

Well, probably postcard drivers is also, I

think it helps if you have multiple ones

but like Swift Foundation.

There isn't much point to have Foundation

A and Foundation B, right, or Swift

Testing is.

I mean, sometimes there is benefit to

have like variations of testing, but

probably built more on top of a

foundational package like Swift testing.

Sure.

So I think, you know, you get the drift

what the what the idea is behind the

behind the thing.

I think it's also worth mentioning here

that this is a steering group and not a

workgroup.

So, right, yeah.

As far as I understand it, and I'm fairly

sure that I'm right here, but I will be

happy to be corrected if I'm incorrect.

The way I believe they work is that

steering groups sit slightly above the

workgroup.

So, it actually mentions in the um

decision making part of the uh the the

charter that they've put on the Swift

website that the ecosystem steering group

is commissioned by the Swift core teams

to make decisions on its behalf because I

do think that the Swift core team is

quite overloaded with making decisions on

other things from the other work groups

and things like that.

Like the Swift website workgroup, we

quite often have to pass things past the

Swift core team.

And I have a feeling they're trying to

delegate some of their responsibilities

out into these steering groups that can

take responsibility for some of the

choices.

And then there may be workgroups that sit

underneath this steering group.

Now, I may be slightly wrong with that

but I think that's how it works.

Yeah, I mean, in my mind, they're sort of

the managers of the groups, right?

In terms of a company set up, they'd be

the managers and the working groups are

the the team members, the rowers.

Yeah, exactly.

The CEO.

Yeah.

I mean, honestly, I'm I'm surprised by

all the stuff that the court team

traditionally was dealing with.

Like, I, they must be in meetings old

days.

I feel like sometimes because just

looking at the number of Swift evolution

proposals that go through the pipelines

and, you know, have to be discussed and

you, because there's such foundational

decisions, right, you can't just, on a

whim on a Wednesday, sit, ah, right, we'll

do it this way and then maybe we'll

change our mind.

No, this is these are decisions that need

to last.

They need to understand the test of

time.

And I'm really surprised how much they've

been dealing with.

And that has changed already, right?

I think the language steering group, which

is now taking that on that part of it, has

been formed quite a while back.

I believe, so that's dealing with that

part now, and, you know, and then, I mean

but there's so much other stuff that

needs to be within Swift as a whole, that

it's been really surprising how much

actually was funnelled through the core

group and the amount of responsibility

that group has been dealing with quite

quite remarkable.

Yeah, and I think, as I say, I think

that's been, been, in process with the

language, there's actually three steering

groups here, there's the language

steering group, which she just talks

about, there's the platform steering

group, and there is now the ecosystem

steering group as well.

And I would not be surprised if we see

more.

That's great.

Another thing I wanted to talk a bit a

little bit about was I was going through

the packages this week to find anything

to talk about and noticed a couple of

packages by the code edit team.

And the packages that I noticed this week

are welcome window and about window that

have been added to the code edit.

So code edit, 1st of all, is a open

source coding editor written in using

Apple platform technology.

So it's not like VS code and all the

others which are electron applications.

It is a native macOS application.

And it's been development for several

years now.

I think maybe three or four years since

they started development of it.

And I saw these two packages come through

and they're called Welcome Window and

About Window.

And I found a blog post from the teen

that was just published yesterday

actually, on the 7th of July.

And it's part of a thing that they do

actually, which is that they try and

extract as much of their app as they can

into reusable packages, and they had an

offer of from a community member of

theirs that offered to extract the about

window and the welcome window into

reusable packages.

And the blog post is now announcing that

the project now uses those packages

rather than its own implementation of

them.

And I thought this was a really nice

practical example of packages being, you

know, the right way to use packages in

the community.

And this is not something that every part

of the application could be extracted

into a package like this, but and about

window.

And it's quite a fancy about window.

It's got the ability to include, like

contributors, if it's an open source

project in quite a attractively formatted

presentation, and the other one is the

welcome window, which is the, it's

actually very Xcode, like, um, opening

window that you'll see where it says that

you can make a new project or opener

project, or on the right-hand side, you

have a list of recently used projects.

So the kind of thing that if you're

writing a Mac application, there's

actually quite a lot of work in making

something like that welcome window

especially to get it to look good and to

work well and to do all the things people

expect it to do.

And so, obviously, the package, I mean

these are not actually, these are not in

my package recommendations, I guess

although maybe they are. maybe this is an

early package recommendation.

That has never happened before, has it?

Yeah, no.

I thought the blog post was worth

referencing here as an example of a

community project that's kind of doing

this right.

That sounds great.

I love when that happens when you have

sort of elements that are kind of

standard, but don't have actually a

standard, you know, UI component in, you

know, whatever, AppKit or UIKit.

I love when there's a sort of community

maintained, commonly used component.

Like, the one I canonically always think

of is the update manager, what's his

name?

Help me out, the...

Oh, Sparkle?

Sparkle exactly.

Like, you know, you recognise it

immediately.

You know, all right, all right.

This is using the standard thing.

I can trust this thing to update

automatically.

I know exactly where the settings are for

configuring it, you know, like download

automatically.

And, you know, it's like a standard

component, but that isn't actually

shipped with the OS.

But you can tell immediately when an app

uses it.

All right, this this this works.

And I love when sort of these stand

components evolve and and happened.

And I hope, I'd hope for those, you

describe them, to be like in that vein

and it sounds really great. would be nice

to see them adopted widely.

Yeah, absolutely.

And maybe I don't need to do as many

package recommendations now that I've got

those two.

Always, always sneaking in a few extra.

Exactly.

Why not?

Well, it's called Swift package indexing

after all, isn't it?

Exactly.

It's package ecosystem news.

Yeah, in another bit of news, not

strictly about Swift per se, there's a

social media post that came across also

quite a few weeks ago, which I found

really interesting.

At least mine was about Swift.

Well, I'll tie this back to Swift somehow

bear with me.

This is a blog post called Evolution of

Russ Compiler Errors. and it's a really

nicely done blog post in that it has a

snippet of rust code. and then one with

an arrow in it. and then below, it has a

slider where you can scroll through

different versions of rust, like starting

at one.o.o and ending at one 80.

So I'm not sure if there's like literally

80 versions in between.

No, actually, it's jumping like in large

increments than one.

But there's quite a few jumps through the

versions.

And what it does, it shows you below the

code snippet. what the error message

looks like at that version of Rust.

And it's really interesting to see the

evolution.

Like, Ruster's always had nice error

messages, like with ASK art pointing out

where the error is, and then explaining a

little what's happening.

It's like 10, 15 lines of error message

that you're getting, like even in one

0.0.

And then as you scroll through the

versions, you'll see, you know, colour

starting to appear, and an error code

being added, which I think is a really

interesting, an important piece where it

makes it really easy to find additional

information because you get this error

code, like E, 03, H2, in this case.

And then you immediately know are all

right.

I, this is something I can, I can web

search for and then find more information

if, if what's already there isn't enough

and it probably isn't even needed.

But I found that really nice to see the

evolution of it.

And the reason this caught my eye isn't

just, because this is interesting to see

and sort of Swift and Rust are a bit

similar in their messaging, like there's

a lot of focus on how to show errors and

how to explain what's going wrong.

But I think I've also seen on this

performs an announcement that there's

some work happening to improve the error

messages in Swift.

And I think this wasn't just specific to

Swift concurrency where I know there's

work been happening and I think also

still ongoing to improve the error

messages, you know, like when you get

something happening around concurrency, it

can be quite daunting. when that

happens.

So I know there's been a lot of effort

put in to make that more approachable.

I think this goes beyond that.

I think there was a maybe somewhat of

code project.

I'll try and find something and added to

the show notes, where there was specific

focus on presentation and making sure

that there's more information at the

initial message, but then also linking

off to find more about what's happening

and how to resolve it.

And I think it might even be interesting

to see something like that for Swift

because I think the Swift messages have

also changed quite a bit over the years.

So if someone's out there interested, that

might be a fun project.

I think that would be a great level

community project.

Yeah.

I would recommend that anyone listening

to this do just click through to the show

notes and click on the link to that blog

post because you'll really see what

you're, what Sweat is talking about there

when you just quickly grab the slider and

kind of shift it left to right.

And it's interesting.

It's not always that the error message

has got longer, in fact, sometimes it's

got shorter. and they change in different

ways for the various different errors

that are given as examples here.

But certainly they do all seem to try and

point out the location of the error much

better than they did at the beginning.

And I think that's really, really a great

attribute of an error message is showing

people exactly where, or if possible

showing people exactly where the syntax

error is. and I think Swift error

messages could do with not only in the

concurrency arena, Swift error messages

could do with some work as well, one of

the most recent changes that I find quite

interesting is, like, they brought colour

in, like, yeah, like about halfway

through, like, the arrow is, the actual

arrow is in red, like, guides your eye to

you know, like, the error code is in red

and the, what's, what's wrong is in red.

And then at the very end, green appears.

And green is actually making a suggestion

what you could do to fix the problem.

I find that interesting and a good use of

of, you know, colour and helping you.

Like, you know, obviously something went

wrong, but, you know, you don't just want

to know what went wrong.

You should really want to know how do I

fix it, right?

And that's a good thing to do at that

point.

Yeah, and I wonder how much of this kind

of stuff would be possible with Swift

given that the UI in Xcode will also have

to be updated to cope with this type of

error message.

If they went down this route, of course

this is all speculation. of whether they

even want to.

But that seeing Swift error messages in

Xcode actually also can be kind of

difficult. sometimes you sometimes have

to expand the error a little bit to see

it all.

So I think the expert UI would need a bit

of updating as well.

Yeah, well, and it would need to update

when the errors happen or go away, which

sometimes it doesn't.

Right, sure, yes.

We simply don't have the technology to

fix that bug, though.

And with that, shall we do some package

recommendations?

Let's do some packages, yeah.

Why don't you kick us off this week?

All right, my first pick is called swift-security

by Dmitriy Zharov.

And this is a nice keychain API.

I think we've mentioned a couple of those

in the past.

So do look in the past show notes as well

or search the package index if you're

interested or need a package like that.

I've certainly actually created a wrapper

of my own in the past for my use. which

was very simple, but this is one that I

noticed has like a lot of features.

Like it covers a lot of things and has a

lot of API surface.

So if you need something more than, you

know, just read and write a password.

This might be something interesting and

worsened look, because it really seems to

be covering a lot.

So, yeah, in that respect, I'd recommend

it to have a look.

As always, with security related packages

and API, check before use, but it

certainly looks like a solid candidate to

inspect and review.

Sure, but sweet one.

My first one this week is Translate Kit

by FlineDev, and this is, the thing

that caught my eye about this, is the

description of the package.

It was described as SF Symbols for Text

which is actually SF Symbols for

Translations, I would call it.

It's 2000 or more built-in translations

in 40 languages that you can just have

all of the common words and phrases that

you might need in an application, like

for example, a save thing, the word

notifications, save changes as an example

here. except all, you know, there's lots

and lots of core strings that your

application is almost certainly going to

need.

And you can save yourself a whole lot of

time and effort by using a package like

this to just have those there.

And there's a couple of notable things

about this.

First of all, 40 languages is fantastic.

And it's the same 40 languages that Apple

supports in their localisations.

So you could localise the same level as

Apple do with some of your localisation

being done by this package.

And secondly, the translations that are

in this package have been checked against

what Apple uses.

So it's not just someone's opinion on

what this translation should be.

It is the same translation that users in

those countries will be used to seeing in

system prompts and dialogues and UI and

things like that.

So this sounds like a really great

package to me. to get you started with

localisation.

Of course, it's not going to have your

applications, every string that you're

going to need for your application, but

it's the kind of thing that might get you

started.

Is it, I've been trying to come up with

an example.

Is there anything in there that is, like

deals with context?

Because, you know, you often have

multiple sort of correct answers to a

translation and it depends on context

which one's the common one to use.

So, so I think English is particularly

bad for this, where the same word can

mean multiple different things depending

on the context.

I'm sure other languages have the same.

What it does have is the documentation

attached to each of the properties that

has a translation in it includes the

context.

So, for example, there's a screenshot in

the Read Me file here where they are

about to insert the translation for copy

which can actually have multiple

meanings.

And the documentation for that function

says, use when duplicating content to

clipboard.

Right.

So I don't think it has any other

instances of copy there, but it does give

you the context it intends.

I mean, that's that's a huge help.

And as they start, that's probably, I

mean, not probably.

That's definitely a good start, you know

to help you deal with the common stuff.

And then even if you have someone who

helps you with translation, it's nice for

them to not have to deal with all the

mundane, obvious things.

And also, there's common language that's

used in computer systems.

Like I often in, you know, like in German

you have words in computer screens that

you probably wouldn't use in spoken

German, like honestly, but they're so

common in commuter systems that they sort

of became the default translation. and

just having a library of things that are

in common use, you know, makes that much

nicer and you don't have to guess which

one to pick because, you know, that

choice has been made for you.

So yeah, that sounds really nice.

The other thing just to mention what, in

terms of context, is the shorter strings

that this, these kind of translations

tend to be, is where that contextual

confusion can often happen.

When you've got longer strings, the

context is usually explained within the

sentence or the phrase that you're

translating.

So context is much more important in

something like this.

So I'm glad to see that that

documentation does give the context as

well.

Nice.

Does it have, like, means?

Is it just like literally one word or

does it have mean ways to modify it in

some form?

You know, sometimes a word needs to agree

with like literal grammatical context

around it and like plurals or agenda, you

know, like the object gender or the

subject gender. anything like that?

That's just a really great question.

Well done.

Yeah, great question.

I don't know.

I don't know.

But yes, read the read me file.

All right.

My second pick is called TextDiffing by

Simon Støvring.

Another one of those really nice UI.

Well, it's kind of UI and kind of not

packages because it is actually not UI in

the sense that it is a package that takes

two strings, diffs them and creates an

attributed string out of it that shows

the differences between the text.

And if you just look at the read meal

immediately understand.

Oh, did I did I show like one of your

picks there?

No, no, this was very, very nearly my

pick, but I didn't pick it then.

Yeah, as I said, if you look at the read

me, you'll immediately understand what it

does, like sort of it has a green

background insertion and a red background

deletion, and then, you know, it'll, if

you actually render the attributed string

that's what you see.

So in one sense, it's actually not UI

because it's an attributed string, but

then again, you know, where they use

attributed strings, obviously, in UI, so

that's where you then what it's actually

doing. and it's a lovely package.

It is very clear what it's doing. does

it?

And yeah, also gives you a change count

so there's more that you can do with it

than just render it.

So yeah, if you have need for that sort

of thing.

And obviously there's also options, you

know, like, you know, how you format, like

attributed strings can have, you can use

colours to show the differences, but also

strike through, for instance, and that

sort of thing.

So, yeah, if you need that sort of thing

give that package a look and use it in

your differ or whatever you're building.

My next package is a command line tool

still in a Swift package, but it's not a

library, and there's 0 libraries in the

package, just one executable. and it's

called Yap by Finn Voorhees.

And this is a Swift 6.2 specific package

but I don't think it's because it's Swift

6.2 that it needs.

I think it needs what it does need macOS

26.

So in macOS 26, there is a new framework

called Speech.framework, which can very

quickly and efficiently, more efficiently

than the Whisper model from Open AI, which

is used for a lot of text to, sorry

speech to text transcription at the

moment.

In initial tests.

It's more efficient and speedier than

that at transcribing audio to text.

And this is a command line tool that you

can either install through brew or mint

or you can build it from the package

source, and this is a swift package that

contains this executable, that will then

take an MP4 file, presumably an MP3 file

and just very quickly and very accurately

transcribe it to text them.

So I think what we should do is use Yap

to write the transcript and use Mac

Whisper and then use text stiffing to

show the difference between the two

right?

Well, it's funny you should say that

because I haven't actually used this tool

yet, but we do have a process that we do

with Mac Whisper, which is a Mac

application that uses the open AI Whisper

model to locally transcribe text into

sorry, transcribe audio into text.

And that's how we power the

transcriptions that we have for the

podcast that we put out every time we do

an episode.

And I'm going to use the app.

Oh, actually, I haven't got 26 installed

yet.

I was going to use that, yeah.

Yeah, this week, but I haven't yet got a

26 machine, so maybe I won't.

Do you have one handy?

I do, yes, I can I can run that for us.

Perfect.

Okay.

So I will pass you the audio and we'll do

we'll do a diff between the two and see

what the, see what the, the performances

like.

So I've heard from everything I've read

about this.

This is slightly better than much

better.

Like in text translation before.

It's because like speed performs is

massively inaccuracy.

Yeah.

Yeah, in accuracy and also in, like, quite

dramatically in speed, apparently, and

also in accuracy slightly.

Do you have a, do you have the speed

increased to hand?

Is it like 5 or even 10 X or do you do

you recall?

I recall seeing it, but I don't remember

the number, but it's certainly more than

four, I think.

Right, yeah, the read me doesn't make any

claims about that.

But I've seen people who have done tests

with it.

I don't have any of those links handy, but

I'll maybe try and find one for the show

notes.

But I read a couple of articles about

this in the last couple of weeks.

Nice.

Oh, I'm curious.

I've seen the thing, and I was curious to

try it out.

So that's actually a nice thing.

We can do that and then follow up, perhaps

next time.

I should also, I should also get my spare

MacBook out, although my spare MacBook is

an Intel.

So I think Twitter does 26 still run on

Intel?

I think this is the last version that's

Intel, right?

Yeah, last one.

Yeah, okay.

Yeah, and the arm version runs fine.

There was a bit like the 3rd beta, has

cleaned up a bit of the visual ugliness.

Yeah, I'd say ugliness because it was a

bit like Safari tabs were really weird in

Peter 2.

I mean, nothing really broke.

The only thing that isn't working in, in

Marcos 26 is the screenshot tool, um, the

tapping on buttons in the screenshot tool

the specific one, clean, clean shot X. Is

that what it's called?

the one we used.

Yeah, screenshot is great app, yeah.

And unfortunately, if you bring up its

main view where you can edit and mark up

the screenshot, the buttons on that

screen don't work in Tao for some

reason.

So you can only save your screenshot and

then you have to edit it in in preview.

That's the only thing I've seen that

isn't working.

Otherwise, it's really solid beta.

So be warned about that.

Right.

My 3rd and final pick is called Objects2XLSX

by Xu Yang.

And this is an interesting package that

converts Swift objects into XLSX files.

So that's Excel files effectively, the

modern version, which is the XML-based

ones.

And I think there are a couple of them

like packages that do that.

This one is interesting that it is really

typesafe in the sense that you can, like

your workbooks and your objects, literally

write out, you build up a worksheet with

you know, like Swift templates, not

templates, help me out.

I'd love to help you out.

I'm not quite sure where you're going.

You know, like when you have your angular

brackets and the tea in it.

What's it called?

God damn it, what's it called?

Oh, generics.

Generic, that's it.

Jesus Christ.

It's been really hot here last week.

I forgot everything.

So you actually build up a worksheet and

you can use styles and everything.

So it's a nice and interesting API that

you can use to build up and write out the

files.

It doesn't read it back from what I've

seen.

So if you if you need passing, you'd need

something else.

So, so make sure that fits, obviously.

But, yeah, it seems to be really covering

a lot of features because the ones I've

seen in the past excel sheets really deal

with data only.

I don't think I've seen an XLS writer

that actually dealt with styling.

You know, you can set like the border and

colours and stuff of cells.

So that's an interesting thing if you

need to build XLL sheets automatically

that carries some of that.

That's probably one of the few ones that

that will, would really get you far, if

not all the way there.

So if that's what you need, give that a

go.

That's some objects to XLSX by Zuyang.

We got there in the end. did.

And with that, I think we'll leave it

there for this episode.

So we will be back in three weeks.

Excellent, see you next time.

All right, take care.

Bye-bye.

See you next time.

Bye-bye.