On iOS 26 we have lots of new ways to reimagine our UIs with Liquid Glass. This means that we can take a look at Apple’s built-in applications and find interesting applications of Liquid Glass that we can use to enhance our understanding of how Liquid Glass components can be built, and to understand what Apple considers to be good practice for Liquid Glass interfaces. In this post, we’re going to replicate a control that’s part of the new maps app. It’s a vertical stack of two buttons in a single Liquid Glass container. Here’s what the component looks like...

Liquid Glass is iOS 26’s new design language. This means that a lot of apps will be adopting a new UI philosophy that might require some significant changes to how you’re designing your app’s UI. If you’re not ready to adopt Liquid Glass just yet, Apple has provided you an escape hatch that should be usable until the next major iOS release. I recently explored updating my workout app Maxine to work well with Liquid Glass tab bars which you can learn more about here. In this post, I’d like to explore how we can build custom Liquid Glass components...

Swift 6.2 comes with several quality of life improvements for concurrency. One of these features is the ability to have actor-isolated conformances to protocols. Another feature is that your code will now run on the main actor by default. This does mean that sometimes, you’ll run into compiler errors. In this blog post, I’ll explore these errors, and how you can fix them when you do. Before we do, let’s briefly talk about actor-isolated protocol conformance to understand what this feature is about. Understanding actor-isolated protocol conformance Protocols in Swift can require certain functions or properties to be nonisolated. For...

Swift 6.2 is available and it comes with several improvements to Swift Concurrency. One of these features is the @concurrent declaration that we can apply to nonisolated functions. In this post, you will learn a bit more about what @concurrent is, why it was added to the language, and when you should be using @concurrent. Before we dig into @concurrent itself, I’d like to provide a little bit of context by exploring another Swift 6.2 feature called nonisolated(nonsending) because without that, @concurrent wouldn’t exist at all. And to make sense of nonisolated(nonsending) we’ll go back to nonisolated functions. Exploring nonisolated...

When your app has a tab bar and you recompile it using Xcode 26, you will automatically see that your tab bar has a new look and feel based on Liquid Glass. In this blog post, we’ll explore the new tab bar, and which new capabilities we’ve gained with the Liquid Glass redesign. By the end of this post you’ll have a much better sense of how Liquid Glass changes your app’s tab bar, and how you can configure the tab bar to really lean into iOS 26’s Liquid Glass design philosophy. Tab Bar basics in iOS 26 If you’ve...

On iOS 26, iPadOS 26 and more, your apps will take on a whole new look based on Apple's Liquid Glass redesign. All you need to do to adopt this new style in your apps is recompile. Once recompiled, your app will have all-new UI components which means your app will look fresh and right at home in Apple's latest OS. That said, there are many reasons why you might not want to adopt Liquid Glass just yet. It's a big redesign and for lots of apps there will be work to do to properly adapt your designs to fit...

With Swift 6.2, Apple has made a several improvements to Swift Concurrency and its approachability. One of the biggest changes is that new Xcode projects will now, by default, apply an implicit main actor annotation to all your code. This essentially makes your apps single-threaded by default. I really like this change because without this change it was far too easy to accidentally introduce loads of concurrency in your apps. In this post I'd like to take a quick look at how you can control this setting as well as the setting for nonisolated(nonsending) from Xcode 26's build settings menu....

It's no secret that Swift concurrency can be pretty difficult to learn. There are a lot of concepts that are different from what you're used to when you were writing code in GCD. Apple recognized this in one of their vision documents and they set out to make changes to how concurrency works in Swift 6.2. They're not going to change the fundamentals of how things work. What they will mainly change is where code will run by default. In this blog post, I would like to take a look at the two main features that will change how your...

As Swift evolves, a lot of new evolution proposals get merged into the language. Eventually these new language versions get shipped with Xcode, but sometimes you might want to try out Swift toolchains before they're available inside of Xcode. For example, I'm currently experimenting with Swift 6.2's upcoming features to see how they will impact certain coding patterns once 6.2 becomes available for everybody. This means that I'm trying out proposals like SE-0461 that can change where nonisolated async functions run. This specific proposal requires me to turn on an upcoming feature flag. To do this in SPM, we need...

A lot of modern apps have a networking component to them. This could be because your app relies on a server entirely for all data, or you’re just sending a couple of requests as a back up or to kick off some server side processing. When implementing networking, it’s not uncommon for developers to check the network’s availability before making a network request. The reasoning behind such a check is that we can inform the user that their request will fail before we even attempt to make the request. Sound like good UX, right? The question is whether it really...