Swift Package Indexing

I think this week we can actually start with a bit of follow-up,

because my hope to use cross-compilation for Windows compatibility testing

was swiftly shot down by Max Desiatov in a Macedon post.

I'm not sure if you've seen his reply or his post.

Did you see that?

I haven't, no.

So the issue there is apparently that in order to make that work,

you need to have components from Visual Studio.

So you need not to either have Visual Studio installed

or you sort of need to would need to extract the libraries.

And that's obviously not something that's

that's just shiputable or shippable.

- I think we did kind of mention that on the episode where

we, I don't think we were concrete about it,

but we did say, oh, it's actually this potential

that we might need a Windows environment for that.

And I think that Max's post there is proof that we do.

- Yeah.

I wonder if there's a way to work around it

by creating your own cross compilation environment

after the fact, but I'm not sure what the licensing terms say

if you can operate it once you've downloaded it

and copied it over yourself, or if that's also off limits.

I'm not sure how that works exactly.

But it didn't sound like it's a route that's open to us, at least.

So I think part of it as well is that we're trying to provide real world

compilation results and real world compilation results on macOS get

compiled on macOS and to a certain extent, real world compilation results

on Windows should also, I think, be on Windows and yes, it makes our job a

little harder, managing more environments, but I'm not

devastated that that's not going to be a problem, because it's the kind of thing

that even if we could get it working, who knows what would happen down the road, right?

And the next thing you're going to say is we need to set up a iPhone and

iPad build farm? Is that what you're saying?

Well, no, because...

Yes, yes, yes, yes, I know.

because you would build iPhone and iOS applications on Mac.

- You do actually feel it there.

- So that is still a real world environment.

My argument stands.

(both laughing)

- Right, well anyway, so that's certainly going to be,

very likely going to be more complicated

than we were hoping, but let's see how it goes.

Let's see how it goes.

- I also have a little bit of follow-up.

We had an email in, or I had an email in,

after we talked about using GPT to search,

potentially, not as the summarization,

which we talked about, but as the search,

like out there idea that we had.

And this is a blog post from Ramin,

and it's basically using ChatGPT

to search documents and databases.

So it's the code that he's written is in Python rather than in Swift.

But I wanted to mention here, I also popped it in our discord when it arrived.

But I wanted to mention this post that he sent in.

And basically the application that he created with it is to create a web

application for answering questions from Tesla car manuals.

So he fed it with Tesla car manual data.

And then you can ask that application questions,

but it's basically using GPT to search that data.

So I thought I'd give that a mention

as a quick bit of follow-up after he sent that in,

after listening to our GPT episode.

- Interesting, I completely missed that.

I did not see that message.

I need to check that out.

That sounds quite interesting.

- It's certainly worth a read.

There's a lot of code in the blog post.

It's very verbose in terms of you could,

I would imagine you could actually take this code

and get this thing running, so.

- Stick it in GPT and have it converted to Swift,

is that what you're suggesting?

(laughing)

GPT is the answer to everything, really.

- It certainly is, yeah.

- Right, do we have anything else in terms of news

that we want to cover this week?

I mean, next week is the big thing, right?

the big WWDC week.

Yeah.

Next week we will be, um, although the next time we record this podcast, I'm

imagining we'll be surrounded by, uh, virtual reality if, if, if every, if

every website is to be believed.

Uh, so, um, so yes, this is the last time that this will be an audio only podcast.

It will, it will be virtual reality from next episode.

I guess, but there's a cast iron guarantee there.

No, but actually, I mean, one of the one thing that's obviously, obviously, I'm not being serious there.

But one other thing that does come with every WWDC is new versions of Xcode and new versions of Swift, right?

Yeah, yeah, exactly. So it's that time of year again, we did have the 5.8 release was in March, I believe.

I know, you know, obviously this aligns, then this will be, we'll get the first five, nine

versions next week, I suppose.

And the final release will probably be in September with all the rest.

But the beauty of the SWIFT project is that you get some visibility on what's coming in

the next SWIFT version, right?

There's proposals that are being managed via the SWIFT forums.

a website, I believe even on SWIFT.org, you can now see the evolution proposals in flight

and the ones that have been accepted and all that.

That's true.

So you get to see what's coming, right?

Yeah, so it's actually worth just talking about that briefly.

So for a while, there was an independent SWIFT evolution website, and that has quite recently

been integrated into SWIFT.org.

So if you go to Swift.org and on the sidebar

on the left hand side, if you click on Swift Evolution,

then you can see all of the accepted in review,

pending, whether it's under active review

or whether it's an accepted feature,

that's all now integrated into Swift.org.

And there's a search box at the top there,

which if you type in 5.9,

it will show you all of the implemented

and accepted evolution proposals

for a specific language version,

which is an extremely useful tool to have.

So in case that slipped past you,

then that's a good resource to know about.

- Yeah, that's really nice.

I actually didn't know this or didn't remember this.

I'm sure I've seen it,

but I secretly forgotten about it.

And I actually asked on Macedon last night

if there's a list, someone pointed to that list,

but I also found a website that's quite nice

that lists upcoming 5.9 features.

It's buybydev.

- Okay.

- By B-Y B-Y dot dev.

And it lists the proposals and also has a little paragraph

about what it's about.

So it's a bit more on a single page,

a bit more information what the individual

Swift evolution proposal is about, yeah.

- Yeah, that's really nice.

I hadn't come across that.

I went straight to, as I think with my,

with my Swift website work group hat on,

my instant feeling was to go straight to swift.org.

(laughing)

- Is there anything particular to, worth highlighting

in the context of our new section here on the proposals

or going through them?

I'm not sure if it's worth probably going through

all of them because some of them are very specific,

a lot of them around concurrency.

Is there anything, do you have a favorite amongst them?

- I do have a favorite actually.

And my favorite one of all these that are going in

is just a really nice little syntactic sugar

feature around if and switch statements.

So rather than using kind of an if statement

or a switch statement inside a closure,

you can now just assign the result of an if

or a switch to something.

So it cuts down on potential use of ternary operators,

which is, you know, ternary operators are fine,

but they rarely create very readable code

in everything other than the most simplest use of them.

- Yeah.

- So I really like that you can now,

or you will now be able to just say variable equals

and then if or switch and the result of one

or whatever that statement is gets assigned.

And that's gonna save a lot of,

it's not gonna be a huge time saver or anything like that,

but it's just a nice bit of syntactic sugar.

- Yeah, it's nice.

The ternary really only works if the expressions,

you know, in each branch are really short.

When you can fiddle a bit with the formatting

that it doesn't get too crazy,

but having a proper if statement with curlies and stuff

certainly makes that easier to line up, I think.

And the other thing is that the,

because they're now expressions,

you can also elide the return in,

if you have a function that immediately switches

on something, for instance,

and in each case, you can then elide the return.

So you can write really concise little functions

that switch on something and handle the individual branches

without everything looking like a lot of return keywords

and very little information otherwise.

So that should be nice.

- The other thing I think is just worth mentioning

about some of these proposals that are going into 5.9

is that they are not all Apple authored.

I mean, obviously Apple author a lot of proposals

for and implementations of Swift features.

But that's far from the only contributions

that are going in there.

And there was a couple here.

So one of them was importing forward declared

Objective-C interfaces and protocols by Nuri Amari.

And it's possible, Nuri works for Apple,

but from a quick look, I don't think they do.

And certainly I know that the add sleep for to clock proposal,

which is adding a sleep function to clock,

was authored by Brandon Williams and Stephen Seles.

So a couple of mentions.

I think it's worth mentioning that when people

from outside of Apple get features into a major version,

then I think that's also worth, it's worth highlighting.

- Yeah.

There's one little note Doug Greger last night

mentioned in the little thread on Mastodon

that the SE0384, importing forward declared Objective-C

interfaces and protocols might not make it into 5.9.

Apparently there's some late issues with the implementation.

- Ah, okay.

- So there you go.

- I hadn't seen that.

- Yeah, is there anything else?

I mean, there's lots of things around concurrency.

It seems like this is a bit of a follow-up,

release, adding stuff.

I think convenience async stream, make stream methods,

that's something to make it easier to create async streams.

I've never actually actively created one,

but apparently there was a bit of ceremony

around creating them and keeping around the stream

and the continuation.

So this static method make stream makes that a bit easier.

And that's always nice because often I think the problem

with these, especially when it's new APIs is to figure out

where to get started with them.

And I really like it when there's a very obvious

entry point into APIs and that makes it very easy

to go from there because the return types guide you

with what you get back, you can then inspect and use.

So that's nice.

And I think the other thing worth mentioning briefly

is the custom actor executors.

Is that how I pronounce it?

Is it executors or executors?

I wasn't-

It could be, yep.

The custom actor exit things.

And I've come across that a couple of times because I believe that is particularly interesting

in the context of Neo.

There was a post a while back on the Swift forums that this would help Neo to fully adopt

concurrency because it currently is,

I think there's a bit of a performance hit

if you use concurrency as in async await,

async await mechanism keywords.

I think it has to do with thread jumping, stuff like that.

I'm not really sure of the details.

I'll add a link to the show notes

for people who are interested in further details on that.

But yeah, other than that,

I don't think there's a whole lot new coming in 5.9

that we can see.

Do you think there might be something a bit of a surprise?

I recall in the past,

I think we've had a couple of WWDCs

where entirely new stuff landed

that wasn't actually out in the open.

So the only one I can remember that happening for was in 2019 or is it 19?

When does SwiftUI come out first of all?

I'm terrible with years.

It might, yeah, it could have been 19.

Yeah, I think it might've been 19.

When some of the language features that make SwiftUI possible dropped with, I

mean, they still kind of went through the evolution process, but maybe not quite

as publicly as some of the features.

And so I think that's the only time I can remember that happening with Swift.

It's possible.

I mean, what language feature would virtual reality need? I don't know.

Yeah, it feels like all of that is more like a library thing, right?

That's stuff that would be out of our view.

Yeah, Apple have been working on ARKit in public for many, many years.

And so what if there is any announcement coming?

This is not something that's really getting dropped.

Like SwiftUI kind of dropped out of nowhere.

People were talking about declarative user interfaces,

but it certainly hadn't been worked on in public.

Whereas if there is an AR/VR announcement this year,

this has been worked on in public for five years, eight years even.

Do you think there will be? Will there be a hardware? Will there be a new platform announced next week?

So I've written briefly about this in... I don't really do rulers. Like I...

And these rumors at the moment are unavoidable. You can't look anywhere without hearing somebody

talk about what is... You know, if you read any coverage of this, then it's guaranteed

that this is happening on Monday. I don't really do rumors, but I think it's possible. I think the

noise is so deafening that I'd even go as far as to say it's likely. I do wonder whether it's,

I mean, clearly a VR or a mixed reality headset, I don't think is, I don't think it makes a lot of

sense for Apple to release that as a consumer product.

Um, and one thing I wrote, I think a year ago when, uh, again, this was all

rumors a year ago, um, was that some kind of developer kit makes sense.

But the problem with the developer kit is so a developer kit for an AR, um,

products in the future, but the problem with the developer kit is if you release.

anything as Apple, even if you shout it from the highest rooftop that it's a developer

kit, that's not how it's going to be received.

And so, and Apple know that, of course they do.

They're in a very difficult situation to launch something that isn't what they kind of are

intending to launch.

But also, they're a company that can iterate.

And so I think if we do see something this year, it will be the start of an iteration

process.

So you've given me effectively the politician's answer.

Do you think there will be one?

(both laughing)

- Okay, I'll put my flag in the sand.

No hardware this year.

- That's interesting.

I've been thinking about this.

Lots of people say, you know,

this is boiling over again, right?

And I say again because I recall there were lots of rumors about this last year as well.

And the argument people have this year is, well, there's so much talk about this.

If Apple wanted this to cool this off a bit, you know, not to have a disappointment next

week, they'd have, you know, a little Wall Street Journal, you know, little birdie whisper

something to, you know, to give some hints what's happening.

And because that's not happening, people say, well, there's going to be an announcement

next week about this.

But then I thought, well, we had the same thing last year.

I don't recall there any articles like that coming out to call it off.

So I tend to, I don't know.

I really don't know.

I also don't do rumors and I really like the anticipation to see what's going to be coming

next week.

My biggest problem with AR/VR, it's interesting, but outside of gaming, I don't really see

obvious use cases and there might be less obvious use cases.

What do we know?

There might be stuff that then in hindsight will be very obvious.

That's the thing.

stuff you don't necessarily see coming. It's only obvious in hindsight. But there are VR/AR

goggles out there already. And it seems to me like the only stuff, the only application

that has any sort of traction is games. The video conferencing stuff. I don't know if

that's game changing.

It's not enough, right? Yeah.

There was a Verge thing recently about a demo at Google's event that was apparently very

remarkable.

There's a video conferencing set up with, they had like lenses, you had a big TV screen

and then lenses that gave, you didn't wear goggles, but I think there was a lens array

that gave your eyes different perspectives and that gave you a 3D sense of the partner

you were talking to.

But I mean, is that truly a game changer?

I don't think so.

I don't know.

I think that's also where Apple are quite good at this, where they, what we're doing

is we're looking at every other headset that's currently out there and saying, well, this

isn't good enough.

I would love to see if there is an announcement, I would love to see what that announcement

is and my mind is open.

There was one thing, there was one use

which did strike me at first,

initially as quite an interesting one,

but then as soon as I thought about it for a little bit,

I'm not so keen anymore.

Someone was saying, "Wouldn't it be great

"if you could use a VR or mixed reality headset

"to have effectively unlimited monitor space

"in front of you, right?"

So rather than sitting in front of a 27 or a 32 inch monitor, you might sit in front

of a, you know, as many as you want as a windows, whatever you want.

Right.

Yeah.

But.

So I've used some of these headsets and after an hour or so, your eyes are very

tired, or at least in my experience, my eyes were very tired.

Um, and maybe the, maybe if there's a big leap forward in quality or something like

that, but fundamentally putting a screen that close in front of your eyes, I think is going

to make your eyes quite tired. It certainly makes mine tired. And so the limitations of

anything that you would be expected to sit in front of for eight hours, I'm not sure

I'm going to be able to do that if that's the case.

thinking about wearing, it's quite warm where I am in summer. So just imagining wearing,

I can't wear the Airpods Max like all day, not even for more than an hour. I'll be drenched

in sweat. It's just, that's not going to work. So this will never be like in this climate,

this will won't be a viable work environment with a headset. I mean, unless it's like literally

glasses that would work, but a headset wouldn't work. So I hope that isn't the path we're

on because then I might have to move or get like get beefy AC or something.

So after both of us saying that we don't do rumors, we've now just talked about rumors

for the last 10 minutes.

Well, you know, we're not, we're just guessing. We're playing the little guessing game.

Exactly. Yeah, exactly. Yeah.

But maybe we should move on to some package recommendations instead of stuff

that we have no idea what we're talking about.

Actually, I'm not sure we have any idea about what we're talking about on any subject,

but certainly we have slightly no idea on packages.

We do have packages and I feel like really great about my package selection this week,

if I may brag a bit.

OK, that's good.

It's like every week starts and I think,

God, am I going to find interesting packages. And it always works out, I think.

But this week I'm really happy about, especially some late entries.

Do you mind if I get started to get this rolling?

Go for it, yeah.

And I hope this isn't going to be a letdown for folks,

because I think there's perhaps a bit of my background shining through.

So the first package is Latex Swift UI, or Latex Swift UI.

and MathJax Swift, two packages,

one building on top of the other by Colin Campbell.

So what this does, this gives you a Swift UI view

in which you can render LaTeX math expressions.

So for those who don't know, LaTeX is a markup language

to create mostly scientific documents.

You can create any documents with it,

but it's sort of originated in the science departments

where there was a need for a bit like advanced layouts

around equations, graphs, tables, and stuff like that,

references and that sort of thing.

So think of it as HTML for scientific papers

with the goal of having high fidelity output

for print and display.

Has very rich support, as I said,

for representing math and physics formulas in particular.

I think what it really is, is a procrastination playground for when you need to get your thesis

done because fiddle around with this to the nth degree.

It's a fantastic fertile playground to get completely absorbed with tiny little details.

And that's, I guess, why I love this so much because I spent quite a bit of time when I

I was doing physics, in particular towards the end, to fiddle with LaTeX.

The really nice thing about this, you can try this in a playground.

So what I thought initially when I saw this package is that you need to actually install

a LaTeX package under the hood.

And these are big, like installing LaTeX is, these days it's, I think it's just packages,

you can install it with brew.

but it's always a bit daunting because there are different, like slightly different versions.

There's Lartic, there's Xetic and sort of different variants of them.

This one has no dependencies, external dependencies.

So you can plug this, you could use our Triana Playground thing from the package page, launch

it into a, one of these Playgrounds that we create and then paste in quite complex, you

like equations, like proper big equations

and they come out beautifully.

And it uses under the hood this other package

I mentioned, MathJaxSwift,

which is a Swift wrapper around MathJax.

And that is a JavaScript package to render

that renders LATIC math expressions.

And this is using JavaScript core to do all this.

And the reason, I mean, I find this really great

just because that's the kind of stuff I love as a former physicist,

the fidelity of rendering these equations and stuff.

But I also think this is really great in the context of a thing I mentioned in the past,

and that is graphing tooling.

So you may recall I played around with replacing my usual setup to create graphs

of Python, Jupyter and Matplotlib with Swift, Playgrounds and Charts a couple of months back.

And if you throw this in the mix, which is very easy to do because the other thing I talked about

was based on Swift UI and Charts to create like really, really nice looking graphs.

That gives it yet another superpower because now you can plug in formulas and you know,

any sort of LaTeX expression and add that to the mix and you get, you can do like really

really nice graphs and get the really rich high fidelity output that LaTeX offers and

in combination with the really great output that Charts has and I'll probably stop generating

now because I've been going on for quite a bit now.

So I have no experience with the latex or latex or however you pronounce it.

My dissertation at university was not, it was a computing one, but it was nothing.

I didn't need any equations or anything like that in it.

It was a little bit more applied than theoretical.

And so I've never actually used latex at all.

So I have very little to add to this.

Yeah, just I've taken...

I'm sure it's great though.

Take my joy. And yeah, I could say from the brief testing I've done with, you know, not just a simple equation, quite a bigger one, it renders really nicely.

And MathJax under the hood is a rich JavaScript package that's been around for a bit. So I think there's good reason to believe that this will hold up quite well for any sort of formulas you throw at it.

So there you go. That's a LaTeX Swift UI based on MathJax Swift and both packages are by Colin Campbell.

So my first recommendation is a little more down to earth than a LaTeX processor.

It's a package from Kyle Hughes and it's a URL query item coder. So this is a package that is

potentially quite practical for use in package index code, although I don't think we've had a

need for it yet, but certainly in other server-side Swift code this is the kind of thing you might

find useful. Or actually, if you're creating URLs from within a iOS or macOS application,

you could potentially use this as well. It effectively is an encoder and decoder for

working with codable types as URL query items. So if you're building up a URL string that has

the question mark and then a whole load of parameters after it. It can take any codable type

and represent it in a query string, which I think is potentially a useful thing, but also I would

urge a little caution with it. I mean, obviously, if you're designing an API,

then you have much more, a server-side API, you have much more control over how that API will look.

and you probably don't want to lean too far into query strings.

But there are a lot of instances where you would be interacting with other people's APIs

and maybe they are using query strings or something like that.

So I think it's interesting enough to take a look at it

because it's the kind of thing that when you need to do this,

getting it right is just fiddly, you know?

Yeah, I mean, you always start off with, well, how hard is it going to be?

You have a question mark and then you concatenate an array and the joiner is an ampersand and all that.

And then you forget about the encoding of special characters and all that.

So I think for that alone, it's really nice to have that extra help and not having to worry about these little details.

That's nice.

So mine is a much more tightly scoped recommendation than the first one,

but still potentially very useful.

Nice. I think my second package also falls in that category way more,

and it's a package called CountryKit by Frédéric Jacques.

And this is one of those really nice helper packages that gives you access to a dataset,

and the dataset is as the name implies,

everything around continents, regions,

sub regions and countries.

So not just the countries themselves,

but also groupings if you need access to,

I don't know, like Africa and the nations there

and that sort of thing.

And the nice thing is this wraps around

something called the standard country or area codes

for statistical user, I guess, index.

It's UNM49 on Wikipedia.

- That was going to be my question, yeah.

Where does it get its data from?

Because it's a potentially hot topic

of what countries, continents, well not continents,

I think we've pretty much agreed on the continents.

Actually, I think that's, there's not,

there's very little debate still going on in continents,

but that is definitely not the case with countries.

- Yeah, definitely.

- Well, it links out to a Wikipedia page

for this UN M49 thing, I'm not a standard,

is probably the best name, and it sources that data.

I think that should give you some confidence

as to what you're going to get.

There's some underlying ISO standards as well.

I'm just glancing at the Wikipedia page.

So that's always nice to get you started.

I guess it doesn't absorb you from making sure that what you get is what you need,

but it should be a good start for cases where you have a need for country lists.

It also deals with the abbreviations, the two-letter codes and all that.

So that's nice.

And I think also calling codes, like the phone prefixes and that sort of thing.

So that's quite a nice packet for that.

Country Kids by Frederic Jacques.

You remind me of, so a couple of years ago now,

I did a big survey of iOS and macOS developers

to kind of take the temperature of what the industry was like.

Lots and lots of questions. It was a really big survey.

And in the demographic questions around where people were based,

I needed a list of countries.

and so I did the obvious thing, which is type into Google "list of countries" and I very naively

picked the first list of countries and pasted it into my survey software. And only when I was

looking through the... in fact, I think it may have even got out to live people who were answering

the survey, but only for a couple of hours. And this list was absolute garbage. There was a country

in the list called Texas, which is certainly not a country. I mean, it's a big state, but

it's not a country. And yeah, so it's really, I mean, obviously, even if you get a good list,

there are potential problems with countries, but there's an enormous amount of bad data in that

arena out there as well. So this is potentially very useful.

Yeah, definitely do check before you use it, but this should give you a good start at least.

So my next package is by Lucas Werner Kuipers and it's called VueKit.

And it's a relatively new package.

It's been only around for a couple of months, but it's effectively a

SwiftUI like declarative syntax for UIKit.

And so it uses result builders a little bit like SwiftUI does.

And you can make vertical stacks and you can make horizontal stacks and you can

and make UI labels and you'll put a UI label in

and it's got view modifiers and all the rest of it.

And so if you're still building

or needing to build something with UIKit,

but you are missing a little bit

of the declarative syntax of SwiftUI,

then you might want to take a quick look at this.

It's the kind of thing that I,

I like packages like this in terms of,

It's a fun way to look at an existing technology.

But I also, and again, I'm not quite sure

what it is with me at the moment,

but every time I recommend a package,

I feel like I want to present both sides

of the argument of whether to use it or not.

Because one argument against using something like this

is that you introduce a dependency

right at the heart of your application.

That UIKit does not use this kind of thing by default.

And so I do like stuff like this.

Certainly, I really enjoy creating applications in this declarative style that we've got used to with SwiftUI.

So I would consider this if I needed to do some UI kit again.

Nice. So this deals with the layout part of UI views,

because obviously SwiftUI is very different in how it manages state and all that.

Yeah, so this I don't think is tackling any of that kind of stuff.

I think it is purely a, from what I can see in the README file,

it is purely a view builder technology.

Interesting. Cool.

My next pick is called DC Settings by David Caddy.

And I like this one.

We did have a settings package recently.

So this, I should preface this,

this is about creating a settings screen.

And we did talk about or discuss another package

by Cinder Solos called Just Settings a while back.

Yeah. - We did.

- And this is a slightly different take

because this offers up a DSL

to configure your setting screen.

So like a result builder based approach

to define what your settings are

and then it does the, you know,

the assembling of the UI controls to lay it out.

And if you look at the README, it looks really compelling.

It's very easy to create a setting screen and that looks really nice.

Especially on iOS, it looks exactly like it looks in settings.

On macOS, there's a bit of a caveat.

So you need to be okay with the new system settings on macOS Ventura in order to agree

with that statement that it's nice looking. I think Ventura is okay. I don't share that

big complaint about the settings there. I can see the UI issues of it, maybe not scrolling

to the right places necessarily or search being a bit weird sometimes, but I don't think

that that's a fundamental problem.

That's a little bit of some glitches

with the way it's looking right now.

- Yeah, I would agree with you.

I think the settings on Venture is, it's different.

And there are some little things

that might need tweaking in future versions,

but fundamentally, I don't really have a big problem with it.

- So if you're okay with that, you get really nice results.

And you write it once, you get it on both platforms

and it looks like it does right now in both of these platforms,

like the settings application, it looks like a system rendered thing,

which is a good thing, I think.

Yes.

I like it when controls are in the common style,

you know, there's no surprises there.

It's standard controls, you know, that stuff works,

like, you know, selecting elements,

searching and that sort of thing.

When that's a standard way, I really prefer that over highly customized things

where it's not always obvious how stuff works.

So there you go, that's DC Settings by David Caddy.

My final recommendation for this week is one that I think we should use.

It's a topic that's come up before and we've not ever actually implemented it.

But I think we should, I'm not, I'm certainly not promising that we'll look at it before the next episode, but I think we should at some point implement SwiftLint and add SwiftLint to our project to, to do all the things that SwiftLint does.

You know, it's a, it's a valuable tool.

And I know we talked about it right at the beginning, and I think right at the beginning,

it was kind of challenging to add it to a package.swift-based project because it didn't have

external tool support. But that is no longer the case. And in fact, we now have Swift package

plugins that make this kind of thing easy. And so my recommendation this week is Adam Young's

SwiftLint plugin, which is a Swift package plugin for SwiftLint. So all it really does is add the

ability to run SwiftLint through Swift package, but I think it's something that we should look at.

And the problem is, and one of the reasons that this has gone on even a long time after we have

package plugins available, is that the longer you have not had SwiftLint on the project,

on a project, the bigger task adding SwiftLint is, because it's going to create an enormous

amount of noise when we first add it as we decide, well, which rules are important, which are not.

And then the inevitable corrections of, well, we talked last episode about how much code we have.

It's certainly not a small project anymore. And so adding this is not going to be a trivial task,

but it's the kind of thing that I think at some point we need to bite the bullet and say, okay,

we need to implement this and get that in.

- Yeah, I'd be very much in favor of that.

It bugs me to no end that we have different spellings

of things and that's something that I mess.

I've always been, so the thing that bugs me most is URL.

And that's because I sort of changed my mind

halfway through, I've always been on the fence. I don't like the fully capitalized acronyms,

right? Because you sometimes end up with big blocks of just capital letters in like four or

five of them if you have unfortunate alignment of two acronyms. Imagine you had, for some strange

recently, URL, HTML URL, right? I think this style guide says that should be HTML capitalized

and URL capitalized, but that looks terrible. But what's the alternative? HTML lowercase

and then capital U and RL lowercase? That looks nicer, but then you've introduced the

mix and I started out with URL as just capital U and then lowercase RL and then halfway through

I've started writing package URL and URL or capital letters and ID is the other one that

I'm always on the fence about whether it should be both capital I and capital D or

capital I and lowercase d. I just want a decision and then I'm happy.

Yes, it's funny, I've been back and forth on that exact issue too, but I settled on the other side

of it in that Pascal case is, I think Pascal case should be Pascal case, URL, capital U,

lowercase rl. And yes, it's not correct in the acronym, but these acronyms, we're rarely using

acronyms that we don't all know. And they do look better in my opinion, in just standard old Pascal

case. But as well, SwiftLint, I mean, SwiftLint does do some style stuff like that, but it also,

Like, linting is more than just style.

It's looking a little deeper than style.

- Yeah, I'd definitely be interested.

I did run Periphery a while back,

which is a different but kind of similar tool

in that it looks at your source code

and gives you an analysis and highlights issues.

In this case, Periphery highlights unused code,

so it allows you to prune functions, methods,

things that you aren't actually using.

Swift does a good job of highlighting variables that you're not using,

but this identifies functions that you're not using,

which the compiler wouldn't otherwise let you know about.

And I really like those tools because they automate the

maintenance part that is really hard to do otherwise.

There's no way to detect this automatically,

like what periphery does, and the linting is

is also really nice because you might have some style,

but it's easy to slip up and introduce things inadvertently.

And especially if you have contributors,

then it's very clear if you have a tool like that,

what the expectations are around formatting

and you don't need to have a discussion around,

well, should it be like this or should it be like this?

Because there's a certain set of ground rules,

what it should look like.

And you don't need to tighten the screws on all of them,

But I think there's a set of sensible rules that just make the source code more manageable.

And I think it's a great thing to have.

It's also worth mentioning that this will bring our Swift code in line with our front-end code

because we've had Linting on our JavaScript and our CSS for quite a while now.

And so that happens as part of our build process as well.

And I also have some plugins in the editor that I use to edit JavaScript and CSS,

where on save it lints and formats my code.

So that's a way off for Swift yet, but we certainly do have some linting in the project.

And let's bring our Swift code in line with that.

Nice. As long as we don't do it the way a colleague did it, like this is 20 years ago.

This is my first interaction with linting. It was a Java code base and he had a change,

like a significant change to the project. And on top of it, he ran a linter. And that was the merge.

God, no, you're killing me.

No, I promise you I won't sneak any significant changes in with the Linting commit.

All right, I think that's probably it for this week and we will be back in a couple of weeks

with more news based on no rumors but the facts of what was announced at WWDC and of course more

package recommendations as usual. Excellent, well see you in two weeks. Bye-bye. See you in two

weeks. Bye bye.