I can't wait for my timeline to collapse when Apple unveils iOS 18 with an OpenAI partnership at #WWDC next week. And BTW, Ice Cubes will move quickly to iOS 18 only depending on what #SwiftUI exclusive features there are!
Took me a while to get the details right but I think I got it now.
This officially only adds the ability to add a location to an entry but I had to re-think a couple fundamental ideas of the layout to make this future-proof.
This feels like a good basis for further features now.
Here's a subtle #accessibility interaction I frequently see developers overlook:
#SwiftUI makes it very easy to customize Button's appearance at the call-site, either by decorating the Button's label or by applying View Modifiers to the Button itself.
There is no time like the present to grab a deal, and what a deal this is. Simply the best written resources for #SwiftUI out there. You will not regret it. I own every one of them and use them regularly. I only endorse products I use. https://www.bigmountainstudio.com/a/77jt8
This is the 6th video in a 7 part series on building a #SwiftUI app using #WeatherKit.
In this video I am going to show you how you can use the CoreLocation and MapKit frameworks to search for and add cities by name. Final persistence video on Wednesday. https://youtu.be/puelrPxXj-8
WWDC24 is right around the corner. Before the excitement and rush of what's to come, I want to share some navigation fun facts and tips. None of this is new, having been discussed previously in sessions, etc. From talking with developers, these are parts of the system that are often overlooked, or forgotten about #21DaysOfSwiftUINavigation#SwiftUI This is all running on macOS Sonoma 14.4, Xcode 15.3
We dive deeper into navigationDestination. We learned yesterday the closure passed to navigationDestination is reevaluated when its dependencies change. This keeps the destination presented by a navigationDestination up to date with the values captured by the closure. Be aware of how much you are capturing inside this navigationDestination closure! When you build up a stack of views with a NavigationStack, you might be building up a complex dependency graph — thus, cycles. #SwiftUI
11 cont) Let's examine a navigation cycle. This example shows a navigation cycle that is a client bug. It's hard to spot why immediately. The Day11_Bad_Cycle view has an environmental dependency on MyEnvironmentKey. The value of MyEnvironmentKey is a closure. Closures are not equatable or comparable in Swift, the graph always has to assume they have changed value. Down below, the navigationDestination captures self by means of localState! When I tap push, the app freezes up 😮 #SwiftUI
11 cont) When the navigation system tries to push, it evaluates the navigationDestination. The navigationDestination captured self, and established a dependency on self. When SwiftUI checks if the navigationDestination has changed, it has no choice but to assume that it has! Becuase Day11_Bad_Cycle has the non-Equatable functional property. So it reevaluates the destination view and updates the view. Which starts the cycle over again. #SwiftUI
11 cont) The potential for cycles exists in other places in SwiftUI. They come up often in navigation because you can inadvertently build large interconnected dependencies when stacking views up. The solution here is a general best practice: make your environment values equatable so SwiftUI can efficiently diff them. (or for a quick and dirty proof, use a capture list to capture only [localState] and avoid establish the dependency on the environment.) #SwiftUI
11 final) In this version, I've wrapped the closure up in a Equatable Box. For a proof-of-concept, I use the @Namespace property wrapper to establish identity, given that I know that closure values identity is tied to the Namespace.The cycle is solved. The takeaway, make your environment values Equatable when possible, and when you can't, don't capture them as part of .navigationDestinations #SwiftUI
Shout out to a particular follower who knows where they are who filed quality FBs about this.
Day 12) A lot of what I've covered so far I only thought to cover through speaking with developers online and at last year's DubDub. Or via the sub-toots 🙃 For day 12, if any of the preceding tips have been useful to you, would you like more detail on a specific topic? Is your team running into issues with navigation? Are there constructions you're wondering are undefined behavior? #SwiftUI#21DaysOfSwiftUINavigation
12 cont) days 1-11 were more successful than I anticipated! Not a single question today. I'll leave day 12 as an open invitation, I can certainly scale up from zero. The new developer forums are also ready for action. The show must go on: .toolbar(removing: .sidebarToggle) is not a tool to fix the sidebar open, or worse, closed. You remove the sidebar toggle to add a custom one, modify the tool tip, or position it in a spot that suits your app's design better #SwiftUI#21DaysOfSwiftUINavigation
12 final) Given the size classes and interactions supported, fixing the sidebar is a rare, and currently unsupported (FBs welcome). On iPad in certain size classes users can drag from the leading edge to reveal the sidebar. Lest we forget the iPad mini in portrait where a fixed sidebar would feel cramped. And lest we really not forget this peek interaction on macOS #SwiftUI#21DaysOfSwiftUINavigation
An Xcode Previews window showing a macOS preview of a NavigationSplitView. Hovering the mouse some 5-10 points from the leading edge of the window reveal a peek of the sidebar. The user can grab the peeking sidebar and drag it open from a collapsed state. import SwiftUI struct Day12: View { var body: some View { NavigationSplitView { List { ForEach(0...10, id: .self) { i in NavigationLink("Option (i)", value: i) } } } detail:{ ContentUnavailableView( "Make your selection", systemImage: "circle.hexagongrid.fill") .symbolRenderingMode(.multicolor) .symbolEffect(.pulse, options: .repeating) } } } #Preview { Day12() }
macOS supports Cmd-click deselect out of the box. This works with value-destination and view destination links. You'll notice the view-destination link’s (Settings) selection is cleared when the environmental action dismiss is called from the detail view #SwiftUI#21DaysOfSwiftUINavigation
macOS Xcode Previews showing a basic NavigationSplitView. The 3 options in the sidebar as successively clicked and Command-clicked, which dismisses the presented view. Additionally, a button that calls the dismiss action form the detail column will also dismiss the presented view and clear selection. import SwiftUI struct Day13: View { var body: some View { NavigationSplitView { List { NavigationLink(value: "House") { Label("Home", systemImage: "house") } NavigationLink(value: "Profile") { Label("Profile", systemImage: "person") } NavigationLink { DismissibleView() } label: { Label( "Settings", systemImage: "gear") } } .navigationDestination(for: String.self) { str in if str == "House" { Color.accentColor } else { Color.mint } } } detail: { Text("No selection") } } } struct DismissibleView: View { @Environment(.dismiss) var dismiss var body: some View { ZStack { Color.gray Button("Dismiss") { dismiss() } } } } #Preview { Day13() }
NavigationSplitView has opinionated behavior when collapsing from a regular to compact size class. In the absence of a preferredCompactColumn argument, NavigationSplitView will show the most "interesting" trailing column. A column is interesting if it's been root-replaced, its previous column has a non-nil List selection binding, or if it contains a NavigationStack with a non-empty path. Given no interesting columns, the sidebar will be on top. #SwiftUI#21DaysOfSwiftUINavigation