Adding custom values to SwiftUI’s environment has never been very hard to do to. However, the syntax for doing it is verbose and easy to forget. To refresh your mind, take a look at this post where I explain how to add your own environment values to a SwiftUI view. To summarize what’s shown in that post; here’s how you add a custom value to the environment using Xcode 15 and earlier: private struct DateFormatterKey: EnvironmentKey { static let defaultValue: DateFormatter = { let formatter = DateFormatter() formatter.locale = Locale(identifier: "en_US_POSIX") formatter.dateFormat = "MM/dd/yyyy" return formatter }() } extension EnvironmentValues...

Xcode 16 and iOS 18 come with a feature that allows us to build elaborate preview environments using a new PreviewModifier protocol. This protocol allows us to define objects that can create a single context or environment that’s cached and used across your SwiftUI previews. This is useful because it means that you could, for example, populate a database with a bunch of mock data that is then used in your previews. You can also use PreviewModifier to apply specific styling to your previews, to wrap them all in a specific wrapper, and more. Essentially, they’re a tool that allows...

SwiftUI in iOS 18 and macOS 15 has gained a new trick; it can mix colors. This means that it’s now possible to take a color and modify it by applying another color to it using a provided percentage. The video below shows how this works: Notice how the large rectangle updates its color to be a certain mix of a left and right color. In the video I use distinct colors but you can also mix with white or black to lighten or darken your color. One use of color mixing I like a lot is to explore color...

In iOS 18, Apple has revamped the way that tab bars look. They used to be positioned at the bottom of the screen with an icon and a text underneath. Starting with iOS 18, tab bars will no longer be displayed in that manner. Instead, on iPad you will have your tab bar on the top of the screen with text-only items while on iPhone your tab bar will retain its old look. In addition to changing how a tab bar looks, Apple has also added new behavior to the tab bar; it can expand into a sidebar that contains...

In iOS 18, SwiftUI's ScrollView has gotten lots of love. We have several new features for ScrollView that give tons of control to us as developers. One of my favorite interactions with scroll views is when I can drag on a list an a header image animates along with it. In UIKit we'd implement a UIScrollViewDelegate and read the content offset on scroll. In SwiftUI we could achieve the stretchy header effect with GeometryReader but that's never felt like a nice solution. In iOS 18, it's possible to achieve a stretchy header with little to no workarounds by using the...

One of the key features that was missing from SwiftUI when it first shipped was a good way to do programmatic navigation. There were some ways to handle this before iOS 16 introduced NavigationPath but it wasn’t very satisfying to use those APIs and they could be rather unreliable at times. To see an example, take a look at this post I wrote about handling deeplinks on iOS 14. In this post, I’d like to revisit programmatic navigation through iOS 16’s NavigationPath API which is a huge leap forward in terms of developer experience and reliability at the same time....

By default, a NavigationSplitView in SwiftUI will show users an option to toggle the visibility of the sidebar. If you want to prevent this button from showing up so that users will always have to see your sidebar, you can do this by applying the toolbar(removing:) view modifier to your split view's sidebar as follows: NavigationSplitView(sidebar: { ExercisesList() .toolbar(removing: .sidebarToggle) }, detail: { ExerciseDetail(exercise: exercises.first!) }) The downside of doing this is that the button is hidden both in portrait and landscape modes. The result is that landscape users can no longer access your app's sidebar. To fix this you...

With iOS 17, we’ve gained a new way to provide observable data to our SwiftUI views. Until iOS 17, we’d use either an ObservableObject with @StateObject, @ObservedObject, or @EnvironmentObject whenever we had a reference type that we wanted to observe in one of our SwiftUI views. For lots of apps this worked absolutely fine, but these objects have a dependency on the Combine framework (which in my opinion isn’t a big deal), and they made it really hard for developers to limit which properties a view would observe. In iOS 17, we gained the new @Observable macro. I wrote about...

WIth the introduction of Xcode 15 beta and its corresponding beta OSses (I would say iOS 17 beta, but of course we also get macOS, iPadOS, and other betas...) Apple has introduced new state mangement tools for SwiftUI. One of these new tools is the @Bindable property wrapper. In an earlier post I explained that @Binding and @Bindable do not solve the same problem, and that they will co-exist in your applications. In this post, I would like to clarify the purpose and the use cases for @Bindable a little bit better so that you can make better decisions when...

Sometimes in SwiftUI apps I’ll find that I have a model with an optional value that I’d like to pass to a view that requires a non optional value. This is especially the case when you’re using Core Data in your SwiftUI apps and use auto-generated models. Consider the following example: class SearchService: ObservableObject { @Published var results: [SearchResult] = [] @Published var query: String? } Let me start by acknowledging that yes, this object can be written with a query: String = "" instead of an optional String?. Unfortunately, we don’t always own or control the models and objects...