Issue 704 21st March 2025 Written by Dave Verwer

I received a suggestion earlier this week from Kyle Bashour to check out his latest package, AestheticText. It’s a cool little package that automatically adjusts the line breaks in a piece of text so that each line is approximately the same length.

But it also set me thinking about how I think about choosing a package that includes a UI component.

I have a friend who has previously told me that even importing UIKit or SwiftUI rules a package out for them. I don’t take quite that position, but I certainly spend more time considering whether to use a UI component than something without those imports. There’s nothing inherently bad about packages that include a UI component, but it has been my experience that they tend to take hold in an app’s codebase in a much stronger way than non-visual components.

I remember helping a client with an app that used a collection view library that provided the screen layout they wanted when they first built the app. That component ran out of steam, and the library had stopped receiving updates. Extracting it caused them significant pain and even changed the core UI of the app in ways that they had not planned.

One of my main considerations when choosing a package dependency is the consequences of removing it. Importing someone else’s code can save you significant time, but you also import all the package author’s bugs¹ and assumptions, and you might need to remove dependencies later.

Kyle’s package is a great example of a UI component I would consider. Without it, text would revert to a standard layout, and the app would lose some polish, but there would be no other side effects.

I’m not saying you should or shouldn’t use Kyle’s label component, but I am saying it’s firmly in the category of UI components that make sense to me, unlike ones that reach deeper into the core of an app.

Dave Verwer

​Swift development moves fast, and so should your code reviews. CodeRabbit analyzes your iOS pull requests, providing intelligent feedback on Swift-specific patterns, performance optimizations, and potential bugs before they reach production. Our custom AST Grep rules catch subtle Swift issues that traditional linters miss, while one-click fix suggestions help maintain SwiftUI best practices and Swift language conventions automatically. Get started today.

David Smith on the community’s negative reaction to the rumour of design changes in upcoming iOS and macOS releases:

Negativity isn’t exclusive to our community, it’s everywhere, and worse online. It’s challenging, but I try to choose optimism where I can, and I’m fully with David on this.

You might have seen discussions around the new coding editor Zed recently. It’s written with Rust and appears to be trying to take on VS Code. Tornike Gomareli has written up this useful article on getting it working with Swift using xcode-build-server and LSP.

Several people, including author Sarun Wongpatcharapakorn, told me about this tool after my feature requests when I linked to Framous last week. Sarun’s app does everything I asked for, and more! I had no idea this existed.

No matter which side of the fence you are on with using LLM tools for coding, you should read Simon Willison’s latest article on “vibe coding” and why you shouldn’t dismiss it, even as an experienced developer. No one writes as clearly as Simon on this topic right now, and his writing is all based on actual usage and genuine expertise in the subject matter.

SwiftUI’s Group construct adds structure without adding container views, but is it always that simple? Chris Eidhof has some words of warning, in case you think it’s as straightforward as I did. 😬 Oh, and if you’re in the mood for more “why I avoid” information from Chris, he followed it up with a post on bindings.

I’ve never seen an App Clip used in the wild, at least here in the UK. So, I was surprised to see Andrew Yates’s article about using them for marketing. If nothing else, you should open his post to try one out with a real app!

It’s been a little while since 2024’s edition of Swift Heroes, but here’s a reminder of what you missed and why you might want to attend the next edition. 🦸‍♂️

Senior iOS Developer - Productivity Team @ komoot GmbH – As a Senior iOS Developer, you’ll be an essential part of our newly established iOS Developer Productivity Team. You’ll work closely with other iOS developers and help them perform at their highest technical level. – Remote (within European timezones)

iOS framework developer @ Nutrient (formerly PSPDFKit) – Design APIs that will affect hundreds of apps, and create UIs used by millions of users. Collaborate globally in a small team working on the leading document SDK for iOS, macOS and visionOS. Make the most of a flexible schedule, and attend annual retreats at exciting places around the world. – Remote (Anywhere)

Coding. 🎯