Hi using this new Text method for timers is not counting down. Here is an example of how I implemented it. Text(.now, format:.timer(countingDownIn: Date.now..<Date.now.addingTimeInterval(120), showsHours: true, maxFieldCount: 2, maxPrecision: .seconds(60)) ) After waiting over a minute it never counts down

Proposal: Add a System Readable Content Layout to SwiftUI SwiftUI currently does not provide a native equivalent of UIKit's UIView.readableContentGuide. For content-heavy applications such as articles, documentation, settings, email, and media descriptions, developers often need to prevent text from becoming excessively wide on iPad, Mac, and other large displays. UIKit already provides a system-level solution through: view.readableContentGuide However, there is currently no equivalent API in SwiftUI. Current Workarounds Developers currently have to choose between several approaches, none of which provides the same behavior as UIKit's readableContentGuide. 1. Hard-coded maximum width content .frame(maxWidth: 700) This is simple, but the value is arbitrary and does not adapt to the platform, window size, Dynamic Type, or system layout rules. 2. containerRelativeFrame A developer can approximate a readable width: content .containerRelativeFrame(.horizontal) { length, axis in length * 0.52 } However, this is only an approximation. Developers still have to determine the appropriate ratio themselves, and the result does not necessarily match the system's readable content width. 3. Bridging to UIKit Another workaround is to create a UIKit view/controller and obtain: view.readableContentGuide.layoutFrame The resulting width can then be passed back into SwiftUI. This works for iOS and iPadOS, but introduces UIKit-specific implementation details into an otherwise pure SwiftUI view and does not provide a natural cross-platform solution for macOS, tvOS, and other SwiftUI platforms. Proposed API I propose that SwiftUI provide a system-defined readable content layout. For example: .contentWidth(.readable) or a dedicated layout/container: ReadableContent { content } Another possibility would be a layout guide exposed through the SwiftUI environment: @Environment(\.readableContentGuide) private var readableContentGuide allowing: content .frame( maxWidth: readableContentGuide.width ) The exact API design is of course up to Apple, but the important part is that the readable width should be determined by the system rather than by application-specific constants. Expected Behavior The readable content width should be determined by the current platform and environment, taking into account factors such as: Available window/container size Platform-specific layout conventions Dynamic Type / accessibility text sizes Layout margins Safe areas Orientation Size classes where applicable Current window size on macOS Appropriate platform-specific readable widths For example, the same SwiftUI view could behave naturally across devices: iPhone ┌─────────────────────────┐ │ │ │ Readable content │ │ │ └─────────────────────────┘ iPad ┌─────────────────────────────────────────────┐ │ │ │ ┌───────────────────────┐ │ │ │ Readable content │ │ │ └───────────────────────┘ │ │ │ └─────────────────────────────────────────────┘ Mac ┌──────────────────────────────────────────────────────────────┐ │ │ │ ┌───────────────────────┐ │ │ │ Readable content │ │ │ └───────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘ The developer should not need to know the exact width used by the system. Why This Belongs in SwiftUI SwiftUI already provides many environment-driven layout behaviors that automatically adapt to the current platform and device. Readable content width is similarly a semantic layout concept, rather than a fixed visual dimension. For example, developers generally should not need to write: #if os(iOS) let maxWidth = 700 #elseif os(macOS) let maxWidth = 800 #elseif os(tvOS) let maxWidth = 1000 #endif A system-provided readable layout would allow the application to express its intent instead: ReadableContent { ArticleView() } This would also make SwiftUI applications more resilient to future platform changes because Apple could adjust the underlying readable-content rules without requiring developers to update hard-coded constants. Use Cases This would be particularly useful for: Article and reading applications Documentation viewers News applications Email clients Settings and preference screens Legal/privacy documents Markdown viewers AI/chat applications Book and EPUB readers Media descriptions and metadata Forms containing large amounts of text Relationship to UIKit UIKit already establishes a precedent with: UIView.readableContentGuide SwiftUI developers should have access to the same semantic concept without needing to bridge through UIKit. The SwiftUI API does not necessarily need to expose the UIKit implementation. It could instead provide a platform-independent abstraction whose implementation is appropriate for each SwiftUI platform. Summary I would like to request a native SwiftUI API for system-defined readable content width. The ideal solution would allow developers to express: ReadableContent { ArticleView() } or: ArticleView() .contentWidth(.readable) while SwiftUI automatically determines the appropriate readable width for the current platform, window, Dynamic Type settings, and layout environment. This would eliminate the need for hard-coded maximum widths and platform-specific UIKit/AppKit workarounds, while bringing SwiftUI closer to the adaptive layout behavior already available in UIKit through readableContentGuide.

On the iPhone Duo the standard "Edit" button for navigation bars is a text-based button, and text-based buttons are not pushed to the vertical toolbars on the Duo. This looks sometimes silly, if it is the only remaining button that can not be placed in the vertical toolbar and which has the result that an almost empty horizontal navigation bar must be kept visible as well. So I guess it would be good idea to have an icon-based replacement for the Editor button to avoid having two toolbars on the Duo. Is there a best practice for the icon to pick for such an edit button? Would be "square.and.pencil" (SF Symbols) a good choice? Or better the "pencil .circle", because the "square" one is often used for text-based input? Anything better?

FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.

As of iOS 27, DragGesture(minimumDistance: 0) no longer functions as a reliable touch detector, at least without a noticeable delay before the gesture is recognized. This is very frustrating, as this was one of the few decent ways to detect touch down (and up) events in more complicated gesture handling scenarios. Some level of delay for gesture disambiguation is of course expected in certain cases, but this is reproducible even when the drag gesture is the sole gesture in the view hierarchy. Further, this was never a problem on iOS 26 and below. To see the issue, run an app containing the following view and tap the green rectangle rapidly. On iOS 27, the opacity won't change at all, while on iOS 26 and below it will flash rapidly as expected. To make matters much worse, the latency goes from slight but noticeable to ridiculous if the view is placed anywhere in the bottom 1/5 or so of the screen. System gestures seem to be interfering. Again, this was not an issue before iOS 27. struct PressDetectView: View { @GestureState private var isPressed = false var body: some View { Rectangle() .fill(.green) .opacity(isPressed ? 0.5 : 1) .gesture(dragGesture) } private var dragGesture: some Gesture { DragGesture(minimumDistance: 0) .updating($isPressed) { value, state, _ in state = true print("drag") } } } Any workarounds?

Hello everyone 👋 I’m an engineer and self-taught iOS developer. I recently published my app, Nexora AI, on the App Store. The app is designed to help students study smarter using AI-driven features like PDF analysis, instant problem solving, flashcard generation, and study/exam planning. As a solo developer, I’d love to gather feedback on UX/UI flow, performance, and general user experience from the community. If you have a moment to test it out or share any thoughts, I’d greatly appreciate it! 📲 App Store Link: https://apps.apple.com/tr/app/nexora-ai/id6770621015 Thanks for your time and feedback!

Calling contactAccessPicker results in a blank sheet and a jetsam error, rather than the expected contact picker, using Apple’s sample code, only on device with iOS 26.2.1. This is happening on a iPhone 17 Pro Max running 26.2.1, and not on a simulator. I’m running Apple's sample project Accessing a person’s contact data using Contacts and ContactsUI Steps: Run the sample app on device running iOS 26.2.1. Use the flow to authorize .limited access with 1 contact: Tap request access, Continue, Select Contacts. Select a contact, Continue, Allow Selected Contact. This all works as expected. Tap the add contact button in the toolbar to add a second contact. Expected: This should show the Contact Access Picker UI. Actual: Sheet is shown with no contents. See screenshot of actual results on iOS device running 26.2.1. Reported as FB21812568 I see a similar (same?) error reported for 26.1. It seems strange that the feature is completely broken for multiple point releases. Is anyone else seeing this or are the two of us running into the same rare edge case? Expected Outcome, seen on simulator running 26.2 Actual outcome, seen on device running 26.2.1

I’m experiencing a UI flickering issue in a SwiftUI application related to navigation and the .searchable modifier. I have the following navigation flow: Case 1: Event Dashboard ↓ Attendee List ↓ Back to Event Dashboard The Event Dashboard contains an event image at the top. The Attendee List has a navigation bar with a .searchable search field. When I navigate back from the Attendee List to the Event Dashboard, the event image briefly becomes smaller and then returns to its original size after approximately one second. Case 2: Event Dashboard ↓ Attendee List ↓ Attendee Detail The Attendee List contains .searchable, while the Attendee Detail screen does not. When navigating from the Attendee List to the Attendee Detail screen, the attendee profile image similarly becomes slightly smaller and then enlarges back to its original size. The behavior appears to be related to the navigation bar/search bar layout changing between screens. For example, the Attendee List currently uses: .searchable( text: $model.searchQuery, placement: .navigationBarDrawer, prompt: "Search" ) If I completely remove .searchable from the Attendee List, the flickering does not occur. I would like to understand whether this is expected SwiftUI behavior or a known issue with .searchable and navigation transitions. I am considering testing the Attendee List with ScrollView + LazyVStack instead of List to determine whether List is contributing to the issue.

Hi there, I am working on bluetooth functionality of iOS and I have a feature that display all bluetooth paired devices on list view. Is there a way to get the list of paired device using swift programming. Many Thanks!

Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.

Project structure is: App target + widget extension + widget intent extension All share a common appgroup group.com.x.y and all file handling is done using FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.x.y") so that only the shared container is used. Using the Main app target, a font "Chewy-Regular.ttf" is downloaded and saved to the shared AppGroup container. Font can now be loaded via CTFontManagerRegisterFontsForURL and displayed in a Main App Text view Text("Testing...").font(Font.custom("Chewy-Regular", size: 20)) Now add a Widgetkit widget instance that uses this font. In 'getTimeLine() and getSnapShot() of IntentTimelineProvider we load the font again via CTFontManagerRegisterFontsForURL (this needs to happen again probably because widget runs in a separate process from the main app?). On simulator, the widget will show the correct font. BUT On iPhone7 real device, the widget will show the 'redacted placeholder view'. It seems that something is crashing. I see in the device console : error 14:39:07.567120-0800 chronod No configuration found for configured widget identifier: D9BF75EE-4A04-441A-8C85-1507F7ECE379 fault 14:39:07.625600-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.672733-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; error 14:39:07.672799-0800 chronod [co.appevolve.onewidget.widgetx:widgetx:small:1536744920620481560@148.0/148.0/20.2] reload: could not decode view error 14:39:07.674984-0800 kernel Sandbox: chronod(2128) deny(1) file-read-metadata /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.675762-0800 kernel Sandbox: chronod(2128) deny(1) file-read-data /private/var/mobile/Containers/Shared/AppGroup/9B524570-1765-4C24-9E0C-15BC3982F0DC/downloadedFonts/Chewy/Chewy-Regular.ttf error 14:39:07.708914-0800 chronod [u 8D2C83B3-A6CB-432E-A9D4-9BC8F7056B10:m (null)] [&amp;lt;private&amp;gt;(&amp;lt;private&amp;gt;)] Connection to plugin invalidated while in use. fault 14:39:07.710284-0800 widgetxExtension -[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times. error 14:39:07.803468-0800 chronod Encountered an error reading the view archive for &amp;lt;private&amp;gt;; error: &amp;lt;private&amp;gt; It seems that it's a permission issue, and the textview can't access the font file it needs when the widget is rendering. Notes: 1) Font is definitely registered because I can see them in for fontFamily in UIFont.familyNames {             for fontName in UIFont.fontNames(forFamilyName: fontFamily) {                 print(fontName) &amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;&amp;amp;#9;... in both the Main App target and the Widget Extension target 2) If I make make the font part of the app bundle and add to 'Fonts provided by application' , the are loaded absolutely fine in the Main App and the Widget on simulator and iPhone 7 real device. 3) I do see this error sometimes in the Widget extension target log, don't know if it's related. widgetxExtension[1385:254599] [User Defaults] Couldn't read values in CFPrefsPlistSource&amp;lt;0x28375b880&amp;gt; (Domain: group.co.appevolve.onewidget, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd 4) I suspected something to do with app groups, so I tried to copy the font into the Widget Extension container and load from there, but had the same result. Please help! Thank you.

Example of code: @State private var state1 = "hello" @State private var state2 = "world" @State private var state3 = 0 @State private var state4 = false Or using store @Observable class Store { var state1 = "hello" var state2 = "world" var state3 = 0 var state4 = false } // and @State var store = Store() Some things I found myself, is that using Store I can use didSet, willSet to update other vars when one changes. But if that is not needed - is there an advantage of one

Has anyone else observed an app entering the background when the user simply opens Notification Center on iOS 27? In our app, fully pulling down Notification Center triggers both UIScene.didEnterBackgroundNotification and UIApplication.didEnterBackgroundNotification. The user has not pressed the side button, gone to the Home Screen, or switched to another app. In the iOS 26 environments we checked, opening Notification Center only made the app inactive. User-visible impact and recording Our app currently treats background entry during an active medication reminder as leaving that reminder session: it closes the reminder screen and schedules a follow-up. As a result, merely checking Notification Center now triggers that existing behavior. Screen recording: https://drive.google.com/file/d/1KmXEKwg1vJpCWqe56IrC_iHaEC2aH_fc/view?usp=sharing The recording shows Notification Center being opened from the reminder screen, including a return to the app's main screen instead of the reminder screen. It also includes opening and dismissing Control Center, as well as going to the Home Screen and returning to the app. These are separate interactions, not one continuous Notification Center interaction. The video illustrates the visible impact; the lifecycle evidence below comes from separate logging. Environment and observations Physical device with the issue: iPhone 14 Pro, iOS 27.0 release build 24A435. We also observed it on an iOS 27 developer beta. Devices without the issue: iPhone 11 Pro running iOS 26.5.2 and iPhone 16 Pro running iOS 26.6. Opening Notification Center did not trigger background entry on either device. These comparisons involve different devices; we have not isolated the OS version as the only variable. App lifecycle: SwiftUI App + WindowGroup + @UIApplicationDelegateAdaptor. Multiple-scene support is disabled. The app uses AlarmKit for medication reminders. Verified build environments (simulator reproduction) Reproduction build Xcode iOS SDK Our app 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 26.4.1 (17E202) 26.4 Minimal standalone lifecycle apps 27.0 RC (27A266a) 27.0 All three groups reproduced background entry when fully opening Notification Center on the iOS 27.0 simulator (24A434). The same SDK 26.4-built minimal apps remained inactive, without entering the background, on the iOS 26.4.1 simulator (23E254a). The behavior therefore also reproduces with apps built against the older SDK, not only with the iOS 27 SDK. Steps to reproduce in our app Open the app and leave it in the foreground. Swipe down from the top-left edge to fully open Notification Center. Do not tap a notification, lock the device, or switch apps. Observe the lifecycle notifications, then dismiss Notification Center to return to the app. On the affected iOS 27 device, the behavior differs between these actions: Action Observed behavior Fully open Notification Center App becomes inactive, then enters the background Open Control Center App becomes inactive, without background entry Enter the app switcher without selecting another app or going Home App becomes inactive, without background entry Go to the Home Screen App enters the background, as expected Lifecycle evidence This is a representative trace from earlier instrumented runs, separate from the screen recording above. Times are relative to the first event: +0.000s scene.willDeactivate +0.002s app.willResignActive +0.778s scene.didEnterBackground +0.780s app.didEnterBackground In subsequent instrumented runs on the iOS 27 release build, we also observed UIScene.activationState == .background after opening Notification Center. Our application's background handler is connected to the UIKit notification, rather than an onChange handler for SwiftUI's scenePhase: .onReceive( NotificationCenter.default.publisher( for: UIApplication.didEnterBackgroundNotification ) ) { _ in delegate.handleBackgroundEntry() } Separately, a diagnostic observer uses NotificationCenter.default.addObserver to record the UIKit application and scene notifications. The background events are therefore not inferred solely from our own session state or from the reminder screen disappearing. Questions Has anyone reproduced this on iOS 27? Reports of either reproduction or non-reproduction, including device model and OS build, would be helpful. Is background entry when fully opening Notification Center expected on iOS 27, or could this be a regression or an interaction with our app configuration? Is there a supported API or documented lifecycle distinction between opening Notification Center and actually leaving the app for the Home Screen or another app? Our standalone simulator comparisons reproduced the behavior with both SwiftUI and UIKit scene-based app lifecycles, including direct sceneDidEnterBackground callbacks. For context, this earlier Apple staff response describes Notification Center as making an app foreground-inactive. I also found this iOS 27 AVPlayer report about playback stopping after Notification Center is fully opened, but I do not know whether it has the same underlying cause. Any clarification from Apple or observations from other developers would be appreciated.

Hi, in RealityKit, AudioPlaybackController exposes duration, gain, speed, play/pause/stop, and a completion handler, but I can't find a way to read the current playhead position while a resource is playing. I need this to trigger animations and other timed events in sync with the audio. Is there a supported way to read the current playback position on AudioPlaybackController? If not, is this planned any time soon? Also, is there a sample-accurate way to start/keep audio playback in sync across multiple entities in RealityKit? Appreciate any guidance, thanks.

On macOS 27.0 (26A428) with Xcode 27.0, Apple's unmodified sample Building a document-based app with SwiftUI stops responding permanently when another process replaces an open document's file through NSFileCoordinator. AppKit reverts the document on the main thread, which then blocks in a semaphore wait inside SwiftUI: -[NSDocument relinquishPresentedItemToWriter:]_block_invoke_8 (in AppKit) -[NSDocument _revertToVersion:preservingFirst:error:] (in AppKit) -[NSDocument revertToContentsOfURL:ofType:error:] (in AppKit) URLPlatformDocument.read(from:ofType:) (in SwiftUI) _dispatch_semaphore_wait_slow (in libdispatch.dylib) No other thread is reading the document. In another app using Document, its DocumentReader was never called, and a document with unsaved changes hung the same way in URLPlatformDocument.write(to:ofType:for:originalContentsURL:). Reproduction (the sample plus a short script): https://github.com/DePasqualeOrg/swiftui-document-revert-hang Feedback report: FB24792850

When I drag and drop a file with flag "shouldAttemptToOpenInPlace: true", I was able to access the original file name in macOS 15. After upgrading to macOS 26, I can't access the original file name anymore. Instead, I got some useless file name such as ".com.apple.Foundation.NSItemProvider.gKZ91u.tmp". The app no longer works with these tmp filenames because it needs the orignal file name to do the file transfer. (Btw, this is a WinSCP like app on Mac platform) Could you please check and fix this issue? Thank you. FileRepresentation(contentType: .item, shouldAttemptToOpenInPlace: true)

As a 3D artist specializing in spatial installations, I faced the constant risk of designs looking balanced on screen but failing in physical proportions on the production floor. Starting with no traditional coding background, I embraced AI-assisted development and the CORE learning framework to master Swift, ARKit, and RealityKit. Real ini was built out of real practitioner necessity: turning the iPhone and iPad into on-site spatial validation studios that bridge digital art into physical reality. Download my app for free : https://apps.apple.com/id/app/real-ini/id6805716872

I’d like Swift Charts to support pinch-to-zoom, with the data beneath the pinch staying in place and smooth integration with scrolling and selection. This is useful whenever someone wants to explore a chart: zoom into a heart-rate spike, inspect a price change, or investigate a burst of energy consumption without losing their place. Apple Health uses preset time ranges to change the level of detail. Those are useful shortcuts, but they don’t always match the interval someone wants to explore. Pinching would complement them by letting users zoom directly into whatever catches their attention—a familiar interaction from maps and photos that feels natural for charts too. I’ve implemented a workaround using MagnifyGesture, chartXVisibleDomain, and chartScrollPosition. It mostly works, but keeping the pinch anchored requires continuously adjusting the scroll position, which causes chart jumps and visual glitches—even with animations disabled. Native support should handle that coordination, let developers configure zoom limits, and work alongside existing chart gestures. Developers could then offer smooth, interactive charts without each having to solve the same gesture and anchoring problems. I’ve attached a sample project demonstrating the workaround and its limitations. Would native pinch-to-zoom help your app too? I’d be interested in your use cases and any limitations you’ve encountered. I’ve filed this as FB24785962; if you submit related feedback, please reference it and describe your own use case. Sample Project

Hi! I've encountered strange bug in iOS 26. The MultiDatePicker component exhibits unreliable behavior when attempting to deselect previously chosen dates. Users often need to tap a selected date multiple times (e.g., tap to deselect, tap to re-select, then tap again to deselect) for the UI to correctly register the deselection and update the displayed state. This issue does not occur on iOS 18 or Xcode 26 previews, where MultiDatePicker functions as expected, allowing single-tap deselection. The bug only occurs on physical device or simulator. I can't lie, I have multidatepicker as crucial component in my larger app and can't really find a solution to this. Has anyone encountered this problem before? Here is the code to replicate the issue: import SwiftUI struct ContentView: View {     @ State private var selectedDates: Set = []     var body: some View {         NavigationStack {             Form {                 Section {                     MultiDatePicker("Select Dates", selection: $selectedDates)                 } header: {                     Text("MultiDatePicker Bug Test")                 }                 Section {                     Text("Selected Dates Count: (selectedDates.count)")                     ForEach(Array(selectedDates).sorted(by: {                         Calendar.current.date(from: $0)! < Calendar.current.date(from: $1)!                     }), id: .self) { dateComponent in                         if let date = Calendar.current.date(from: dateComponent) {                             Text(date.formatted(date: .long, time: .omitted))                         }                     }                 } header: {                     Text("Current State of Selected Dates")                 }             }             .navigationTitle("Date Picker Bug")         }     } } #Preview {     ContentView() }

It has been two years since I wrote my a SwiftUI app, and I wanted to start again in Xcode 26. I can no longer see the attributes inspector when I select an element in the canvas. This was an Xcode feature that was very helpful as I am still a novice. Has this feature been deprecated in Xcode 26? And if not, please help explain how I can find and use it.