I've been getting occasional crash reports that look similar to this:Fatal Exception: NSInternalInconsistencyException Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread. Fatal Exception: NSInternalInconsistencyException 0 CoreFoundation 0x19dcd0a48 __exceptionPreprocess 1 libobjc.A.dylib 0x19d9f7fa4 objc_exception_throw 2 Foundation 0x19e1a6f08 -[NSISEngine tryToOptimizeReturningMutuallyExclusiveConstraints] 3 Foundation 0x19dfa803c -[NSISEngine withBehaviors:performModifications:] 4 UIKitCore 0x1a20ff8e8 -[UIView(UIConstraintBasedLayout) _resetLayoutEngineHostConstraints] 5 UIKitCore 0x1a21d9314 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] 6 QuartzCore 0x1a473c7dc -[CALayer layoutSublayers] 7 QuartzCore 0x1a4742958 CA::Layer::layout_if_needed(CA::Transaction*) 8 QuartzCore 0x1a474d578 CA::Layer::layout_and_display_if_needed(CA::Transaction*) 9 QuartzCore 0x1a4695f1c CA::Context::commit_transaction(CA::Transaction*, double) 10 QuartzCore 0x1a46bfc08 CA::Transaction::commit() 11 QuartzCore 0x1a46c0b8c CA::Transaction::release_thread(void*) 12 libsystem_pthread.dylib 0x19d9eefb0 _pthread_tsd_cleanup 13 libsystem_pthread.dylib 0x19d9ebde8 _pthread_exit 14 libsystem_pthread.dylib 0x19d9ece7c _pthread_wqthread_legacy_worker_wrap 15 libsystem_pthread.dylib 0x19d9ecc18 _pthread_wqthread 16 libsystem_pthread.dylib 0x19d9ef760 start_wqthreadThis is not being invoked by my code (at least directly). I've been running the app in the debugger with the Main Thread Checker enabled and have yet to catch whatever is causing this.I've found multiple reports from others who have been experiencing similar issues, most commonly on iOS 13. (My app only supports 13 and later.) I have yet to see any solid explanation. @Eskimo - is it possible that iOS is invoking something that results in a UI state change which is called from a background thread?Thanks,-S

I'm testing out an app that will be using the DeviceCheck framwork / API to enable a one-time free trial. I'm testing using the deveopment URL provided in the documentation (https://api.development.devicecheck.apple.com). I had set the bits for one of my test iOS devices several days ago. Today when I went to do some additional testing the query_two_bits response came back with "200 Bit State Not Found" - what the API apparently returns for a device that has never had the DeviceCheck value set. I tried it several times before I executed another update_two_bits call, which succeeded. Subsequent calls to the query endpoint returned 200 OK and the expected bit values.It's probably worth mentioning that the unexpected behavior happened after I had deleted and re-installed the app. The app's bundle ID did not changed, but I did enable Push Notifications yesterday.My question is: is the development version of DeviceCheck less "permanent" than the production version (i.e. does everything get deleted after X days)?Or, unlike in the production environment, does deleting and reinstalling the app change something that causes DeviceCheck to not recognize the device by subsequently generated DC tokens?Or does making a change to the app's configuration in AppStoreConnect (i.e. enabling Push) make some change that causes DeviceCheck to not recognize the device by subsequently generated DC tokens?Or is it most likely that something has broken in my environment or code?Thanks -S

After upgrading my build environment to Xcode 12 and iOS 14 my application has begun crashing with the following error: 2020-09-22 13:49:14.896138-0500 FlightBox PFD[3347:2884020] This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.  Stack:( 0   CoreAutoLayout                      0x00007fff58010c53 _AssertAutoLayoutOnAllowedThreadsOnly + 190 1   CoreAutoLayout                      0x00007fff58010fcd -[NSISEngine withBehaviors:performModifications:] + 25 2   UIKitCore                           0x00007fff24ab9bdc -[UIView(UIConstraintBasedLayout) _resetLayoutEngineHostConstraints] + 70 3   UIKitCore                           0x00007fff24bbd92f -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2715 4   QuartzCore                          0x00007fff27a3dd87 -[CALayer layoutSublayers] + 258 5   QuartzCore                          0x00007fff27a44239 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 575 6   QuartzCore                          0x00007fff27a4ff91 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 65 7   QuartzCore                          0x00007fff27990078 _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 496 8   QuartzCore                          0x00007fff279c6e13 _ZN2CA11Transaction6commitEv + 783 9   QuartzCore                          0x00007fff279c7616 _ZN2CA11Transaction14release_threadEPv + 210 10  libsystem_pthread.dylib             0x00007fff5dcda054 _pthread_tsd_cleanup + 551 11  libsystem_pthread.dylib             0x00007fff5dcdc512 _pthread_exit + 70 12  libsystem_pthread.dylib             0x00007fff5dcd9ddd _pthread_wqthread_exit + 77 13  libsystem_pthread.dylib             0x00007fff5dcd8afc _pthread_wqthread + 481 14  libsystem_pthread.dylib             0x00007fff5dcd7b77 start_wqthread + 15 ) 2020-09-22 13:49:14.898322-0500 FlightBox PFD[3347:2884020] * Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.' First throw call stack: ( 0   CoreFoundation                      0x00007fff2043a126 __exceptionPreprocess + 242 1   libobjc.A.dylib                     0x00007fff20177f78 objc_exception_throw + 48 2   CoreAutoLayout                      0x00007fff58010d41 -[NSISEngine tryToOptimizeReturningMutuallyExclusiveConstraints] + 0 3   CoreAutoLayout                      0x00007fff58010fcd -[NSISEngine withBehaviors:performModifications:] + 25 4   UIKitCore                           0x00007fff24ab9bdc -[UIView(UIConstraintBasedLayout) _resetLayoutEngineHostConstraints] + 70 5   UIKitCore                           0x00007fff24bbd92f -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2715 6   QuartzCore                          0x00007fff27a3dd87 -[CALayer layoutSublayers] + 258 7   QuartzCore                          0x00007fff27a44239 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 575 8   QuartzCore                          0x00007fff27a4ff91 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 65 9   QuartzCore                          0x00007fff27990078 _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 496 10  QuartzCore                          0x00007fff279c6e13 _ZN2CA11Transaction6commitEv + 783 11  QuartzCore                          0x00007fff279c7616 _ZN2CA11Transaction14release_threadEPv + 210 12  libsystem_pthread.dylib             0x00007fff5dcda054 _pthread_tsd_cleanup + 551 13  libsystem_pthread.dylib             0x00007fff5dcdc512 _pthread_exit + 70 14  libsystem_pthread.dylib             0x00007fff5dcd9ddd _pthread_wqthread_exit + 77 15  libsystem_pthread.dylib             0x00007fff5dcd8afc _pthread_wqthread + 481 16  libsystem_pthread.dylib             0x00007fff5dcd7b77 start_wqthread + 15 ) Normally this kind of thing can be tracked down by enabling the Main Thread Checker, but it does not appear to be working in this one case. I've enabled it and verified that the breakpoint it creates is active, but when the background thread does its thing the breakpoint is not called - the app simply crashes with the ever so useless: libc++abi.dylib: terminating with uncaught exception of type NSException I'm frankly not sure what is creating this background thread - it does not appear to be associated with a queue. I'm not using any low-level APIs that would create a thread on my own, so I assume it's being executed by one of the libraries I'm using (or by one of the core iOS libs). I'm going to start doing the usual things: disconnecting various bits of the app to see if I can get the crash to stop. If anyone knows how to get the Main Thread Checker to catch this, or might know what's going on here, please let me know. The app has been working fine for months when build on Xcode 11 and run on iOS 13.

Working on a new app built in xcode 11.2 for iOS 13.x. The app is a single-view storyboard app, but like all apps created under 11, it defaults to using the scene delegate for lifecycle events.The app exports a custom file type and registers as owner of that type. When the app is in the background it is automatically brought to the foreground when a file of the custom type is accessed in the Files app, delivered to the device over AirDrop, opene from Mail, etc. This happens by calling the scene delegate's openURLContainers method:func scene(_ scene: UIScene, openURLContexts URLContexts: Set) { // handle URLs here... // This works when the app is already in memory // but is never called if the app is launched from cold/dark }However, when the app is not resident in memory (i.e. following a restart or after the app has been killed) the expected behavior does not occur. The app is launched, but the opeURLContexts method is never called.I thought that perhaps in this situation the legacy process in appDelegate would be called (i.e. a LauchOptionsKey of type .url in the launchOptions dictionary). That does not appear to be the case either. The launchOptions dictionary is always nil.Is this a bug, or is there some other way to catch the URL for the file in this new scene-based world?