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.

My App Clip is associated with three domains: • nfc.ttwifi.net • qr.ttwifi.net Currently, I’m experiencing an issue where scanning a QR code from qr.ttwifi.net correctly launches my App Clip. However, when I scan a QR code from nfc.ttwifi.net, it successfully displays the App Clip card but then shows the message “App Clip unavailable.” I checked the Website Status in App Store Connect, and both domains have their Debugging Status and Cache Status marked as Verified. One important detail to note: Yesterday, while submitting a new version for review, I noticed that nfc.ttwifi.net showed “Unable to connect to AASA file” in the Cache Status in App Store Connect. The cache status update time was March 27, 2025, at 6:52 PM. However, when I checked today, both domains appeared to be fine, and the cache status update time was March 27, 2025, at 7:07 PM. How can I restore the App Clip functionality for my nfc.ttwifi.net domain?

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) } }

I've developed an app in swift and UIKit. Its multi linguistic app supports English and Arabic. When I change the language from English to Arabic or Arabic to English. After changing language, when I navigate through different screens crash is happening randomly on different screens most of the time when I tap to navigate to a screen. And cash log is: This time crashed with this error Exception NSException * "Not possible to remove variable:\t945: <unknown var (bug!) with engine as delegate:0x2824edf00>{id: 34210} colIndex:261 from engine <NSISEngine: 0x15c5dd5f0>{ delegate:0x15c594b50\nEngineVars:\n\t 0: objective{id: 31542} rowIndex:0\n\t 1: UIButton:0x15c6255b0.Width{id: 31545} rowIndex:1\n\t 2: 0x281c41450.marker{id: 31548} colIndex:1\n\t 3: UIButton:0x15c6255b0.Height{id: 31547} rowIndex:1073741824\n\t 4: 0x281c412c0.marker{id: 31546} colIndex:1073741825\n\t 5: UIButton:0x15c625a50.Width{id: 31549} rowIndex:11\n\t 6: 0x281c41270.marker{id: 31544} colIndex:2\n\t 7: UIButton:0x15c625a50.Height{id: 31551} rowIndex:1073741825\n\t 8: 0x281c414a0.marker{id: 31550} colIndex:1073741826\n\t 9: UILabel:0x15c625d10.Height{id: 31553} rowIndex:1073741826\n\t 10: 0x281c41590.marker{id: 31552} colIndex:1073741827\n\t 11: UIImageView:0x15c625870.Width{id: 31555} rowIndex:3\n\t 12: 0x281c41360.marker{id: 31554} colIndex:3\n\t 13: UIImageView:0x15c625870.Height{id: 31557} rowIndex:1073741827\n\t 14: 0x281c413b0.marker{id: 31556} colIndex:1073741828"... 0x0000000282fb11a0 For switching language I'm using this code snippet: private func restartApp() { guard let windowScene = UIApplication.shared.connectedScenes.first as? UIWindowScene, let delegate = windowScene.delegate as? SceneDelegate, let window = delegate.window else { return } // Create a new root view controller let vc : AppLoadingVC = AppRouter.instantiateViewController(storyboard: .Splash) let nc = UINavigationController(rootViewController: vc) ApplicationManager.sharedInstance.isUserLoggedIn = false DispatchQueue.main.async { if UserDefaults.isRTL { UIView.appearance().semanticContentAttribute = .forceRightToLeft SideMenuController.preferences.basic.forceRightToLeft = true Localize.setCurrentLanguage("ar") } else { UIView.appearance().semanticContentAttribute = .forceLeftToRight SideMenuController.preferences.basic.forceRightToLeft = false Localize.setCurrentLanguage("en") } window.rootViewController = nc window.makeKeyAndVisible() } } Please anybody help me I've been stuck here since lot of days. I tried multiple things but all in vain.

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) } }

I have an app that run Monte Carlo simulations. I run thousands of simulations in the app and a simulation runs can take on the order of 30 seconds to a minute to complete. I would like to have a progress view that tracks the number of simulation runs. How can I implement this in swiftui?

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.

In order to make referencing keys for localized strings a little more reliable, our application references generated constants for localized string keys: This eliminates the potential for developers to misspell a key when referencing a localized strings. And because these constants are automatically generated by the exact same process that provides localized strings for the application, each and every constant is guaranteed to have a localized string associated with it. I’m currently attempting to implement something similar for the localized strings referenced by our new App Intents. Our initial release of App Intent functionality is simply using string literals to reference localized strings: However, I am running into several issues when trying to reference the string keys as a constant. The closest I managed to get was defining the constant as either a LocalizationValue or as a StaticString and referencing the constant while initializing the LocalizedStringResource. With this approach, I see no errors from Xcode until I try and compile. What’s more is that the wording of the error being thrown is quite peculiar: As you can see with the sample code above, I am clearly calling LocalizedStringResource’s initializer directly as Indicated by the error. Is what I’m trying to do even possible with App Intents? From my research, it does look like iOS app localization is moving more towards using string literals for localized strings. Like with String Catalog’s ability to automatically generate entries from strings referenced in UI without the need for a key. However, we’d prefer to use constants if possible for the reasons listed above.

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

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

I had a problem with my app (or in my setup) and searching the web I found a very simple code where part of my problem occurs. I create a new Multiplatform App and paste this code in ContentView. import SwiftUI struct ContentView: View { var body: some View { NavigationStack { VStack { Text("Navigation article") .font(.title) .padding() NavigationLink("Go to the second view", destination: SecondView()) .padding() } .navigationTitle("First View") } } } struct SecondView: View { var body: some View { Text("This is the Second view") .font(.headline) .padding() .navigationTitle("Second View") } } run on iPhone/ iOS no problem run on a Mac/macOS Going from view 1 to view 2 work, the back arrow on view 2 is there, and it is working but the second time I go to the view 2, the back arrow is gone. after looking closely I can see the Arrow Underneath the S of SecondView. I have tried many things and could not make it work. I post this in a HackingWithSwift forum and somebody tried the code and said it work. so it seems the problem could be related to my setup but I create another user in my computer , same problem and tried it on my another computer, same problem.

I am trying to make a collection view with self-sizing cells that adapt to SwiftUI content. My test platform is macOS, but it should work on iOS all the same. I chose macOS because on macOS, you can resize the window and cause more interesting scenarios with that. My layout intent is fairly simple: a one-column collection view with cells with SwiftUI content, where the collection view cells should adapt to the height of their SwiftUI content. I got it working almost correctly. The one scenario that I don’t have working is window resizing. When the window resizes, the layout and cells should adapt to the content and change their heights. I feel that I am missing something fairly basic. How do I change this project so that the layout works correctly when I change the macOS window width? Example project and video of the behavior: https://gist.github.com/jaanus/66e3d863941ba645c88220b8a22970e1

I'm currently integrating SwiftUI into an AppKit based application and was curious if the design pattern below was viable or not. In order to "bridge" between AppKit and SwiftUI, most of my SwiftUI "root" views have aViewModel that is accessible to the SwiftUI view via @ObservedObject. When a SwiftUI views need to use NSViewRepresentable I'm finding the use of a ViewModel and a Coordinator to be an unnecessary layer of indirection. In cases where it makes sense, I've just used the ViewModel as the Coordinator and it all appears to be working ok, but I'm curious if this is reasonable design pattern or if I'm overlooking something. Consider the following pseudo code: // 1. A normal @ObservedObject acting as the ViewModel that also owns and manages an NSTableView. @MainActor final class ViewModel: ObservedObject, NSTableView... { let scrollView: NSScrollView let tableView: NSTableView @Published var selectedTitle: String init() { // ViewModel manages tableView as its dataSource and delegate. tableView.dataSource = self tableView.delegate = self } func reload() { tableView.reloadData() } // Update view model properties. // Simpler than passing back up through a Coordinator. func tableViewSelectionDidChange(_ notification: Notification) { selectedTitle = tableView.selectedItem.title } } // 2. A normal SwiftUI view, mostly driven by the ViewModel. struct ContentView: View { @ObservedObject model: ViewModel var body: some View { Text(model.selectedTitle) // No need to pass anything down other than the view model. MyTableView(model: model) Button("Reload") { model.reload() } Button("Delete") { model.deleteRow(...) } } } // 3. A barebones NSViewRepresentable that just vends the required NSView. No other state is required as the ViewModel handles all interactions with the view. struct MyTableView: NSViewRepresentable { // Can this even be an NSView? let model: ViewModel func makeNSView(context: Context) -> some NSView { return model.scrollView } func updateNSView(_ nsView: NSViewType, context: Context) { // Not needed, all updates are driven through the ViewModel. } } From what I can tell, the above is working as expected, but I'm curious if there are some situations where this could "break", particularly around the lifecycle of NSViewRepresentable Would love to know if overall pattern is "ok" from a SwiftUI perspective.

Hi! I'm seeing some weird animation issues building the Food Truck sample application.^1 I'm running from macOS 15.4 and Xcode 16.3. I'm building the Food Truck application for macOS. I'm not focusing on iOS for now. The FoodTruckModel adds new Order values with an animation: // FoodTruckModel.swift withAnimation(.spring(response: 0.4, dampingFraction: 1)) { self.orders.append(orderGenerator.generateOrder(number: orders.count + 1, date: .now, generator: &generator)) } This then animates the OrdersTable when new Order values are added. Here is a small change to OrdersTable: // OrdersTable.swift - @State private var sortOrder = [KeyPathComparator(\Order.status, order: .reverse)] + @State private var sortOrder = [KeyPathComparator(\Order.creationDate, order: .reverse)] Running the app now inserts new Order values at the top. The problem is I seem to be seeing some weird animation issues here. It seems that as soon as the new Order comes in there is some kind of weird glitch where it appears as if part the animation is coming from the side instead of down from the top: What's then more weird is that if I seem to affect the state of the Table in any way then the next Order comes in with perfect animation. Scrolling the Table fixes the animation. Changing the creationData sort order from reverse to forward and back to reverse fixes the animation. Any ideas? Is there something about how the Food Truck product is built that would cause this to happen? Is this an underlying issue in the SwiftUI infra?

Hi, I got a problem with severe hangs when I use code like this on tvOS 18.2 If I try to use HStack instead of LazyHStack inside the scrollview then the problem does not occur any more but then the scroll performance is compromised and the vertical scroll is no longer that smooth. Does someone has any experience with this? Is this SwiftUI problem or am I missing something? ScrollView { LazyVStack { ForEach(0...100, id: \.self) { _ in ScrollView { LazyHStack { ForEach(0...20, id: \.self) { _ in Color.red.frame(height: 300) } } } } } }

One of our users reported a very strange bug where our app freezes and eventually crashes on some screen transitions. From different crash logs we could determine that the app freezes up when we call view.layoutIfNeeded() for animating constraint changes. It then gets killed by the watchdog 10 seconds later: Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: app<bundleID(2A01F261-3554-44C0-B5A9-EBEB446484AD)>:6921 exhausted real (wall clock) time allowance of 10.00 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: scene-update WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 24.320 (user 18.860, system 5.460), 29% CPU", "Elapsed application CPU time (seconds): 10.630, 12% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive> The crash stack trace looks slightly different, depending on the UI transition that is happening. Here are the two we observed so far. Both are triggered by the layoutIfNeeded() call. Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 CoreAutoLayout 0x1b09f90e4 -[NSISEngine valueForEngineVar:] + 8 1 UIKitCore 0x18f919478 -[_UIViewLayoutEngineRelativeAlignmentRectOriginCache origin] + 372 2 UIKitCore 0x18f918f18 -[UIView _nsis_center:bounds:inEngine:forLayoutGuide:] + 1372 3 UIKitCore 0x18f908e9c -[UIView(Geometry) _applyISEngineLayoutValuesToBoundsOnly:] + 248 4 UIKitCore 0x18f9089e0 -[UIView(Geometry) _resizeWithOldSuperviewSize:] + 148 5 CoreFoundation 0x18d0cd6a4 __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 6 CoreFoundation 0x18d0cd584 -[__NSArrayM enumerateObjectsWithOptions:usingBlock:] + 432 7 UIKitCore 0x18f8e62b0 -[UIView(Geometry) resizeSubviewsWithOldSize:] + 128 8 UIKitCore 0x18f977194 -[UIView(AdditionalLayoutSupport) _is_layout] + 124 9 UIKitCore 0x18f976c2c -[UIView _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 800 10 UIKitCore 0x18f903944 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2728 11 QuartzCore 0x18ec15498 CA::Layer::layout_if_needed(CA::Transaction*) + 496 12 UIKitCore 0x18f940c10 -[UIView(Hierarchy) layoutBelowIfNeeded] + 312 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 QuartzCore 0x18ec2cfe0 -[CALayer animationForKey:] + 176 1 UIKitCore 0x18fa5b258 UniqueAnimationKeyForLayer + 192 2 UIKitCore 0x18fa5ab7c __67-[_UIViewAdditiveAnimationAction runActionForKey:object:arguments:]_block_invoke_2 + 468 3 UIKitCore 0x18fa5ba5c -[_UIViewAdditiveAnimationAction runActionForKey:object:arguments:] + 1968 4 QuartzCore 0x18eb9e938 CA::Layer::set_bounds(CA::Rect const&, bool) + 428 5 QuartzCore 0x18eb9e760 -[CALayer setBounds:] + 132 6 UIKitCore 0x18f941770 -[UIView _backing_setBounds:] + 64 7 UIKitCore 0x18f940404 -[UIView(Geometry) setBounds:] + 340 8 UIKitCore 0x18f908f84 -[UIView(Geometry) _applyISEngineLayoutValuesToBoundsOnly:] + 480 9 UIKitCore 0x18f9089e0 -[UIView(Geometry) _resizeWithOldSuperviewSize:] + 148 10 CoreFoundation 0x18d0cd6a4 __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 11 CoreFoundation 0x18d132488 -[__NSSingleObjectArrayI enumerateObjectsWithOptions:usingBlock:] + 92 12 UIKitCore 0x18f8e62b0 -[UIView(Geometry) resizeSubviewsWithOldSize:] + 128 13 UIKitCore 0x18f977194 -[UIView(AdditionalLayoutSupport) _is_layout] + 124 14 UIKitCore 0x18f976c2c -[UIView _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 800 15 UIKitCore 0x18f916258 -[UIView(Hierarchy) layoutSubviews] + 204 16 UIKitCore 0x18f903814 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2424 17 QuartzCore 0x18ec15498 CA::Layer::layout_if_needed(CA::Transaction*) + 496 18 UIKitCore 0x18f940c10 -[UIView(Hierarchy) layoutBelowIfNeeded] + 312 So far, we only know of one iPad Air M1 where this is happening. But we don't know how many users experience this issue without reporting it. Does anyone know what could cause Auto Layout or Core Animation to block in those calls? We have no clue so far...

I have an app with two file types with the following extensions: gop (an exported type), sgf (an imported type). The Save command fails after the following sequence of events: I open a gop file, say the file "A.gop". I save this file as an sgf file, say "A.sgf". This Save As works perfectly and the document name in the document’s title bar has changed to "A.sgf". I change something in the document and then try to Save this change. This should just resave the document to "A.sgf", but "A.sgf" remains untouched. Instead I get a system alert with the message The document “A.sgf” could not be saved. A file with the name “A.gop” already exists. To save the file, either provide a different name, or move aside or delete the existing file, and try again. In the Xcode console I get the following diagnostic: NSFileSandboxingRequestRelatedItemExtension: an error was received from pboxd instead of a token. Domain: NSPOSIXErrorDomain, code: 2 [NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/francois/Desktop/A.sgf, newURL: file:///Users/francois/Desktop/A.gop The problem seems to relate to the sandbox. But I am at a loss to find a solution. (After closing the alert, I check that A.sgf did not register the change.) If I open an sgf file, say "B.sgf", save it as "B.gop", make a change in the document and then try to save this change (into "B.gop"), I hit the same problem, with "gop" and "sgf" interchanged. If, instead of saving "A.gop" as "A.sgf", I save it as "B.sgf", make a change in the document and then try to save this change into "B.sgf", I get the following system alert: The document “B.sgf” could not be saved. You don’t have permission. To view or change permissions, select the item in the Finder and choose File &gt; Get Info. And in the Xcode console I get the following diagnostic: NSFileSandboxingRequestRelatedItemExtension: an error was received from pboxd instead of a token. Domain: NSPOSIXErrorDomain, code: 2 [NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/francois/Desktop/B.sgf, newURL: file:///Users/francois/Desktop/B.gop Again the sandbox ! (After closing the alert, I check that B.sgf did not register the change.) It’s clear my code is missing something, but what?

I want record screen in my app,the method startCaptureWithHandler:completionHandler:,the sampleBuffer， It is supposed to exist but it has become nil.Not only that,but there‘s another problem,when I want to stop recording and save the video,I will check [RPScreenRecorder sharedRecorder].recording first, it will be false sometime,that problems are unusual in iOS 18.3.2 iPhoneXs Max,and unexpected,here is my code -(void)startCaptureScreen { NSLog(@"AKA++ startCaptureScreen"); if ([[RPScreenRecorder sharedRecorder] isRecording]) { return; } //屏幕录制 [[RPScreenRecorder sharedRecorder]setMicrophoneEnabled:YES]; NSLog(@"AKA++ MicrophoneEnabled AAAA startCaptureScreen"); [[RPScreenRecorder sharedRecorder]setCameraEnabled:YES]; [[RPScreenRecorder sharedRecorder] startCaptureWithHandler:^(CMSampleBufferRef _Nonnull sampleBuffer, RPSampleBufferType bufferType, NSError * _Nullable error) { if(self.assetWriter == nil){ if (self.AVAssetWriterStatus == 0) { [self setupAssetWriterAndStartWith:sampleBuffer]; } } if (self.AVAssetWriterStatus != 2) { return; } if (error) { // deal with error return; } if (self.assetWriter.status != AVAssetWriterStatusWriting) { [self assetWriterAppendSampleBufferFailWith:bufferType]; return; } if (bufferType == RPSampleBufferTypeVideo) { if(self.assetWriter.status == 0 ||self.assetWriter.status > 2){ } else if(self.videoAssetWriterInput.readyForMoreMediaData == YES){ BOOL success = [self.videoAssetWriterInput appendSampleBuffer:sampleBuffer]; } } if (bufferType == RPSampleBufferTypeAudioMic) { if(self.assetWriter.status == 0 ||self.assetWriter.status > 2){ } else if(self.audioAssetWriterInput.readyForMoreMediaData == YES){ BOOL success = [self.audioAssetWriterInput appendSampleBuffer:sampleBuffer]; } } } completionHandler:^(NSError * _Nullable error) { //deal with error }]; } and than ,when want to save it : -(void)stopRecording { if([[RPScreenRecorder sharedRecorder] isRecording]){ // The problem is sporadic,recording action failed,it makes me confused } [[RPScreenRecorder sharedRecorder] stopCaptureWithHandler:^(NSError * _Nullable error) { if(!error) { //post message } }]; }

We've seen a spike in crashes on iOS 18.4 across both iPhone & iPad. We can't reproduce it, but it looks like it happens when the app goes into the background. Crash Log