Re: 🎨 SwiftUI Tips, Error Handling, and a Trip Down Memory Lane
Hey everyone!
Welcome to issue #80 of Not only Swift! In this issue, I’ve got a bunch of cool libraries and tools for you, including a better way to handle errors in Swift, a Swift package that simplifies working with SF Symbols in SwiftUI, and another one that helps you swipe any view in SwiftUI - for those times when, you know, you are in the mood for swiping left or right. There’s also an article about the first programming language I ever learned - BASIC. Are you ready for a trip down memory lane?
This week, I am away for a short break to the Cotswolds, and next week, I’ll be in London to record the next episode of Firebase Release Notes. This means there will be no livestream on my channel, but you can watch the most recent one, in which Antoine van der Lee joined me to talk about RocketSim and how it can help you build better apps. It was a fun conversation, and Antoine shared a lot of behind-the-scenes details about the project, how he came up with the idea in the first place, and how he decides which features to work on next. Definitely check it out!
As always, I’d love to hear your thoughts and feedback. What topics would you like to see covered in future issues? Let me know!
At iOSKonf, I will be giving an updated version of my talk Why every SwiftUl developer should care about the Environment. It goes behind the scenes of the SwiftUI Environment, and I am super excited about it. There are a bunch of cool demos, so it’s definitely not going to be boring!
AI Heroes being an AI conference, my talk will be about MCP, the Model Context Protocol, and how you can use it to allows LLMs to connect with other apps and APIs. The title of the talk is Beyond Prompts: Building Intelligent Applications with Genkit and the Model Context Protocol, and one of my demos will show how to connect LLMs to Keynote to create the slides for my talk. Let’s see how this goes! If you’re interested in going, here is a discount code for 30% off: AIH25-SWIFT-SPK30
If you’re attending either conference, please come say hello!
Do you remember the days of using Reachability to check for network status? I sure do, and it was a pain to set up. Thankfully, Apple has made it easier with the introduction of NWPathMonitor in iOS 12.
Interestingly, NWPathMonitor conforms to the AsyncSequence protocol, which means we can use it to monitor network status changes in a more modern and efficient way.
In this article, Matthaus demonstrates how you can use NWPathMonitor as an AsyncSequence to monitor network status changes in SwiftUI. What I like about this approach is how it enables us to keep the relevant code hyper-localised to the place where we need it, rather than having to sprinkle it around the codebase.
We all hate cryptic error messages, don’t we? So as responsible developers, we strive to make our error messages as clear and helpful as possible. But you might have noticed that Swift doesn’t seem to pick up your well-crafted error messages, instead showing cryptic messages like “The operation couldn’t be completed. (AppName.YourCustomError error 0.)“.
Cihat not only describes the problem in his article, he also created a drop-in library to solve it. On top of providing a developer-friendly API that expands on the existing LocalizedError protocol, it also comes with a bunch of presets for common error types - very convenient!
When styling text in SwiftUI, I never know which modifier to use for changing the foreground color - is it foregroundStyle, foregroundColor, or tint?
In this article, Natalia clarifies the differences between these modifiers and provides examples of when to use each one.
The bottom line is that you should probably use foregroundStyle most of the time.
And if you need some extra customisation, you can use a custom text renderer. Given how much heavy lifting SwiftUI does for us, going down that route doens’t feel very compelling, but it’s good to know it’s there.
Also, I noticed that Natalia mentiones the SwiftUI environment in a throw-away line:
It accepted a Color and applied it in the environment, affecting text and other foreground elements within the view hierarchy.
If you’d like to learn more about the SwiftUI environment, check out the recording of my talk at SwiftHeroes: Why every SwiftUI developer should care about the environment, or come to iOSKonf25 in Skopje (May 13th - 15th), where I will be giving an updated version of that talk.
Screen tracking is a popular way to track user behaviour in mobile apps. When using Firebase Analytics, you typically end up with code like this:
struct SomeScreen: View { var body: some View { VStack { Text("Hello, World!") } .analyticsScreen(name: "SomeScreen") }}
Which doesn’t look too bad, but once you start renaming your screens, you will invitably forget to update the screen name in the analytics call, as it’s just a string literal.
In this article, Aline shows a nifty little trick to avoid this issue by using the #file compile directive to automatically extract the screen name from the file path.
The only thing I would probably do differently is to use just a view modifier function instead of a full blown view modifier, but overall, it’s a great solution.
The first programming language I learned was BASIC (on a Philips MSX home computer - it was actually a version of Microsoft BASIC), so this was a fascinating read for me.
But what I found even more interesting about this article is how Bill manages to explain complex concepts (such as machine code and how an interpreter works) in a way that is both engaging and easy to understand. Definitely something we can all learn from.
Until iOS 15, the only swipe action you could add to a List view was the delete action. I once went down the rabbit hole of re-implementing the entire List view just to enable support for other swipe actions, but never ended up publishing it. Thankfully so, as I would’ve gotten sherlocked by Apple’s introduction of full support for swipe actions in List in iOS 15!
If you need swipe actions on other views, Andrew is here to save the day!
SwipeActions is a lightweight SwiftUI library that brings customizable swipe actions to any view, not just Lists. It’s very customisable, with a bunch of view modifiers to tweak the appearance and behaviour of the swipe actions.
SF Symbols are a great way to add well-designed icons to your app, but they can be a bit of a pain to work with, especially when searching for the right symbol for your use case. There are just so many of them! In addition all of Apple’s APIs that use SF Symbols are stringly typed. On the one hand, this means that it’s easy to add custom symbols (I wrote about how to create custom SF Symbols here), but on the other hand, it means that it’s easy to make mistakes when using them in your code.
James puts and end to this with his new Swift package, SFSymbolKit. It provides type-safe and convenient extensions for common SwiftUI views, eliminating the need for string literals and providing compile-time validation for symbol names. Definitely checkout the best practices document document, which shows how to use SF Symbols’ features such as variants, dynamic color, symbol appearance, animations, etc.