I'm having this problem, with this code: let docPicker = UIDocumentPickerViewController(forOpeningContentTypes: [ .pdf ]) docPicker.delegate = self docPicker.modalPresentationStyle = .currentContext view.window?.rootViewController?.present(docPicker, animated: true, completion: nil) but then when I open the simulator and click the button that calls to the method that has this code... Cannot pick the pdf document. Testing in browserstack with real devices is working, but it's a very slow process, why I cannot use simulators to make work this?

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

Hi all, I am trying to allow users of my app to select extra options when opening documents, and to remember those options when re-opening documents at launch. So far best idea I have is: Subclass NSDocumentController to provide an NSOpenPanel.accessoryView with the options Create a URL bookmark for each opened file and keep a mapping of bookmarks to options On launch and when the recent documents list changes, prune the stored mappings to match only the recent items Has anyone done this before, or know of a better approach? Thank you.

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.

Issue:- The characters in SearchController SearchBar are overlapping on focusing. Steps:- Select the System language as Arabic Launch the tvOS app Set the app language as English in the tvOS app Focus on SearchController SearchBar Focus on any characters there you can see overlapping issue.

As SwiftUI adoption grows, developers face challenges in effectively measuring and optimizing SwiftUI app performance within automated tests. Currently, the only viable approach to analyzing SwiftUI performance is through Profiling (Instruments), which, while powerful, lacks the ability to be incorporated into automated testing workflows. It would be incredibly valuable if XCTest could introduce new performance metrics specifically tailored for SwiftUI, allowing us to write tests against common performance bottlenecks. Suggested Metrics: View Body Evaluation Count – Tracks how often a SwiftUI body is recomputed to detect unnecessary re-renders. Slow View Bodies – Flags SwiftUI views that take a significant amount of time to compute their body. These metrics would help developers identify inefficiencies early, enforce performance best practices through CI/CD pipelines, and ensure a smooth user experience. I believe adding these performance metrics would be a game-changer for SwiftUI development. Thank you for your time and consideration!

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 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.

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?

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?

I'm creating an app which gamifies Screen Time reduction. I'm running into an issue with apples Screen Time setting where the user can disable my apps "Screen Time access" and get around losing the game. Is there a way to detect when this setting is disabled for my app? I've tried using AuthorizationCenter.shared.authorizationStatus but this didn't do the trick. Does anyone have an ideas?

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.

Hi, I am developing a new SwiftUI app. Running under OSX, I see very high cpu usage (I am generating lots of gpu based updates which shouldn't affect the cpu). I have used the profiler to ensure my swift property updates are minimal, yet the cpu usage is high coming from SwiftUI. It seems the high cpu usage is coming from NSAppearance, specifically, CUICopyMeasurements - for a single button??? But the swift updates don't show any buttons being updating

I have a controller that displays a pdf using UIDocumentInteractionController as the presented view. When users open it up, it shows fine. User gets the app backgrounded and session timed out. After timed out, when the app is brought to foreground, I bring our loginVC by removing the old VC used to show the UIDocumentInteractionController. All the crashes are happening at this point. I am not able to reproduce it, but our alert systems show we have crashes happening. The code that shows the pdf is straight forward documentViewController = UIDocumentInteractionController() documentViewController?.delegate = self documentViewController?.url = url documentViewController?.presentPreview(animated: true) and we reset it to nil in delegate documentInteractionControllerDidEndPreview Based on the crash trace, it seems like the crash happens when our login VC replaces it and only when pdf was displayed. The reason of stressing ONLY because when we have other viewcontroller present and they are removed in a similar way, we do not see any issue. So we always replace first and then add a new one childViewController.willMove(toParent: nil) childViewController.viewIfLoaded?.removeFromSuperview() childViewController.removeFromParent() addChild(childViewController) view.addSubview(childViewController.view) childViewController.view.frame = view.bounds childViewController.didMove(toParent: self) Raised a ticket with Apple, but I haven't heard back, and it's been a month. Posting here in case anyone experiences the same and has any solutions. I saw some related posts, and solution was to remove the pdf the moment the app goes to the background, but I am trying to find some alternate solution if possible.

I tried to create a Text View using attributedString. I want to set the line height using paragraphStyle and return the Text, but paragraphStyle is not being applied. Why is that? extension Text { init?(_ content: String, font: StyleType, color: Color = .ppBlack) { var attributedString = AttributedString(content) attributedString.font = Font.custom(font.fontWeight, fixedSize: font.fontSize) attributedString.foregroundColor = color let paragraphStyle = NSMutableParagraphStyle() paragraphStyle.minimumLineHeight = 16 paragraphStyle.maximumLineHeight = 16 paragraphStyle.lineSpacing = 0 attributedString.mergeAttributes(.init([.paragraphStyle: paragraphStyle])) self = Text(attributedString) } }

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

Pasting either plain or styled text into any TextEditor results in a memory leak. import SwiftUI struct EditorView: View { @State private var inputText: String = "" var body: some View { VStack{ TextEditor(text: $inputText) .frame(minHeight: 150) } } }

I'm trying to render a markdown with a link using Text. If the URL of the link is a static string, then no problem. If the URL is a property, then OpenURLAction gets a string ‘%25@’. I think this may be a bug. struct ContentView: View { let url = "https://www.google.com" var body: some View { Text("[Terms of Service](\(url))") .environment(\.openURL, OpenURLAction(handler: { url in print(url) return .handled })) } }

I have an attributedString with 100 NSTextAttachments(contains image of 400kb). When i scroll the textview, it is lagging, When i did the same in textkit 1, it is butter smooth. It can be because of how textkit 1 & 2 layout the elements. let attachment = NSTextAttachment() attachment.image = UIImage(named: "image2") let attachmentString = NSAttributedString(attachment: attachment) let mutableAttributedString = NSMutableAttributedString(attributedString: textView.attributedText) for _ in 0...100 { mutableAttributedString.append(NSAttributedString(string: "\n")) mutableAttributedString.append(attachmentString) } textView.attributedText = mutableAttributedString How to handle images in textkit 2 so that it feels smooth while scrolling textview?

In tvOS when using NavigationStack inside NavigationSplitView as below: @State private var selectedItem: String? @State private var navigationPath = NavigationPath() // Track navigation state manually var body: some View { NavigationSplitView { List(selection: $selectedItem) { Button("Item 1") { selectedItem = "Detail View 1" } Button("Item 2") { selectedItem = "Detail View 2" } } } detail: { NavigationStack(path: $navigationPath) { DetailView() .navigationDestination(for: String.self) { value in Text("New Screen: \(value)") } } } } } This example completely breaks the animation inside NavigationStack while navigating between different views, using withAnimation also breaks the navigation as the old view seems to be still in stack and is shown in the new view background. I have also submitted bug report: https://feedbackassistant.apple.com/feedback/16933927