Post

Replies

Boosts

Views

Activity

Reply to Simple solution for visibilityPriority for toolbar items.
Version 1.1 Part 2/2 // V1.1 Matching support for visionOS, watchOS and tvOS /// A value that defines the visibility priority of a toolbar item after iOS 27/iPadOS27 and visionOS 27. /// The value is ignored on previous versions. /// /// When a toolbar runs out of space, it moves items into an overflow /// menu. Visibility priority controls the order in which that happens: /// items with a lower priority move first, keeping higher-priority /// items visible longer as the window shrinks. /// /// Use values of this type with the /// ``ToolbarContent/visibilityPriorityIfAvailable(_:)`` modifier. For example, /// to keep a share button visible longer than an archive button: /// /// struct RootView: View { /// var body: some View { /// ContentView() /// .toolbar { /// ToolbarItem { /// SecondaryControl() /// } /// ToolbarItem { /// PrimaryControl() /// } /// .visibilityPriorityIfAvailable(.high) /// } /// } /// } struct ToolbarItemVisibilityPriorityIfAvailable : Hashable, Sendable { fileprivate let level: VisibilityPriorityIfAvailable /// The default priority that lets the system determine the item's /// visibility in the toolbar. static let automatic = ToolbarItemVisibilityPriorityIfAvailable(.automatic) /// A priority that moves the item to the overflow menu before /// items with the default or high priority. /// /// Use for secondary actions, such as archive or delete, that /// don't need persistent visibility in the toolbar. /// > Warning : Prior to OS 27, it is ignored. @available(watchOS, unavailable) @available(tvOS, unavailable) @available(visionOS, unavailable) static let low = ToolbarItemVisibilityPriorityIfAvailable(.low) /// A priority that keeps the item in the toolbar longer than /// items with the default or low priority. /// /// Use for frequently used actions that need to stay visible as /// the toolbar shrinks. /// > Warning : Prior to OS 27, it is ignored. @available(watchOS, unavailable) @available(tvOS, unavailable) @available(visionOS, unavailable) static let high = ToolbarItemVisibilityPriorityIfAvailable(.high) /// Internal initializer. /// - Parameter level: <#level description#> private init(_ level: VisibilityPriorityIfAvailable) { self.level = level } /// Creates a priority lower than the specified value. /// /// The priority is lower than `other` but doesn't cross below /// the next lower system priority. For example, /// `ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high)` returns a value /// that is less than `.high` but greater than `.automatic`. /// /// Priorities created with the same base value are equal: /// /// let x = ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high) /// let y = ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high) /// x == y // true /// /// > Warning : calling this initializer with a value different from .low .automatic or .high returns the same /// other value. This is a limitation of this transitional code. @available(watchOS, unavailable) @available(tvOS, unavailable) @available(visionOS, unavailable) init(lowerThan other: ToolbarItemVisibilityPriorityIfAvailable) { switch other.level { case .low: self.level = .lowerThanLow case .automatic: self.level = .lowerThanAutomatic case .high: self.level = .lowerThanHigh default: // We don't manage other complex cases, we let them at the same level self.level = other.level } } /// Creates a priority higher than the specified value. /// /// The priority is higher than `other` but doesn't cross above /// the next higher system priority. For example, /// `ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high)` returns a /// value that is greater than `.high`. /// /// Priorities created with the same base value are equal: /// /// let x = ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high) /// let y = ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high) /// x == y // true /// /// > Warning : calling this initializer with a value different from .low .automatic or .high returns the same /// other value. This is a limitation of this transitional code. @available(watchOS, unavailable) @available(tvOS, unavailable) @available(visionOS, unavailable) init(higherThan other: ToolbarItemVisibilityPriorityIfAvailable) { switch other.level { case .low: self.level = .higherThanLow case .automatic: self.level = .higherThanAutomatic case .high: self.level = .higherThanHigh default: // We don't manage other complex cases, we let them at the same level self.level = other.level } } /// Returns a Boolean value indicating whether two values are equal. /// /// Equality is the inverse of inequality. For any values `a` and `b`, /// `a == b` implies that `a != b` is `false`. /// /// - Parameters: /// - lhs: A value to compare. /// - rhs: Another value to compare. public static func == (a: ToolbarItemVisibilityPriorityIfAvailable, b: ToolbarItemVisibilityPriorityIfAvailable) -> Bool { return a.level == b.level } } /// Enumeration of the managed level values for simpler code. fileprivate enum VisibilityPriorityIfAvailable: Int { case low = 100 case automatic = 200 case high = 300 case lowerThanLow = 99 case higherThanLow = 101 case lowerThanAutomatic = 199 case higherThanAutomatic = 201 case lowerThanHigh = 299 case higherThanHigh = 301 }
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Sep ’26
Reply to Simple solution for visibilityPriority for toolbar items.
Upgraded version that can be used with iOS 27 with the priorities while still working as before on older iOS. Support for visionOS, watchOS and tvOS is updated by removing features they don't have: .low, .high, lowerThan and higherThan. On those platforms, .automatic is the only supported level. Part 1/2 // // ToolbarContentExtension.swift // // Created by L'Appli en Rose, Paris on 23/09/2026. // No Rights Reserved, Free to use // SPDX-License-Identifier: CC0-1.0 // V1.1 Matching support for visionOS, watchOS and tvOS import SwiftUI extension ToolbarContent { /// Defines the visibility priority for a toolbar item after iOS 27 / iPadOS27 and visionOS 27. /// **Does nothing on previous versions.** /// /// When toolbar space is limited, items with a lower priority /// move into the overflow menu before items with a higher priority. /// The default is ``ToolbarItemVisibilityPriorityIfAvailable/automatic``. /// /// For example, an important control can appear at the trailing edge /// of the toolbar, but still be shown as the window is made smaller: /// /// struct RootView: View { /// var body: some View { /// ContentView() /// .toolbar { /// ToolbarItem { /// SecondaryControl() /// } /// ToolbarItem { /// PrimaryControl() /// } /// .visibilityPriorityIfAvailable(.high) /// } /// } /// } /// /// - Parameter priority: The visibility priority for this toolbar /// item. @MainActor @preconcurrency func visibilityPriorityIfAvailable(_ priority: ToolbarItemVisibilityPriorityIfAvailable) -> some ToolbarContent { if #available(iOS 27.0, macOS 26.1, watchOS 27.0, tvOS 27.0, visionOS 27.0, *) { let newLevel: ToolbarItemVisibilityPriority switch priority.level { #if os(iOS) || os(macOS) // levels only on iOS/iPadOS, Mac Catalyst and macOS case .low: newLevel = .low case .high: newLevel = .high case .lowerThanLow: newLevel = ToolbarItemVisibilityPriority(lowerThan: .low) case .lowerThanAutomatic: newLevel = ToolbarItemVisibilityPriority(lowerThan: .automatic) case .lowerThanHigh: newLevel = ToolbarItemVisibilityPriority(lowerThan: .high) case .higherThanLow: newLevel = ToolbarItemVisibilityPriority(higherThan: .low) case .higherThanAutomatic: newLevel = ToolbarItemVisibilityPriority(higherThan: .automatic) case .higherThanHigh: newLevel = ToolbarItemVisibilityPriority(higherThan: .high) #endif default: newLevel = .automatic } return self.visibilityPriority(newLevel) } else { // Prior to OS 27, no modifcation to the ToolbarContent return self } } }
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Sep ’26
Reply to Simple solution for visibilityPriority for toolbar items.
Part 2/2 /// A value that defines the visibility priority of a toolbar item after iOS 27/iPadOS27 and visionOS 27. /// The value is ignored on previous versions. /// /// When a toolbar runs out of space, it moves items into an overflow /// menu. Visibility priority controls the order in which that happens: /// items with a lower priority move first, keeping higher-priority /// items visible longer as the window shrinks. /// /// Use values of this type with the /// ``ToolbarContent/visibilityPriorityIfAvailable(_:)`` modifier. For example, /// to keep a share button visible longer than an archive button: /// /// struct RootView: View { /// var body: some View { /// ContentView() /// .toolbar { /// ToolbarItem { /// SecondaryControl() /// } /// ToolbarItem { /// PrimaryControl() /// } /// .visibilityPriorityIfAvailable(.high) /// } /// } /// } struct ToolbarItemVisibilityPriorityIfAvailable : Hashable, Sendable { fileprivate let level: VisibilityPriorityIfAvailable /// The default priority that lets the system determine the item's /// visibility in the toolbar. static let automatic = ToolbarItemVisibilityPriorityIfAvailable(.automatic) /// A priority that moves the item to the overflow menu before /// items with the default or high priority. /// /// Use for secondary actions, such as archive or delete, that /// don't need persistent visibility in the toolbar. /// > Warning : Prior to OS 27, it is ignored. static let low = ToolbarItemVisibilityPriorityIfAvailable(.low) /// A priority that keeps the item in the toolbar longer than /// items with the default or low priority. /// /// Use for frequently used actions that need to stay visible as /// the toolbar shrinks. /// > Warning : Prior to OS 27, it is ignored. static let high = ToolbarItemVisibilityPriorityIfAvailable(.high) /// Internal initializer. /// - Parameter level: <#level description#> private init(_ level: VisibilityPriorityIfAvailable) { self.level = level } /// Creates a priority lower than the specified value. /// /// The priority is lower than `other` but doesn't cross below /// the next lower system priority. For example, /// `ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high)` returns a value /// that is less than `.high` but greater than `.automatic`. /// /// Priorities created with the same base value are equal: /// /// let x = ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high) /// let y = ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high) /// x == y // true /// /// > Warning : calling this initializer with a value different from .low .automatic or .high returns the same /// other value. This is a limitation of this transitional code. init(lowerThan other: ToolbarItemVisibilityPriorityIfAvailable) { switch other.level { case .low: self.level = .lowerThanLow case .automatic: self.level = .lowerThanAutomatic case .high: self.level = .lowerThanHigh default: // We don't manage other complex cases, we let them at the same level self.level = other.level } } /// Creates a priority higher than the specified value. /// /// The priority is higher than `other` but doesn't cross above /// the next higher system priority. For example, /// `ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high)` returns a /// value that is greater than `.high`. /// /// Priorities created with the same base value are equal: /// /// let x = ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high) /// let y = ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high) /// x == y // true /// /// > Warning : calling this initializer with a value different from .low .automatic or .high returns the same /// other value. This is a limitation of this transitional code. init(higherThan other: ToolbarItemVisibilityPriorityIfAvailable) { switch other.level { case .low: self.level = .higherThanLow case .automatic: self.level = .higherThanAutomatic case .high: self.level = .higherThanHigh default: // We don't manage other complex cases, we let them at the same level self.level = other.level } } /// Returns a Boolean value indicating whether two values are equal. /// /// Equality is the inverse of inequality. For any values `a` and `b`, /// `a == b` implies that `a != b` is `false`. /// /// - Parameters: /// - lhs: A value to compare. /// - rhs: Another value to compare. public static func == (a: ToolbarItemVisibilityPriorityIfAvailable, b: ToolbarItemVisibilityPriorityIfAvailable) -> Bool { return a.level == b.level } } /// Enumeration of the managed level values for simpler code. fileprivate enum VisibilityPriorityIfAvailable: Int { case low = 100 case automatic = 200 case high = 300 case lowerThanLow = 99 case higherThanLow = 101 case lowerThanAutomatic = 199 case higherThanAutomatic = 201 case lowerThanHigh = 299 case higherThanHigh = 301 }
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Sep ’26
Reply to Simple solution for visibilityPriority for toolbar items.
I share the solution I use today that can be used with iOS 27 with the priorities while still working as before on older iOS. Part 1/2 // // ToolbarContentExtension.swift // // Created by L'Appli en Rose, Paris on 23/09/2026. // No Rights Reserved, Free to use // SPDX-License-Identifier: CC0-1.0 import SwiftUI extension ToolbarContent { /// Defines the visibility priority for a toolbar item after iOS 27 / iPadOS27 and visionOS 27. /// **Does nothing on previous versions.** /// /// When toolbar space is limited, items with a lower priority /// move into the overflow menu before items with a higher priority. /// The default is ``ToolbarItemVisibilityPriorityIfAvailable/automatic``. /// /// For example, an important control can appear at the trailing edge /// of the toolbar, but still be shown as the window is made smaller: /// /// struct RootView: View { /// var body: some View { /// ContentView() /// .toolbar { /// ToolbarItem { /// SecondaryControl() /// } /// ToolbarItem { /// PrimaryControl() /// } /// .visibilityPriorityIfAvailable(.high) /// } /// } /// } /// /// - Parameter priority: The visibility priority for this toolbar /// item. @MainActor @preconcurrency func visibilityPriorityIfAvailable(_ priority: ToolbarItemVisibilityPriorityIfAvailable) -> some ToolbarContent { if #available(iOS 27.0, macOS 26.1, watchOS 27.0, tvOS 27.0, visionOS 27.0, *) { let newLevel: ToolbarItemVisibilityPriority switch priority.level { case .low: newLevel = .low case .high: newLevel = .high case .lowerThanLow: newLevel = ToolbarItemVisibilityPriority(lowerThan: .low) case .lowerThanAutomatic: newLevel = ToolbarItemVisibilityPriority(lowerThan: .automatic) case .lowerThanHigh: newLevel = ToolbarItemVisibilityPriority(lowerThan: .high) case .higherThanLow: newLevel = ToolbarItemVisibilityPriority(higherThan: .low) case .higherThanAutomatic: newLevel = ToolbarItemVisibilityPriority(higherThan: .automatic) case .higherThanHigh: newLevel = ToolbarItemVisibilityPriority(higherThan: .high) default: newLevel = .automatic } return self.visibilityPriority(newLevel) } else { // Prior to OS 27, no modifcation to the ToolbarContent return self } } }
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Sep ’26
Reply to ToolbarItem(placement: .topBarPinnedTrailing) is not shown if it is the only toolbar element.
Thank you Albert. No I don't hide the toolbar with the "-" button, I just hide this button and the other button disappears too. Imagine an Undo button. You do something and the Undo button appears. You click it, and as there is nothing more to Undo, the button disappears. Another use case is a button which appears only in some cases, but you have another button which should always stay on screen. The issue only happens with the new .topBarPinnedTrailing modifier. You can try with the previous modifier and you will see that the first button stays on screen. // ToolbarItem(placement: .topBarPinnedTrailing) { ToolbarItem(placement: .topBarTrailing) { Feel free if you have any questions. Thank you.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Sep ’26
Reply to UserDefaults.standard.integer(forKey: ) crashes the app with EXC_BAD_ACCESS (code=1, address=0x0)
Yes you are right. We develop on the production Xcode (currently 26.5), but we test on every Beta OS (currently 27 OSes Beta 2) to be sure the user experience will be fine when they will update their OS. This also allows us to report feedbacks on new bugs on the future OS before it is out. And it has already been useful ;-) Unfortunately we often don't have time to also test the next Xcode, resources are limited in statups and clients await features in the apps. This issue is Xcode 26.5 can't run apps on iOS/iPadOS and visionOS Beta 2. Do you wan't me to close the feedback and open another one on Xcode?
Topic: App & System Services SubTopic: General Tags:
Jun ’26
Reply to UserDefaults.standard.integer(forKey: ) crashes the app with EXC_BAD_ACCESS (code=1, address=0x0)
Hello Quinn, I do not yet test Xcode 27, I' m still using Xcode Version 26.5 (17F42). Regarding the sysdiagnoses, the one made on Vision Pro was exactly the issue described with EXC_BAD_ACCESS. But as I said, without Xcode, launching directly on the devices works fine (I didn't notice at first). And now I have the crash you describe (instead of EXC_BAD_ACCESS) on iPhone and iPad with the 27 beta with the app launched from Xcode. Searching for the new error message, I found a web page describing "Fixing OS_dispatch_mach_msg _setContext: unrecognized selector on iOS 27 by Mick MacCallum" wich is the new error I see. He says In Xcode, open Product > Scheme > Edit Scheme. Select the Run action in the sidebar, then open the Options tab. Find Queue Debugging and uncheck Enable backtrace recording. This is what I did and now the project UserDefaults27 runs fine from Xcode. To recap, this is not an error with UserDefaults on the 27 OSes. The error is in fact that running apps from Xcode Version 26.5 (17F42) crashes the app on iOS, iPadOS and visionOS 27 including Beta 2 (and perhaps other 27 OSes). This could be very useful to know for other readers of this forum, as many could have the same issue. Please, tell me what you want me to do with the feedback. Should I open a new one on Xcode, can you change its category. Please let me know. Thank you very much.
Topic: App & System Services SubTopic: General Tags:
Jun ’26
Reply to UserDefaults.standard.integer(forKey: ) crashes the app with EXC_BAD_ACCESS (code=1, address=0x0)
Hello Quinn, Yes the project UserDefaults27 was created especially to reproduce the issue we have in our app, but a with a short sample we could send. That's why there are only print() instead of the real logic and the update of the values back to UserDefaults. The project crashed in our environment on visionOS, iOS and iPadOS 27 Beta 1 but not on an iPhone with iOS 26.5. Today I have another issue with iOS and iPadOS which stop in the Xcode debugger, but not when launching the app. I have sent Sysdiagnoses of these. I can still reproduce on visionOS and I have also sent a Sysdiagnose. Thank you very much, don't hesitate to ask if you need anything. PS: It's an honour for me to have you working on this issue. I use your precious advice on this forum on OS X and macOS since about 15 years (perhaps less I don't remember precisely the first time I've read you). Your work is very useful. Thank you.
Topic: App & System Services SubTopic: General Tags:
Jun ’26
Reply to Project xcodeproj file can no longer by iCloud Sync
Update : in fact all files which are packages can no longer be synched with iCloud Drive since the upgrade to macOS 26.2 : local package files are never sent to iCloud, and iCloud package files are never downloaded to the Mac drive. The xcodeproj files are packages files, but also realitycomposerpro, pages, number or bundle files are packages. A new Feedback was created as it is not only Xcode related: FB21663069
Jan ’26
Reply to Project xcodeproj file can no longer by iCloud Sync
We know how bug reporting is important for good software quality. We use Feedback Assistant each time we encounter an issue. Then, we also know we never get progress reports, but we had a majority of issues solved. It's worth it. Nothing changed in our infrastructure. The only changes were macOS 26.2 and Xcode 26.2. And has we had checked, and Apple Care rechecked, we have no other sync issues, just the .xcodeproj file, and now the new project .xcodeproj file. I have updated the FB to include the zip of the file with the issue to help your Xcode team. Thank you very much for you answers.
Dec ’25
Reply to Simple solution for visibilityPriority for toolbar items.
Version 1.1 Part 2/2 // V1.1 Matching support for visionOS, watchOS and tvOS /// A value that defines the visibility priority of a toolbar item after iOS 27/iPadOS27 and visionOS 27. /// The value is ignored on previous versions. /// /// When a toolbar runs out of space, it moves items into an overflow /// menu. Visibility priority controls the order in which that happens: /// items with a lower priority move first, keeping higher-priority /// items visible longer as the window shrinks. /// /// Use values of this type with the /// ``ToolbarContent/visibilityPriorityIfAvailable(_:)`` modifier. For example, /// to keep a share button visible longer than an archive button: /// /// struct RootView: View { /// var body: some View { /// ContentView() /// .toolbar { /// ToolbarItem { /// SecondaryControl() /// } /// ToolbarItem { /// PrimaryControl() /// } /// .visibilityPriorityIfAvailable(.high) /// } /// } /// } struct ToolbarItemVisibilityPriorityIfAvailable : Hashable, Sendable { fileprivate let level: VisibilityPriorityIfAvailable /// The default priority that lets the system determine the item's /// visibility in the toolbar. static let automatic = ToolbarItemVisibilityPriorityIfAvailable(.automatic) /// A priority that moves the item to the overflow menu before /// items with the default or high priority. /// /// Use for secondary actions, such as archive or delete, that /// don't need persistent visibility in the toolbar. /// > Warning : Prior to OS 27, it is ignored. @available(watchOS, unavailable) @available(tvOS, unavailable) @available(visionOS, unavailable) static let low = ToolbarItemVisibilityPriorityIfAvailable(.low) /// A priority that keeps the item in the toolbar longer than /// items with the default or low priority. /// /// Use for frequently used actions that need to stay visible as /// the toolbar shrinks. /// > Warning : Prior to OS 27, it is ignored. @available(watchOS, unavailable) @available(tvOS, unavailable) @available(visionOS, unavailable) static let high = ToolbarItemVisibilityPriorityIfAvailable(.high) /// Internal initializer. /// - Parameter level: <#level description#> private init(_ level: VisibilityPriorityIfAvailable) { self.level = level } /// Creates a priority lower than the specified value. /// /// The priority is lower than `other` but doesn't cross below /// the next lower system priority. For example, /// `ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high)` returns a value /// that is less than `.high` but greater than `.automatic`. /// /// Priorities created with the same base value are equal: /// /// let x = ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high) /// let y = ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high) /// x == y // true /// /// > Warning : calling this initializer with a value different from .low .automatic or .high returns the same /// other value. This is a limitation of this transitional code. @available(watchOS, unavailable) @available(tvOS, unavailable) @available(visionOS, unavailable) init(lowerThan other: ToolbarItemVisibilityPriorityIfAvailable) { switch other.level { case .low: self.level = .lowerThanLow case .automatic: self.level = .lowerThanAutomatic case .high: self.level = .lowerThanHigh default: // We don't manage other complex cases, we let them at the same level self.level = other.level } } /// Creates a priority higher than the specified value. /// /// The priority is higher than `other` but doesn't cross above /// the next higher system priority. For example, /// `ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high)` returns a /// value that is greater than `.high`. /// /// Priorities created with the same base value are equal: /// /// let x = ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high) /// let y = ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high) /// x == y // true /// /// > Warning : calling this initializer with a value different from .low .automatic or .high returns the same /// other value. This is a limitation of this transitional code. @available(watchOS, unavailable) @available(tvOS, unavailable) @available(visionOS, unavailable) init(higherThan other: ToolbarItemVisibilityPriorityIfAvailable) { switch other.level { case .low: self.level = .higherThanLow case .automatic: self.level = .higherThanAutomatic case .high: self.level = .higherThanHigh default: // We don't manage other complex cases, we let them at the same level self.level = other.level } } /// Returns a Boolean value indicating whether two values are equal. /// /// Equality is the inverse of inequality. For any values `a` and `b`, /// `a == b` implies that `a != b` is `false`. /// /// - Parameters: /// - lhs: A value to compare. /// - rhs: Another value to compare. public static func == (a: ToolbarItemVisibilityPriorityIfAvailable, b: ToolbarItemVisibilityPriorityIfAvailable) -> Bool { return a.level == b.level } } /// Enumeration of the managed level values for simpler code. fileprivate enum VisibilityPriorityIfAvailable: Int { case low = 100 case automatic = 200 case high = 300 case lowerThanLow = 99 case higherThanLow = 101 case lowerThanAutomatic = 199 case higherThanAutomatic = 201 case lowerThanHigh = 299 case higherThanHigh = 301 }
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Sep ’26
Reply to Simple solution for visibilityPriority for toolbar items.
Upgraded version that can be used with iOS 27 with the priorities while still working as before on older iOS. Support for visionOS, watchOS and tvOS is updated by removing features they don't have: .low, .high, lowerThan and higherThan. On those platforms, .automatic is the only supported level. Part 1/2 // // ToolbarContentExtension.swift // // Created by L'Appli en Rose, Paris on 23/09/2026. // No Rights Reserved, Free to use // SPDX-License-Identifier: CC0-1.0 // V1.1 Matching support for visionOS, watchOS and tvOS import SwiftUI extension ToolbarContent { /// Defines the visibility priority for a toolbar item after iOS 27 / iPadOS27 and visionOS 27. /// **Does nothing on previous versions.** /// /// When toolbar space is limited, items with a lower priority /// move into the overflow menu before items with a higher priority. /// The default is ``ToolbarItemVisibilityPriorityIfAvailable/automatic``. /// /// For example, an important control can appear at the trailing edge /// of the toolbar, but still be shown as the window is made smaller: /// /// struct RootView: View { /// var body: some View { /// ContentView() /// .toolbar { /// ToolbarItem { /// SecondaryControl() /// } /// ToolbarItem { /// PrimaryControl() /// } /// .visibilityPriorityIfAvailable(.high) /// } /// } /// } /// /// - Parameter priority: The visibility priority for this toolbar /// item. @MainActor @preconcurrency func visibilityPriorityIfAvailable(_ priority: ToolbarItemVisibilityPriorityIfAvailable) -> some ToolbarContent { if #available(iOS 27.0, macOS 26.1, watchOS 27.0, tvOS 27.0, visionOS 27.0, *) { let newLevel: ToolbarItemVisibilityPriority switch priority.level { #if os(iOS) || os(macOS) // levels only on iOS/iPadOS, Mac Catalyst and macOS case .low: newLevel = .low case .high: newLevel = .high case .lowerThanLow: newLevel = ToolbarItemVisibilityPriority(lowerThan: .low) case .lowerThanAutomatic: newLevel = ToolbarItemVisibilityPriority(lowerThan: .automatic) case .lowerThanHigh: newLevel = ToolbarItemVisibilityPriority(lowerThan: .high) case .higherThanLow: newLevel = ToolbarItemVisibilityPriority(higherThan: .low) case .higherThanAutomatic: newLevel = ToolbarItemVisibilityPriority(higherThan: .automatic) case .higherThanHigh: newLevel = ToolbarItemVisibilityPriority(higherThan: .high) #endif default: newLevel = .automatic } return self.visibilityPriority(newLevel) } else { // Prior to OS 27, no modifcation to the ToolbarContent return self } } }
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Sep ’26
Reply to Simple solution for visibilityPriority for toolbar items.
Part 2/2 /// A value that defines the visibility priority of a toolbar item after iOS 27/iPadOS27 and visionOS 27. /// The value is ignored on previous versions. /// /// When a toolbar runs out of space, it moves items into an overflow /// menu. Visibility priority controls the order in which that happens: /// items with a lower priority move first, keeping higher-priority /// items visible longer as the window shrinks. /// /// Use values of this type with the /// ``ToolbarContent/visibilityPriorityIfAvailable(_:)`` modifier. For example, /// to keep a share button visible longer than an archive button: /// /// struct RootView: View { /// var body: some View { /// ContentView() /// .toolbar { /// ToolbarItem { /// SecondaryControl() /// } /// ToolbarItem { /// PrimaryControl() /// } /// .visibilityPriorityIfAvailable(.high) /// } /// } /// } struct ToolbarItemVisibilityPriorityIfAvailable : Hashable, Sendable { fileprivate let level: VisibilityPriorityIfAvailable /// The default priority that lets the system determine the item's /// visibility in the toolbar. static let automatic = ToolbarItemVisibilityPriorityIfAvailable(.automatic) /// A priority that moves the item to the overflow menu before /// items with the default or high priority. /// /// Use for secondary actions, such as archive or delete, that /// don't need persistent visibility in the toolbar. /// > Warning : Prior to OS 27, it is ignored. static let low = ToolbarItemVisibilityPriorityIfAvailable(.low) /// A priority that keeps the item in the toolbar longer than /// items with the default or low priority. /// /// Use for frequently used actions that need to stay visible as /// the toolbar shrinks. /// > Warning : Prior to OS 27, it is ignored. static let high = ToolbarItemVisibilityPriorityIfAvailable(.high) /// Internal initializer. /// - Parameter level: <#level description#> private init(_ level: VisibilityPriorityIfAvailable) { self.level = level } /// Creates a priority lower than the specified value. /// /// The priority is lower than `other` but doesn't cross below /// the next lower system priority. For example, /// `ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high)` returns a value /// that is less than `.high` but greater than `.automatic`. /// /// Priorities created with the same base value are equal: /// /// let x = ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high) /// let y = ToolbarItemVisibilityPriorityIfAvailable(lowerThan: .high) /// x == y // true /// /// > Warning : calling this initializer with a value different from .low .automatic or .high returns the same /// other value. This is a limitation of this transitional code. init(lowerThan other: ToolbarItemVisibilityPriorityIfAvailable) { switch other.level { case .low: self.level = .lowerThanLow case .automatic: self.level = .lowerThanAutomatic case .high: self.level = .lowerThanHigh default: // We don't manage other complex cases, we let them at the same level self.level = other.level } } /// Creates a priority higher than the specified value. /// /// The priority is higher than `other` but doesn't cross above /// the next higher system priority. For example, /// `ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high)` returns a /// value that is greater than `.high`. /// /// Priorities created with the same base value are equal: /// /// let x = ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high) /// let y = ToolbarItemVisibilityPriorityIfAvailable(higherThan: .high) /// x == y // true /// /// > Warning : calling this initializer with a value different from .low .automatic or .high returns the same /// other value. This is a limitation of this transitional code. init(higherThan other: ToolbarItemVisibilityPriorityIfAvailable) { switch other.level { case .low: self.level = .higherThanLow case .automatic: self.level = .higherThanAutomatic case .high: self.level = .higherThanHigh default: // We don't manage other complex cases, we let them at the same level self.level = other.level } } /// Returns a Boolean value indicating whether two values are equal. /// /// Equality is the inverse of inequality. For any values `a` and `b`, /// `a == b` implies that `a != b` is `false`. /// /// - Parameters: /// - lhs: A value to compare. /// - rhs: Another value to compare. public static func == (a: ToolbarItemVisibilityPriorityIfAvailable, b: ToolbarItemVisibilityPriorityIfAvailable) -> Bool { return a.level == b.level } } /// Enumeration of the managed level values for simpler code. fileprivate enum VisibilityPriorityIfAvailable: Int { case low = 100 case automatic = 200 case high = 300 case lowerThanLow = 99 case higherThanLow = 101 case lowerThanAutomatic = 199 case higherThanAutomatic = 201 case lowerThanHigh = 299 case higherThanHigh = 301 }
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Sep ’26
Reply to Simple solution for visibilityPriority for toolbar items.
I share the solution I use today that can be used with iOS 27 with the priorities while still working as before on older iOS. Part 1/2 // // ToolbarContentExtension.swift // // Created by L'Appli en Rose, Paris on 23/09/2026. // No Rights Reserved, Free to use // SPDX-License-Identifier: CC0-1.0 import SwiftUI extension ToolbarContent { /// Defines the visibility priority for a toolbar item after iOS 27 / iPadOS27 and visionOS 27. /// **Does nothing on previous versions.** /// /// When toolbar space is limited, items with a lower priority /// move into the overflow menu before items with a higher priority. /// The default is ``ToolbarItemVisibilityPriorityIfAvailable/automatic``. /// /// For example, an important control can appear at the trailing edge /// of the toolbar, but still be shown as the window is made smaller: /// /// struct RootView: View { /// var body: some View { /// ContentView() /// .toolbar { /// ToolbarItem { /// SecondaryControl() /// } /// ToolbarItem { /// PrimaryControl() /// } /// .visibilityPriorityIfAvailable(.high) /// } /// } /// } /// /// - Parameter priority: The visibility priority for this toolbar /// item. @MainActor @preconcurrency func visibilityPriorityIfAvailable(_ priority: ToolbarItemVisibilityPriorityIfAvailable) -> some ToolbarContent { if #available(iOS 27.0, macOS 26.1, watchOS 27.0, tvOS 27.0, visionOS 27.0, *) { let newLevel: ToolbarItemVisibilityPriority switch priority.level { case .low: newLevel = .low case .high: newLevel = .high case .lowerThanLow: newLevel = ToolbarItemVisibilityPriority(lowerThan: .low) case .lowerThanAutomatic: newLevel = ToolbarItemVisibilityPriority(lowerThan: .automatic) case .lowerThanHigh: newLevel = ToolbarItemVisibilityPriority(lowerThan: .high) case .higherThanLow: newLevel = ToolbarItemVisibilityPriority(higherThan: .low) case .higherThanAutomatic: newLevel = ToolbarItemVisibilityPriority(higherThan: .automatic) case .higherThanHigh: newLevel = ToolbarItemVisibilityPriority(higherThan: .high) default: newLevel = .automatic } return self.visibilityPriority(newLevel) } else { // Prior to OS 27, no modifcation to the ToolbarContent return self } } }
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Sep ’26
Reply to ToolbarItem(placement: .topBarPinnedTrailing) is not shown if it is the only toolbar element.
Thank you Albert. No I don't hide the toolbar with the "-" button, I just hide this button and the other button disappears too. Imagine an Undo button. You do something and the Undo button appears. You click it, and as there is nothing more to Undo, the button disappears. Another use case is a button which appears only in some cases, but you have another button which should always stay on screen. The issue only happens with the new .topBarPinnedTrailing modifier. You can try with the previous modifier and you will see that the first button stays on screen. // ToolbarItem(placement: .topBarPinnedTrailing) { ToolbarItem(placement: .topBarTrailing) { Feel free if you have any questions. Thank you.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Sep ’26
Reply to UserDefaults.standard.integer(forKey: ) crashes the app with EXC_BAD_ACCESS (code=1, address=0x0)
Yes you are right. We develop on the production Xcode (currently 26.5), but we test on every Beta OS (currently 27 OSes Beta 2) to be sure the user experience will be fine when they will update their OS. This also allows us to report feedbacks on new bugs on the future OS before it is out. And it has already been useful ;-) Unfortunately we often don't have time to also test the next Xcode, resources are limited in statups and clients await features in the apps. This issue is Xcode 26.5 can't run apps on iOS/iPadOS and visionOS Beta 2. Do you wan't me to close the feedback and open another one on Xcode?
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
Jun ’26
Reply to UserDefaults.standard.integer(forKey: ) crashes the app with EXC_BAD_ACCESS (code=1, address=0x0)
Hello Quinn, I do not yet test Xcode 27, I' m still using Xcode Version 26.5 (17F42). Regarding the sysdiagnoses, the one made on Vision Pro was exactly the issue described with EXC_BAD_ACCESS. But as I said, without Xcode, launching directly on the devices works fine (I didn't notice at first). And now I have the crash you describe (instead of EXC_BAD_ACCESS) on iPhone and iPad with the 27 beta with the app launched from Xcode. Searching for the new error message, I found a web page describing "Fixing OS_dispatch_mach_msg _setContext: unrecognized selector on iOS 27 by Mick MacCallum" wich is the new error I see. He says In Xcode, open Product > Scheme > Edit Scheme. Select the Run action in the sidebar, then open the Options tab. Find Queue Debugging and uncheck Enable backtrace recording. This is what I did and now the project UserDefaults27 runs fine from Xcode. To recap, this is not an error with UserDefaults on the 27 OSes. The error is in fact that running apps from Xcode Version 26.5 (17F42) crashes the app on iOS, iPadOS and visionOS 27 including Beta 2 (and perhaps other 27 OSes). This could be very useful to know for other readers of this forum, as many could have the same issue. Please, tell me what you want me to do with the feedback. Should I open a new one on Xcode, can you change its category. Please let me know. Thank you very much.
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
Jun ’26
Reply to UserDefaults.standard.integer(forKey: ) crashes the app with EXC_BAD_ACCESS (code=1, address=0x0)
Hello Quinn, Yes the project UserDefaults27 was created especially to reproduce the issue we have in our app, but a with a short sample we could send. That's why there are only print() instead of the real logic and the update of the values back to UserDefaults. The project crashed in our environment on visionOS, iOS and iPadOS 27 Beta 1 but not on an iPhone with iOS 26.5. Today I have another issue with iOS and iPadOS which stop in the Xcode debugger, but not when launching the app. I have sent Sysdiagnoses of these. I can still reproduce on visionOS and I have also sent a Sysdiagnose. Thank you very much, don't hesitate to ask if you need anything. PS: It's an honour for me to have you working on this issue. I use your precious advice on this forum on OS X and macOS since about 15 years (perhaps less I don't remember precisely the first time I've read you). Your work is very useful. Thank you.
Topic: App & System Services SubTopic: General Tags:
Replies
Boosts
Views
Activity
Jun ’26
Reply to Project xcodeproj file can no longer by iCloud Sync
Update : in fact all files which are packages can no longer be synched with iCloud Drive since the upgrade to macOS 26.2 : local package files are never sent to iCloud, and iCloud package files are never downloaded to the Mac drive. The xcodeproj files are packages files, but also realitycomposerpro, pages, number or bundle files are packages. A new Feedback was created as it is not only Xcode related: FB21663069
Replies
Boosts
Views
Activity
Jan ’26
Reply to Project xcodeproj file can no longer by iCloud Sync
We know how bug reporting is important for good software quality. We use Feedback Assistant each time we encounter an issue. Then, we also know we never get progress reports, but we had a majority of issues solved. It's worth it. Nothing changed in our infrastructure. The only changes were macOS 26.2 and Xcode 26.2. And has we had checked, and Apple Care rechecked, we have no other sync issues, just the .xcodeproj file, and now the new project .xcodeproj file. I have updated the FB to include the zip of the file with the issue to help your Xcode team. Thank you very much for you answers.
Replies
Boosts
Views
Activity
Dec ’25