Issue 748

17^th April 2026

Written by Dave Verwer

Comment

One community announcement that stood out to me this week was the Hummingbird project announcing their AI tool policy.

The topic of LLM-written pull requests on open-source projects has been escalating for a while now. Maintainers are being overwhelmed with AI slop to the point of shutting down bug bounties. AI agents are writing retaliatory blog posts when their pull requests get closed. Is either of these events the Archduke Ferdinand moment of the first great human vs. machine war? 😬 Probably not, but it’s definitely something that’s causing friction in our communities.

We’re even being affected a little at the Swift Package Index, although not to the point of it being a huge issue, and not in the main repository. Instead, it seems that LLMs have baked into their knowledge the old method for submitting a package to the index which we unfortunately no longer support. Currently, around 30% of package submissions are coming from agents, and they always use the incorrect method. It’s not a huge problem, but it’s more work, and shows how far this issue stretches.

Having a policy in place is a great place to start, and I’m glad to see Hummingbird tackle the subject. This issue isn’t going to go away, and having a written policy helps prevent arguments.

The policy centres around the idea that LLM-generated PRs are acceptable, but only if a human was involved and understands the code. It also requires transparency around how much of a PR’s code was tool-generated, and that PR descriptions are written primarily by the contributor, not an LLM. Finally, and I really like this point, you can’t implement “good first issues” with a tool. Those have a special purpose, and are protected.

It’s so important that we encourage open-source participation, and in my opinion, it’s not reasonable or practical to completely ban these tools. They are remarkable when used well. I think this is a great initiative from the Hummingbird team, and if you run or help maintain an open source project, even a small one, you might want to think about what your policy is, and get it written down.

– Dave Verwer

Tools

If you’ve used Chris Eidhof’s SwiftUI Field Guide, you might wonder how it works. Did he really implement everything the site demonstrates in TypeScript? Yes, he actually did, but he took a different approach with his new project and the FormatStyle Guide is a Wasm project! The page takes a few seconds to load, but you can be sure the results are accurate because it’s running Swift behind the scenes. This is a great example of where a project genuinely benefits from running Swift via Wasm. 🚀

Alberto De Bortoli writes about Luca, a “minimalistic, lightweight, decentralised tool and skill manager” that solves a genuine problem for teams: Making sure everyone has the same versions of the tools needed to work on a project. From the announcement of this post:

It started as an internal tool to pin CLI binary versions per project. It now handles AI agent skills management too and has a growing ecosystem around it.

It looks like a promising tool, and if you’ve been reading Alberto’s blog for any length of time, you’ll know that solving this problem for teams is very much an area of interest for him.

Code

Matt Massicotte writes about package traits, which have been in the language since 6.1 but which are now possible to set in Xcode projects as of Xcode 26.4. I like the idea of traits, but they do strike me as a source of potential bugs unless used carefully. They can potentially completely switch the implementation of an API based on the trait, so make sure your tests cover all possible configurations!

Shaun Donnelly:

So, I replaced it with a Cloudflare Worker that’s about 200 lines of TypeScript plus a few lines of Swift in the app. The whole thing costs nothing on the free tier.

Cloudflare Workers are great and push notifications are easier than you think. I would thoroughly recommend the solution Shaun came up with in this post as a great (and free!) venue for any small app that doesn’t require any other aspect of a custom back-end server.

Majid Jabrayilov:

Whenever you consider creating a scrollable screen in SwiftUI, you might think of using a List. However, it’s not always the best choice. Lists are great for displaying uniform data. For anything else, a ScrollView with a lazy stack is almost always the best option.

The SwiftUI List is great, but it’s quite inflexible once you start to stray too far from something like a list of emails in Mail.app. That doesn’t mean you need to build something from first principles every time, though.

Business and Marketing

I really like smaller, “boutique”, ad networks like the one Tyler Hillsman launched this week. They tend to have higher quality advertisers and provide higher quality traffic. What makes Guild Ads a little different is the business model:

Every week, the network has a price. That price fluctuates with demand: if the network sells out, the price for the following week goes up; if it does not fill, the price goes down. Advertisers choose how much of the network they want to buy. When inventory is gone, it is gone.

I like that model and I wish Tyler, and everyone who participates, luck with it!

And finally...

You know what would make 2026 the best WWDC ever? An official “Lil Finder Guy” scavenger hunt across Apple Park! 🕵️‍♂️