var format = "%7B%22sign%22%3Anull%2C%22company%22%3A%22%E5%85%84%E5%BC%9F%E6%B5%B7%E6%B4%8B%E7%A7%91%E6%8A%80%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%22%2C%22businessNo%22%3Anull%2C%22scene%22%3Anull%2C%22interviewCode%22%3A%22767676%22%7D" let message = withVaList([]) { args in let msg = NSString(format: format, arguments: args) print(msg) }

I was just having a look at some crash reports downloaded by Xcode, and I noticed the same wrong pattern I already mentioned here: the crash reports indicate that method A calls method B, which is impossible. In the first crash report below, method MainViewController.showSettings seems to be called by ConfirmMoveViewController.openSourceInFinder, which is impossible. ConfirmMoveViewController.openSourceInFinder is a context menu action in a modal window, and MainViewController.showSettings is in a completely different window and the two methods have no relation whatsoever. In the second crash report below, MainViewController.setSortMode is triggered by the press of a button (and nothing else) but seems to be called by OtherViewController.copy that can be triggered by a context menu (or keyboard shortcut). The two methods have no relation whatsoever. The rest of the stack trace confirm that it's indeed the button that was pressed. This seems to me like a quite serious bug in how macOS creates crash reports. 1.crash 2.crash

We are experiencing an issue where our app gets stuck during launch. The splash screen appears for some time, and then the app either becomes unresponsive or closes unexpectedly. However, there are no crash logs captured in Xcode or Firebase Crashlytics, indicating that the app is not crashing but rather being terminated. This issue is preventing affected users from properly launching the app. Additionally, some users have reported occasional lag and slow performance when using the app. The issue occurs only for a specific subset of users and appears to be related to other Electronic Logging Device (ELD) apps running in the background. When these apps are active, our app struggles to launch and sometimes becomes unresponsive. We suspect that this behavior could be related to system resource allocation, such as high memory consumption by background apps, which might be affecting our app's ability to launch correctly. However, we have been unable to reproduce the issue on our end despite multiple attempts. Actions Performed During App Launch: Firebase configuration API requests, including: Fetching account details Registering the FCM token with the server Asynchronous background requests to fetch POI details Creating a local database and storing POI data in local storage We would like guidance from Apple regarding potential causes and debugging strategies, especially in scenarios where the app does not produce crash logs but still fails to launch properly. Any insights into memory management, conflicts with background applications, or system resource constraints would be highly appreciated. Steps to Reproduce: Install and launch the app on an affected device. Observe that the app gets stuck on the launch screen. After some time, the app terminates unexpectedly. Issue is inconsistent and occurs only for certain users. Presence of other ELD apps running in the background appears to influence the issue.

I have found a system bug with UINavigationController, UIGestureRecognizerDelegate mainly the swipe back control. I have reproduced this in many apps, while some that use custom swipe back i can not reproduce, however any app using default uikit/swift transitions i can reproduce the flicker/previous screen flashing The Bug: a slight tap or series of quick taps anywhere on the screen (with the slightest (1-2pt -x)confuse the system into thinking its a swipe back gesture, however instead of pushing back to previous screen the UI flickers and flashes the previous screen. for a split second, very easy to reproduce. on screens with lots of options of boxes to tap it happens quite often. I have removed all custom "swipe back from anywhere" logic, all custom gesture logic, and can still reproduce by tapping the edge of the screen with only UINavigationController, UIGestureRecognizerDelegate in my navigation controller. Please let me know the best way to get in contact with someone at apple to either build an extension to prevent this flicker or if a developer has a fix but this is rarely talked about. (velocity limits etc do not work, and just make the gesture feel awful) all the developers i have reached out too have looked into this and have said "its an ios bug, only fix is build a custom swipe back from anywhere, or wait for apple to fix it).... as a small indie app, building my own seems daunting Recap: quick or taps with small x movement flash previous screen instead of pushing back or simply recognizing it as a tap and not flashing previous screen. this happens with no custom code default uikit/swift. Link me your app i can probably reproduce it, I have reproduced it in X(was hard), Retro(easy), and many more. The goal is to have a smooth native swipe/drag back from anywhere gesture while preventing flicking on fast taps or short taps with minor x movement. i have tried everything from setting limits to -x, velocity limits etc. nothing fixes this. happy hacking! PS i hope someone at apple calls me and i can explain this and we can fix it for every app in an update.

Hi, I’m experiencing an issue where my React Native (Expo) app crashes immediately in TestFlight after launching, but it works fine in Expo Go and the iOS Simulator. This is my first time building an IOS app, so I'm not sure where I'm going wrong. Are there known issues with JS bundle loading, native module compatibility, or API entitlements that could be causing this? What tools or logs should I use to track the exact source of failure? Any guidance would be greatly appreciated! Thank you. Steps Taken: The app runs fine in Expo Go (npx expo start --no-dev --minify) and in the iOS Simulator (npx expo run:ios --clean). I also did (npx expo-doctor) and it passed all 15 checks. After building with EAS (eas build --platform ios --profile production), the TestFlight build crashes on launch. I checked Xcode logs (Devices & Simulators > View Device Logs) and found this error: `Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: LoungeNavigator [4666] Triggered by Thread: 6 Thread 6 name: Thread 6 Crashed: Thread 6 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000 My app.json file: "expo": { "name": "appname", "slug": "app", "owner": "baint", "version": "0.5.2", "orientation": "portrait", "icon": "./assets/images/IOS-App-Icon.png", "scheme": "myapp", "userInterfaceStyle": "automatic", "newArchEnabled": true, "ios": { "supportsTablet": true, "bundleIdentifier": "bundleIdentifier", "icon": "./assets/images/IOS-App-Icon.png", "buildNumber": "7", "infoPlist": { "NSLocationAlwaysAndWhenInUseUsageDescription": "This app requires access to your location at all times.", "NSLocationAlwaysUsageDescription": "This app needs your location even when the app is in the background.", "NSLocationWhenInUseUsageDescription": "We need your location.", "ITSAppUsesNonExemptEncryption": false } }, "android": { "adaptiveIcon": { "foregroundImage": "./assets/images/IOS-App-Icon.png", "backgroundColor": "#ffffff" }, "package": "identifier" }, "web": { "bundler": "metro", "output": "static", "favicon": "./assets/images/favicon.png" }, "plugins": [ "expo-router", [ "expo-splash-screen", { "image": "./assets/images/IOS-App-Icon.png", "imageWidth": 200, "resizeMode": "contain", "backgroundColor": "#ffffff" } ], "expo-asset", [ "@rnmapbox/maps", { "RNMapboxMapsImpl": "mapbox", "ios": { "RNMapboxMapsDownloadToken": "token", "RNMapboxMapsAccessToken": "token", "NSLocationAlwaysAndWhenInUseUsageDescription": "This app requires access to your location at all times.", "NSLocationAlwaysUsageDescription": "This app needs your location even when the app is in the background.", "NSLocationWhenInUseUsageDescription": "We need your location." } } ], [ "expo-build-properties", { "ios": { "useFrameworks": "static", "useModularHeaders": true } } ] ], "experiments": { "typedRoutes": true }, "extra": { "router": { "origin": false }, "eas": { "projectId": "projectid" } } } } My eas.json file: "cli": { "version": ">= 14.7.1", "appVersionSource": "remote" }, "build": { "development": { "developmentClient": true, "distribution": "internal" }, "preview": { "distribution": "internal" }, "internal": { "distribution": "store", "ios": { "credentialsSource": "remote" }, "autoIncrement": true, "env": { "EXPO_PUBLIC_NODE_ENV": "production" } }, "production": { "autoIncrement": true, "distribution": "store", "env": { "EXPO_PUBLIC_NODE_ENV": "production" } } }, "submit": { "production": { "ios": { "ascAppId": "ascAppId", "appleId": "appleId", "ascApiKeyPath": "ascApiKeyPath" } } } }

When apple pay on the web does a onshippingcontactselected it appears to truncate the zip code. If I enter: 11111 or 11111-1111 I always get 11111. Is there any way to get the plus 4?

I am working on an XCode project and I have some Swift functions within a helper functions file. This file has some functions declared that create 3 global variables. These global variables are then used in various views throughout the app. In the functions, there are print statements for when it catches an error. However, when I run the app and I get an error that stems from this file, there are no print statements. How can I have this print statements show up in the debug console?

When I toggle a panel like navigationsidebar, I get a message in the console. I guess it's not a big issue, but is there a way to fix this message? because it appears in every project. Unable to open mach-O at path: /AppleInternal/Library/BuildRoots/d187757d-b9a3-11ef-83e5-aabfac210453/Library/Caches/com.apple.xbs/Binaries/RenderBox/install/TempContent/Root/System/Library/PrivateFrameworks/RenderBox.framework/Versions/A/Resources/default.metallib Error:2

When you build a static library that includes DWARF information, you may encounter error messages in the binary package generated by Xcodebuild. Upon examining the DWARF information with dwarfdump, you will find that any entries containing keywords like dir are all absolute paths specific to the publisher's computer. This is quite alarming, as it poses a risk of leaking private information. Additionally, when debugging an app, you can encounter consistent warning notes indicating that the referenced path addresses cannot be found. This is because the absolute path addresses generated during the 'xcodebuild' process reflect the paths from the computer used to build it. When distributing this to others, how can anyone access these paths? Has the design of the secondary linking process for DWARF considered the issues related to binary distribution? Are there existing solutions to address and handle privacy concerns? Is there a solution to allow the distributed DWARF files to be correctly recognized during compilation and debugging of the app? BTW: Incorrect paths can indeed affect LLDB's ability to load and debug the application effectively?

Xcode 16.1 iOS 18.1 iPad Air 13-inch (M2) I have created a completely new Xcode project with Swift and Storyboard. In Storyboard, I only have a tabBarController with two attached UIViewControllers. The code from the base project hasn't been changed at all. I created a UITest with a very simple premise. let app = XCUIApplication() override func setupWithError() throws { continueAfterFailure = false app.launch() } func testTabBarExistence() { let tabBar = app.tabBars.element(boundBy: 0) XCTAssertTrue(tabBar.waitForExistence(timeout: 5), "Tab bar should exist") } But this test always fails for iPad on iOS 18+, but it will succeed for anything lower (e.g. 17.5)

Hi all, reposting this from here: https://unix.stackexchange.com/questions/789849/xattr-c-not-removing-com-apple-finderinfo-attribute I came to this problem because my Xcode project was failing to build due to the error "resource fork, Finder information, or similar detritus not allowed" (was trying the solutions on this post). Basically, running xattr -cr . in the terminal on my project directory removes all extended attributes except com.apple.FinderInfo, which stays on all .xcodeproj and .xcworkspace files. I've tried everything under the sun, from sudo to xattr -d to dot_clean to tar to rsync and nothing works. Is this just an immortal attribute that can never be removed? I'm truly at a loss here, this is for my senior thesis project.

Hi, I am getting this crash specific to iOS 18.4. This has happened only on iPad, combined with 18.4. I do not what is causing the crash. I am unable to reproduce the crash. Crash report attached at the bottom of the post. Thank you. first.crash second.crash

Hi All, I have an App on AppStore, recently the minimum supported version of the app was changed from iOS 12 to iOS 14. Post that the TestFlight builds are crashing on launch. If we revert the minimum supported iOS version to 12, the crash no longer happens. This project is using cocoapods, and from the crash logs it seems the issue with with PLCrashReporter framework. "EXC_CRASH" Termination reason: DYLD 9 weak-def symbol not found '__ZN7plcrash3PL_5async15dwarf_cfa_stateljiE10push_stateEv'. This issue is happening only on TestFlight builds where the minimum supported version is 14.0 Any pointer to a solution is welcome.

This is an issue that occurred while using SwiftUI. Cannot find '$state' in scope The other view finds properties normally. May I know why the error is occurring? The following code is the full text of the code that causes problems. import SwiftUI @Observable class HomeState { var title: String = "Home" } struct HomeView: View { @Binding var state: HomeState var body: some View { Text(state.title) } } #Preview { @Previewable @State var state: HomeState = .init() HomeView(state: $state) /// Error: Cannot find '$state' in scope } The same error occurs when using the String type rather than the object. What did I do wrong?

I received the attached crash report. The problem is that the crash report does not contain the abort reason - it appears to be thrown in the GCD library with no additional information. Is it a possible deadlock? 2023-02-15_02-40-23.0077_+0100-94015bd052c4005658221a5e6279f28a75b9e92c.crash Any ideas?

Hi! My SwiftUI app is a rather complex browser app. Starting with iOS 18, the app crashes due to repeted reloads of the WkWebView. I’ve tracked the issue as far as I can, but I still haven’t found the root cause. My app is structured like this: MainView holds a cuple of subviews. It also holds a @StateObject called viewModel that holds a lot of @Published vars. The viewModel is passed as a enivormentObject. Example from ViewModel: @MainActor class ViewModel: NSObject, ObservableObject { @Published public var isLoading: Bool = false @Published public var loadProgress: Double? = 0 public func setIsLoading(_ value: Bool) async { self.isLoading = value } public func setLoadProgress(_ value: Double?) async { self.loadProgress = value } } WebView is a subview of MainView, which holds a navigation bar, and a UIViewRepresentable, which is a WkWebView. The WkWebView pushes some states to the ViewModel as the underlying values of the WkWebView changes, i.e. estimaedProgress, and isLoading. This is done via KVO and works like this: estimatedProgressObservation = self.parent.webView.observe(\.estimatedProgress) { webView, progress in Task { await parent.viewModel.setLoadProgress(webView.estimatedProgress) } } isLoadingObservation = self.parent.webView.observe(\.isLoading) { webView, value in Task { await parent.viewModel.setIsLoading(webView.isLoading) } } By using a timer in WkWebViews Coordinator, i trigger a load after a configurable amount of time :
 func loadUrl(url: URL) { DispatchQueue.main.async { console.info("Load URL: ...", sensitive: "Load URL: \(url.absoluteString)") let policy: NSURLRequest.CachePolicy if self.parent.settings.noCache { policy = .reloadIgnoringLocalAndRemoteCacheData } else { policy = .useProtocolCachePolicy } let request = URLRequest(url: url, cachePolicy: policy) self.parent.webView.load(request) } } Running the app with the automatic reload enabled freezes the app after a couple of hours. It also seems to freeze Safari on the device. The device needs to be rebooted. If I inspect the device's running processes, hundreds of ”com.apple.webkit. web content " processes are running. Removing await parent.viewModel.setLoadProgress(webView.estimatedProgress) and await parent.viewModel.setIsLoading(webView.isLoading) fixes the issue, but it is necessary for other app functions. Therefore, is suspect that the viewModel somehow causes the bug. The issue arises after a couple of loads 5-10. The debugger shows a message when the processes start to pile up. I suspect its related. Failed to terminate process: Error Domain=com.apple.extensionKit.errorDomain Code=18 "(null)" UserInfo={NSUnderlyingError=0x12d0e7f60 {Error Domain=RBSServiceErrorDomain Code=1 "Client not entitled" UserInfo={RBSEntitlement=com.apple.runningboard.terminateprocess, NSLocalizedFailureReason=Client not entitled, RBSPermanent=true}}} How can I find out what causes the suspected memory leak? Instruments gives me nothing of value. The memory leak wasn't present in iOS 17. Is this a bug in iOS 18, or was something intentionally changed?

Hello! We're working on a large app with over 400 modules in both Swift and Objective-C, totaling more than 3 million lines of code. Since the release of Xcode 15 and 16 this summer, we’ve been experiencing issues with LLDB that have made debugging practically impossible. Here are some of the problems we’re facing: The first breakpoint takes a very long time to hit. When using 'po self', we encounter the following error: error: type for self cannot be reconstructed: type for typename "$s5MyModule10PlayerViewCD" was not found (cached) error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work. We get numerous log messages like this: Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.warning: (arm64) /Users/egormerkushev/Library/Developer/Xcode/DerivedData/App-enhtbwiyebmjsffoqkqhhpshsfia/Build/Products/Debug-iphoneos/MyModule.framework/MyModule(UploadConfiguration.o) 0x000000000000079d: unable to locate module needed for external types: /Users/builder/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/169D1N0MIKBUI/Security-3BRN4UPIIGHME.pcm error: '/Users/builder/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/169D1N0MIKBUI/Security-3BRN4UPIIGHME.pcm' does not exist In the Derived Data folder, we find files with hash-like names, such as: Security-3JM2E93YFDLZNYHWPPIMWNENB.d Security-3JM2E93YFDLZNYHWPPIMWNENB.dia Security-3JM2E93YFDLZNYHWPPIMWNENB.pcm Security-3JM2E93YFDLZNYHWPPIMWNENB.scan Security-3NAAT3MGN7XY96KVJW529HR41.d Security-3NAAT3MGN7XY96KVJW529HR41.dia Security-3NAAT3MGN7XY96KVJW529HR41.pcm Security-3NAAT3MGN7XY96KVJW529HR41.scan Security-3RJH8STJC01N1KKN7JCY1WK7F.d Security-3RJH8STJC01N1KKN7JCY1WK7F.dia Security-3RJH8STJC01N1KKN7JCY1WK7F.pcm Security-3RJH8STJC01N1KKN7JCY1WK7F.scan Security-3TILE9XTY0B8UV9VYL7Y0MJN.d Security-3TILE9XTY0B8UV9VYL7Y0MJN.dia Security-3TILE9XTY0B8UV9VYL7Y0MJN.pcm Security-3TILE9XTY0B8UV9VYL7Y0MJN.scan Security-3ZE8O6ZPHE4L52UZGL0PCBA59.d Security-3ZE8O6ZPHE4L52UZGL0PCBA59.dia ... When enabling LLDB logs with: log enable -f /tmp/lldb.log lldb all we end up with a 1.5GB log file containing hundreds of thousands of error messages. Finally, the LLDB console output in Xcode ends with errors like: error: Assertion failed: (byte_size > 0 && byte_size <= 8 && "GetMaxU64 invalid byte_size!"), function GetMaxU64, file DataExtractor.cpp, line 527 Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 LLDB 0x0000000116ccfe1c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56 1 LLDB 0x000000011682fdcc lldb_private::lldb_assert(bool, char const*, char const*, char const*, unsigned int) + 148 2 LLDB 0x000000011682944c lldb_private::DataExtractor::GetMaxU64(unsigned long long*, unsigned long) const + 72 3 LLDB 0x00000001167335a8 lldb_private::CompilerType::GetValueAsScalar(lldb_private::DataExtractor const&, unsigned long long, unsigned long, lldb_private::Scalar&, lldb_private::ExecutionContextScope*) const + 304 4 LLDB 0x000000011666f0f4 lldb_private::Value::ResolveValue(lldb_private::ExecutionContext*, lldb_private::Module*) + 388 5 LLDB 0x0000000116671e94 lldb_private::ValueObject::ResolveValue(lldb_private::Scalar&) + 104 6 LLDB 0x0000000116674d6c lldb_private::ValueObject::GetValueAsSigned(long long, bool*) + 140 7 LLDB 0x000000011650510c lldb::SBValue::GetValueAsSigned(long long) + 160 8 lldb-rpc-server 0x00000001025ebe70 rpc_server::_ZN4lldb7SBValue16GetValueAsSignedEx::HandleRPCCall(rpc_common::Connection&, rpc_common::RPCStream&, rpc_common::RPCStream&) + 92 ... 13 libsystem_pthread.dylib 0x00000001917fb2e4 _pthread_start + 136 14 libsystem_pthread.dylib 0x00000001917f60fc thread_start + 8 Please file a bug report against lldb reporting this failure log, and as many details as possibleerror: Assertion failed: (byte_size > 0 && byte_size <= 8 && "GetMaxU64 invalid byte_size!"), function GetMaxU64, file DataExtractor.cpp, line 527 Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 LLDB 0x0000000116ccfe1c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56 1 LLDB 0x000000011682fdcc lldb_private::lldb_assert(bool, char const*, char const*, char const*, unsigned int) + 148 2 LLDB 0x000000011682944c lldb_private::DataExtractor::GetMaxU64(unsigned long long*, unsigned long) const + 72 3 LLDB 0x00000001167335a8 lldb_private::CompilerType::GetValueAsScalar(lldb_private::DataExtractor const&, unsigned long long, unsigned long, lldb_private::Scalar&, lldb_private::ExecutionContextScope*) const + 304 4 LLDB 0x000000011666f0f4 lldb_private::Value::ResolveValue(lldb_private::ExecutionContext*, lldb_private::Module*) + 388 5 LLDB 0x0000000116671e94 lldb_private::ValueObject::ResolveValue(lldb_private::Scalar&) + 104 6 LLDB 0x0000000116674c44 lldb_private::ValueObject::GetValueAsUnsigned(unsigned long long, bool*) + 140 7 LLDB 0x0000000116505224 lldb::SBValue::GetValueAsUnsigned(unsigned long long) + 160 8 lldb-rpc-server 0x00000001025ebf18 rpc_server::_ZN4lldb7SBValue18GetValueAsUnsignedEy::HandleRPCCall(rpc_common::Connection&, rpc_common::RPCStream&, rpc_common::RPCStream&) + 92 9 lldb-rpc-server 0x00000001025f62b8 rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, rpc_common::RPCPacket&, bool&) + 628 10 lldb-rpc-server 0x00000001025f9e8c Packets::ProcessPackets() + 564 11 lldb-rpc-server 0x00000001025f9bf4 Packets::ReadThread() + 276 12 lldb-rpc-server 0x00000001025f9ad4 Packets::RunReadThread(void*) + 12 13 libsystem_pthread.dylib 0x00000001917fb2e4 _pthread_start + 136 14 libsystem_pthread.dylib 0x00000001917f60fc thread_start + 8 Please file a bug report against lldb reporting this failure log, and as many details as possiblePrinting description of self: error: type for self cannot be reconstructed: type for typename "$s5MyModule10PlayerViewCD" was not found (cached) error: Couldn't realize Swift AST type of self. Hint: using `v` to directly inspect variables and fields may still work. In short, our debugger is completely unusable at this point, which is severely impacting our team's ability to develop effectively. Do you have any suggestions on how we can resolve these issues? We would really appreciate your help. Thank you!

We found there is a significant crash reports (most of them are from iOS 17, the rest are iOS 16 and 15) comes from network loader from CFNetwork. Apparently it seems there are two types of crashes if we checked from the stack trace, the one we found from both Xcode organizer and 3rd party crash reporter is referring to URLConnectionLoader::loadWithWhatToDo and the other one from our 3rd party crash reporter (didn’t found the report from Xcode organizer) referring to _CFURLResponseCreateFromArchiveList (this one only happened on iOS 17.5 and later devices). It seems that they are both kinda similar which might point to the same root cause. From what I’ve seen, we never touch the lower level API directly, we usually use the URLSession to manage our API request. The crashed stack trace also didn’t give any indication about which of our app code that triggered the crash, it only shows calls to Apple’s internal SDKs so we are unsure how to approach this issue meanwhile the crash event already reached 800+ in the last 30 days. Unfortunately, we cannot reproduce the issue as the stack trace itself seems unclear to us. I have submitted a report through feedback assistant with number: FB14679252. Would appreciate if anyone can give any advice on what we can do to avoid this in the future and probably any hint on why it could happened. Hereby I attached the crash reports that we found each from Xcode crash report and our 3rd party crash reporter (the report said it crashed on com.apple.CFNetwork.LoaderQ) so you could get a glimpse of the similarity. Xcode crash report xcode crash report.crash 3rd party crash report 3rd party crash report.txt

Hello! After upgrading to Xcode 16 & Swift 6 & iOS 18 I starting receiveing strange crashes. Happens randomly in different view and pointing to onGeometryChange action block. I added DispatchQueue.main.async { in hopes it will help but it didn't. HStack { ... } .onGeometryChange(for: CGSize.self, of: \.size) { value in DispatchQueue.main.async { self.width = value.width self.height = value.height } } As far as I understand, onGeometryChange is defined as nonisolated and Swift 6 enforce thread checking for the closures, SwiftUI views are always run on the main thread. Does it mean we can not use onGeometryChange safely in swiftui? BUG IN CLIENT OF LIBDISPATCH: Assertion failed: Block was expected to execute on queue [com.apple.main-thread (0x1eacdce40)] Crashed: com.apple.SwiftUI.AsyncRenderer 0 libdispatch.dylib 0x64d8 _dispatch_assert_queue_fail + 120 1 libdispatch.dylib 0x6460 _dispatch_assert_queue_fail + 194 2 libswift_Concurrency.dylib 0x62b58 <redacted> + 284 3 Grit 0x3a57cc specialized implicit closure #1 in closure #1 in PurchaseModalOld.body.getter + 4377696204 (<compiler-generated>:4377696204) 4 SwiftUI 0x5841e0 <redacted> + 60 5 SwiftUI 0x5837f8 <redacted> + 20 6 SwiftUI 0x586b5c <redacted> + 84 7 SwiftUICore 0x68846c <redacted> + 48 8 SwiftUICore 0x686dd4 <redacted> + 16 9 SwiftUICore 0x6ecc74 <redacted> + 160 10 SwiftUICore 0x686224 <redacted> + 872 11 SwiftUICore 0x685e24 $s14AttributeGraph12StatefulRuleP7SwiftUIE15withObservation2doqd__qd__yKXE_tKlF + 72 12 SwiftUI 0x95450 <redacted> + 1392 13 SwiftUI 0x7e438 <redacted> + 32 14 AttributeGraph 0x952c AG::Graph::UpdateStack::update() + 540 15 AttributeGraph 0x90f0 AG::Graph::update_attribute(AG::data::ptr<AG::Node>, unsigned int) + 424 16 AttributeGraph 0x8cc4 AG::Subgraph::update(unsigned int) + 848 17 SwiftUICore 0x9eda58 <redacted> + 348 18 SwiftUICore 0x9edf70 <redacted> + 36 19 AttributeGraph 0x148c0 AGGraphWithMainThreadHandler + 60 20 SwiftUICore 0x9e7834 $s7SwiftUI9ViewGraphC18updateOutputsAsync2atAA11DisplayListV4list_AG7VersionV7versiontSgAA4TimeV_tF + 560 21 SwiftUICore 0x9e0fc0 $s7SwiftUI16ViewRendererHostPAAE11renderAsync8interval15targetTimestampAA4TimeVSgSd_AItF + 524 22 SwiftUI 0xecfdfc <redacted> + 220 23 SwiftUI 0x55c84 <redacted> + 312 24 SwiftUI 0x55b20 <redacted> + 60 25 QuartzCore 0xc7078 <redacted> + 48 26 QuartzCore 0xc52b4 <redacted> + 884 27 QuartzCore 0xc5cb4 <redacted> + 456 28 CoreFoundation 0x555dc <redacted> + 176 29 CoreFoundation 0x55518 <redacted> + 60 30 CoreFoundation 0x55438 <redacted> + 524 31 CoreFoundation 0x54284 <redacted> + 2248 32 CoreFoundation 0x535b8 CFRunLoopRunSpecific + 572 33 Foundation 0xb6f00 <redacted> + 212 34 Foundation 0xb6dd4 <redacted> + 64 35 SwiftUI 0x38bc80 <redacted> + 792 36 SwiftUI 0x1395d0 <redacted> + 72 37 Foundation 0xc8058 <redacted> + 724 38 libsystem_pthread.dylib 0x637c _pthread_start + 136 39 libsystem_pthread.dylib 0x1494 thread_start + 8

Hi, From App analytics, we found that our app crashed from time to time on users' devices despite that we have tested it thoroughly on our devices. We are doubt that it's the reason why we can't retain them. But how can we get the crash reports for the app installed on user devices? We have no users' emails and can't ask them directly.