Basic Information Please provide a descriptive title for your feedback: Sheet presentationDetents breaks after rapid open/dismiss cycles Which platform is most relevant for your report? iOS Description Steps to Reproduce: Create a sheet with presentationDetents([.medium]) Rapidly perform these actions multiple times (usually 3-4 times): a. Open the sheet b. Immediately scroll down to dismiss Open the sheet again Observe that the sheet now appears at .large size, ignoring the .medium detent Expected Result: Sheet should consistently maintain .medium size regardless of how quickly it is opened and dismissed. Actual Result: After rapid open/dismiss cycles, the sheet ignores .medium detent and appears at .large size. Reproduction Rate: Occurs consistently after 3-4 rapid open/dismiss cycles More likely to occur with faster open/dismiss actions Configuration: iOS 18 Xcode 16.0 (16A242d) SwiftUI Device: iPhone 14

I would like to understand how to programmatically set the position of a cursor in a SwiftUI TextField. In UIKit this can be done using the selectedTextRange property, but I couldn't find a similar way to achieve this with pure SwiftUI. I want to figure out something like setCursorPosition (index:) - maybe by tracking the position in a @State or any other way. I understand that I can do this using UIViewRepresentable but I am looking for a pure SwiftUI solution and wanted to know if there is any.

I'm trying to accomplish the features in this video where the child device requests permission from parent to control scren time. Then the parent can choose apps on the childs phone from their phone. Everything on the childs device is working exactly like in the video. However, on the parents phone, when the FamilyActivityPicker appears, it's only the apps on the parents phone and when an app is selected, nothing changes in the FamilyActivitySelection. I found this forum post describe the same issue I am having. I have a physical device logged in the child and a simulator running as the parent. Why can't I see the child's apps on the parents phone? Is it cause I'm running one of them on a simulator?

I'm trying to make a timetable app for my Apple Watch, and it has all actually been going pretty smoothly until this random error started showing up when I try to build my application. Here's a code snippet: // all on top level: class globalStorage { static let shared = globalStorage() // line 27 @State @AppStorage(runningKey) var termRunningGB = false @State @AppStorage(ghostWeekKey) var ghostWeekGB = false @State @AppStorage(startDateKey) var startDateGB = Date.now var currentCourse: Course = getCurrentClass(date: .now) } let storage = globalStorage.shared // << ERRORING HERE (line // ... @main struct myApp: App { /* ... */ } Can anybody tell me what is happening? (And, of course, how to fix it?) Furthermore, upon removing the offending line (let storage = globalStorage.shared) (and replacing all callers of said variable with 'globalStorage.shared' to bypass the variable) the error has decided to settle on line 27, where i define the 'shared' thing in the class. [ I just went back to try more solutions, I have resolved it but forgot to give my solution here. Now I've forgotten how I fixed it. I do know that I moved currentCourse out of the class, that most likely was it I think.] All of this code is on GitHub: https://github.com/the-trumpeter/Timetaber-for-iWatch

My assumption has always been that [NSApp runModalForWindow:] runs a modal window in NSModalPanelRunLoopMode. However, while -[NSApplication _doModalLoop:peek:] seems to use NSModalPanelRunLoopMode when pulling out the next event to process via nextEventMatchingMask:untilDate:inMode:dequeue:, the current runloop doesn't seem to be running in that mode, so during -[NSApplication(NSEventRouting) sendEvent:] of the modal-specific event, NSRunLoop.currentRunLoop.currentMode returns kCFRunLoopDefaultMode. From what I can tell, this means that any event processing code that e.g. uses [NSTimer addTimer:forMode:] based on the current mode will register a timer that will not fire until the modal session ends. Is this a bug? Or if not, is the correct way to run a modal session something like this? [NSRunLoop.currentRunLoop performInModes:@[NSModalPanelRunLoopMode] block:^{ [NSApp runModalForWindow:window]; }]; [NSRunLoop.currentRunLoop limitDateForMode:NSModalPanelRunLoopMode]; Alternatively, if the mode of the runloop should stay the same, I've seen suggestions to run modal sessions like this: NSModalSession session = [NSApp beginModalSessionForWindow:theWindow]; for (;;) { if ([NSApp runModalSession:session] != NSModalResponseContinue) break; [NSRunLoop.currentRunLoop limitDateForMode:NSModalPanelRunLoopMode]; } [NSApp endModalSession:session]; Which would work around the fact that the timer/callbacks were scheduled in the "wrong" mode. But running NSModalPanelRunLoopMode during a modal session seems a bit scary. Won't that potentially break the modality?

What particular configuration will allow a document based app (DocumentGroup) to open the application into the selected document when the document is touched in Files.app. The sample code doesn't show this behaviour and instead will open the app but will not open the selected document. This also is the behaviour with the Xcode document based app template. Using LSSupportsOpeningDocumentsInPlace = YES in the plist does not make any difference. .onOpenURL is not a modifier on Scene only View and if the app is opened from cold the document view will not exist. In any case I would expect the DocumentGroup to open the document directly with no further intervention. What additional magic do I need to get a document to open directly from Files.app (or Messages) . For example Swift Playgrounds shows the correct behaviour, opening the selected project directly.

Hello everyone, The setup: I have an iPadOS app. The app does not require full screen (Requires full screen option is disabled). The problem: The app starts looking unpolished when the canvas becomes too small. What I tried: I am trying to limit the canvas size for our app when run in Stage Manager. How: I saw that UIWindowScene has sizeRestrictions. This property is not always set as per documentation: https://developer.apple.com/documentation/uikit/uiwindowscene/sizerestrictions From my experiments, it only works when it's run on MacOS (in compatibility mode in our case). Console logs: Stage Manager - Requires full screen - OFF willConnectToSession - sizeRestrictions: nil sceneDidBecomeActive - sizeRestrictions: nil Stage Manager - Requires full screen - ON willConnectToSession - sizeRestrictions: nil sceneDidBecomeActive - sizeRestrictions: nil Stage Manager - Requires full screen - OFF - RUN on MacOS willConnectToSession - sizeRestrictions: Available sceneDidBecomeActive - sizeRestrictions: Available Question: Is there a way to enforce this minimum canvas size?

Since tvOS 18, my Picker view with inline style is not showing the checkmark on the selected item. enum Flavor: String, Identifiable { case chocolate, vanilla, strawberry var id: Self { self } } struct ContentView: View { @State private var selectedFlavor: Flavor = .chocolate var body: some View { NavigationView { Form { Picker("Flavor", selection: $selectedFlavor) { Text("Chocolate").tag(Flavor.chocolate) Text("Vanilla").tag(Flavor.vanilla) Text("Strawberry").tag(Flavor.strawberry) }.pickerStyle(.inline) } } } } Am I missing something? When I run this on tvOS 17.x, it works fine.

I was determined to fully rely on SwiftUI's navigation system giving the fact I'm starting a new project - strongly reconsidering this after a very basic requirement. Namely: navigate between my two screens while wanting to hide the back button label. One of them has a large navigation title The other one has no navigation title The problem is that back button icon simply jumps from top, a little bit down (where the title is supposed to be) and then back to top while navigating - resulting in a rough bouncy animation. struct ParentView: View { var body: some View { NavigationStack { WelcomeView() .navigationDestination(for: WelcomeRoute.self) { route in destinationView(for: route) } } } ... } struct WelcomeView: View { var body: some View { ScrollView { VStack { ... NavigationLink(value: WelcomeRoute.Routes.next) { Text("Next screen") } } } .navigationTitle("WELCOME") .navigationBarTitleDisplayMode(.large) } } struct NextWelcomeView: View { var body: some View { ScrollView { VStack { .... Text("Hello") } } .toolbarRole(.editor) } }

Problem Setting ".environment(.layoutDirection, .rightToLeft)" to a view programmatically won't make buttons in menu to show right to left. However, setting ".environment(.locale, .init(identifier: "he-IL"))" to a view programmatically makes buttons in menu to show Hebrew strings correctly. Development environment: Xcode 16.x, macOS 15.3.1 Target iOS: iOS 17 - iOS 18 The expected result is that the button in the menu should be displayed as an icon then a text from left to right. Code to demonstrate the problem: struct ContentView: View { var body: some View { VStack(alignment: .leading) { Text("Buttons in menu don't respect the environment value of .layoutDirection") .font(.subheadline) .padding(.bottom, 48) /// This button respects both "he-IL" of ".locale" and ".rightToLeft" of ".layoutDirection". Button { print("Button tapped") } label: { HStack { Text("Send") Image(systemName: "paperplane") } } Menu { /// This button respects "he-IL" of ".locale" but doesn't respect ".rightToLeft" of ".layoutDirection". Button { print("Button tapped") } label: { HStack { Text("Send") Image(systemName: "paperplane") } } } label: { Text("Menu") } } .padding() .environment(\.locale, .init(identifier: "he-IL")) .environment(\.layoutDirection, .rightToLeft) } }

When the following structure: NavigationStack { ScrollView { NavigationLink(...) } } is presented inside a sheet in SwiftUI, the scroll drag gesture and the link tap gesture collide. If the user happens to begin a scroll gesture on a link, the link will open the moment the finger is lifted, no matter how far it is from its initial touchdown. The issue has already been found (this stack overflow post from 2019), but no solution was provided. I've already filed a report (FB17034020). In the meantime, is there any way to override the touch gesture detection in any manner? This issue is quite inconvenient from a user perspective.

There appears to be a visual bug when using .searchable in a child view that’s pushed via NavigationLink inside a NavigationStack. Specifically, the search bar appears briefly in the wrong position (or animates in an unexpected way) during the transition to the child view. This issue does not occur when using NavigationView instead of NavigationStack. Steps to Reproduce: Create a TabView with a single tab containing a NavigationStack. Push from a ContentView to a DetailsView using NavigationLink. Add a .searchable modifier to both the ContentView and DetailsView. Run the app and tap a row to navigate to the details view. Expected Behavior The search bar in the DetailsView should appear smoothly and in the correct position as the view transitions in, just like it does under NavigationView. Actual Behavior When the DetailsView appears, the search bar briefly animates or appears in the wrong location before settling into place. This results in a jarring or buggy visual experience. Feedback: FB17031212 Here is a reddit thread discussing the issue as well https://www.reddit.com/r/SwiftUI/comments/137epji/navigation_stack_with_search_bar_has_a_bug_and_a/ I hope that an Apple engineer can get this fixed soon. It's frustrating to have new APIs come out with the old deprecated yet there are still obvious bugs two years later. import SwiftUI public enum Tab { case main } struct AppTabNavigation: View { @State private var tabSelection = Tab.main var body: some View { TabView(selection: $tabSelection) { NavigationStack { ContentView() } .tag(Tab.main) .tabItem { Label("Main", systemImage: "star") } } } } struct ContentView: View { @State private var searchText = "" var body: some View { List(0..<100) { i in NavigationLink("Select \(i)", value: i) } .navigationTitle("Main") .searchable(text: $searchText) .navigationDestination(for: Int.self) { i in DetailsView(i: i) } } } struct DetailsView: View { @State private var searchText = "" let i: Int // MARK: - Body var body: some View { List { ForEach(0..<10, id: \.self) { i in Text("Hello \(i)") } } .navigationTitle(i.formatted()) .searchable(text: $searchText) } }

Hi! I am having issues with my internal testing app now showing up the same through different users devices?

I'm trying to determine if it’s possible to detect when a user interacts with a Slide Over window while my app is running in the background on iPadOS. I've explored lifecycle methods such as scenePhase and various UIApplication notifications (e.g., willResignActiveNotification) to detect focus loss, but these approaches don't seem to capture the event reliably. Has anyone found an alternative solution or workaround for detecting this specific state change? Any insights or recommended practices would be greatly appreciated.

Background I have a SwiftUI app that uses OSLog and the new Logger framework. In my SwiftUI views, I would like to use something like Self._logChanges() to help debug issues. After some trial and error, I can see the messages appear in the System console log for the app I am debugging using the com.apple.SwiftUI subsystem. Problem I'd like to see those same messages directly in Xcode's console window so I can filter them as needed. How do I do that? Thanks! -Patrick

I was doing an app which had several "camera" buttons each one dedicated to taking/storing/reviewing/deleting an image associated with a variable URL but what should have been a simple no brainer turned out to be a programming nightmare. To cut a long story short there is a bug in the sheet handling wherebye even tho you have separate instance for each button the camera/picker cylcles sequentially thru the stack of instances for any action finally always placing the image in the first URL. Working with myself debugging, all major AIs (Grok, Claude, Gemini and Perplexity) after 4 x 12hr+ days we finally managed to crack a solution. What follows is Groks interpretation (note it misses the earlier problem of instance cycling!!) ... You can follow the discussion here: https://x.com/i/grok/share/KHeaUPladURmbFq5qy9W506er but be warned its long a detailed but if you are having problems then read ... **Bug Report: Race Conditions with UIImagePickerController in SwiftUI Sheet ** Environment: SwiftUI, iOS 17.7.5 Device: iPad Pro (12.9-inch, 2nd generation) Xcode Version: [Insert your Xcode version] Date: March 30, 2025 **Issue 1: Multiple Instances of UIImagePickerController Spawned After Dismissal ** Description: When using a UIImagePickerController wrapped in a UIViewControllerRepresentable and presented via a SwiftUI .sheet, selecting "Use Photo" resulted in multiple unintended instances of the picker being initialized and presented. The console logs showed repeated "Camera initialized" and "Camera sheet appeared" messages (e.g., multiple <UIImagePickerController: 0x...> instances) after the initial dismissal, despite the sheet being dismissed programmatically. Reproduction Steps: Create a SwiftUI view with a button that sets a @State variable showCamera to true. Present a UIImagePickerController via .sheet(isPresented: $showCamera). Update a @Binding variable (e.g., photoLocation: URL?) in imagePickerController(_:didFinishPickingMediaWithInfo:) after saving the image. Dismiss the picker with picker.dismiss(animated: true) and presentationMode.wrappedValue.dismiss(). Observe that updating the @Binding variable triggers a view re-render, causing the .sheet to re-present multiple times before finally staying dismissed. Root Cause: A race condition occurred between the view update (triggered by changing photoLocation) and the dismissal of the picker. During the re-render, showCamera remained true momentarily, causing the .sheet modifier to re-evaluate and spawn new picker instances before the onDismiss closure could reset showCamera to false. The fix involved delaying the @Binding update (photoLocation) until after the picker and sheet were fully dismissed, ensuring showCamera was reset to false before the view re-rendered: Introduced an onPhotoPicked: (URL) -> Void closure to decouple the photoLocation update from the dismissal timing. Modified the coordinator to call onPhotoPicked and reset showCamera before initiating dismissal:swift Issue 2: Single Unintended Picker Reopen After Initial Fix Description: After addressing the multiple-instance issue, a single unintended reopen of the picker persisted. The logs showed one additional "Camera initialized" and "Camera sheet appeared" after "Use Photo," before the final dismissal. Reproduction Steps: Reproduction Steps: Use the initial fix with onPhotoPicked and delayed photoLocation update. Take a photo and select "Use Photo." Observe one extra picker instance appearing briefly before dismissal completes. Root Cause: The @Binding update (photoLocation) was still occurring too early in the dismissal sequence. Although delayed until after picker.dismiss, the view re-render happened while showCamera was still true during the dismissal animation, causing the .sheet to re-present once before onDismiss reset showCamera. Resolution: The fix ensured showCamera was set to false before the picker dismissal animation began, preventing the .sheet from re-evaluating during the transition: Moved the dismissCamera() call (which sets showCamera to false) into the onPhotoPicked callback, executed before picker.dismiss: CameraView( photoLocation: $photoLocation, storeDirectory: storeDirectory, onPhotoPicked: { url in print("Photo picked callback for \(id), setting photoLocation: \(url)") self.photoLocation = url self.cameraState.dismissCamera() // Sets showCamera to false first } ) Kept the dismissal sequence in the coordinator: DispatchQueue.main.async { self.parent.onPhotoPicked(fileURL) picker.dismiss(animated: true) { self.parent.presentationMode.wrappedValue.dismiss() } } This synchronized the state change with the dismissal, ensuring showCamera was false before the view re-rendered, eliminating the single reopen. Request: Could the SwiftUI team clarify if this behavior is expected, or consider improving the .sheet modifier to better handle state transitions during UIKit controller dismissal? A more robust bridge between SwiftUI’s declarative state and UIKit’s imperative lifecycle could prevent such race conditions.

Environment: • macOS: Sequoia 15.3.2 • Xcode: 16.2 • Framework: AppKit (Objective-C) Issue: When programmatically setting the first responder to an NSSecureTextField shortly after its containing window loads or becomes key, a visual anomaly intermittently occurs (roughly 50% of the time). A semi-transparent UI element—likely related to the system’s Keychain password suggestion/autofill feature—appears detached from the text field. Instead of anchoring to the field, it renders elsewhere on the screen. I found similar issues discussed here: https://stackoverflow.com/questions/74220070/strange-transparent-view-appears-beneath-textfield-in-mac-catalyst-app https://stackoverflow.com/questions/73277582/swiftui-view-with-textfield-and-securefield-buggy-on-macos-shows-strange-view/73615876#73615876 https://developer.apple.com/forums/thread/708075

为什么App 上传testFlight之后。无法通过NFC的方式唤醒 APP Clips。是必须要上架商店之后才能支持么？

I have a few crash report from TestFlight with this context and nothing else. No symbols of my application. Crash report is attached. crashlog.crash It crashes at 16H25 (local time paris) and a few minutes after (8) I see the same user doing task in background (they download data with a particular URL in BGtasks) with a Delay that is consistant with a background wait of 5 or 7 minutes. I have no more information on this crash and by the way Xcode refuses to load it and shows an error. ( I did a report via Xcode for this).

import SwiftUI import OsLog let logger = Logger(subsystem: "Test", category: "Test") struct ContentView: View { var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") } .padding() .task { logger.info("Hallo") } } } #Preview { ContentView() } 27 | .padding() 28 | .task { 29 | logger.info(__designTimeString("#6734_2", fallback: "Hallo")) | `- error: argument must be a string interpolation 30 | } 31 | } Should OsLog be compatible with __designTimeString?