59: At least mine was related to Swift

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.