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.
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.