Still having this problem in Xcode 13.4.1. What the heck

You must be a teacher with your own opinions already cemented. The documentation is very clear and provides examples. Stop fighting the system and follow the examples, perform actual test, and assess the results instead of fighting those providing the answers to your somewhat rant list of questions. As some will say, Read The ******* Manual. Look, I am just asking these simple questions: What exactly is "focus"? What isn't focus? What is the relationship between FocusState and accessibility focus? What is the relationship between whether a SecureField is being edited, and whether it's "focused"? If you know the answer, even if you're just copy-pasting it from somewhere else, please leave it as a response to this post, and if it's correct then I'll mark it correct. But please don't just reply and accuse me of being a teacher, because (a) I'm not a teacher, and (b) the documentation does not define what focus means, exactly, or whether it always directly corresponds with what's being edited, or not. I'm not fighting any systems; I just want to know the answer to these simple questions. Performing tests on devices or simulators won't tell me how it's supposed to work. Thanks.

Note: I did find this discussion of the five "focusable states" in tvOS but this doesn't tell me which of these states "isBeingEdited" (if it existed for SecureField, which it doesn't) should correspond to if we're talking about iOS instead of tvOS. https://developer.apple.com/design/human-interface-guidelines/tvos/app-architecture/focus-and-selection/

@Frameworks Engineer wrote: If the system medium detent isn't sufficient for your use case, you may need to continue to use your own card/sheet implementation. < < < Problem is, the .sheet modifier doesn't give you the medium detent. It only gives the large detent. (Always covers the whole screen.) Apple... if you're listening... please add more flexibility to these SwiftUI APIs. Like... why are you adding functionality that's only available to UIKit? Are you deliberately trying to make adoption go as slow as possible while we reinvent every wheel?

@EA7K All we can do is file FB tickets and pester our WWDR reps about them if they don't get addressed. The squeaky wheel gets grease.

Also see this in the logs: -CMSessionMgr- CMSessionMgrHandleApplicationStateChange: Sending EndInterruption to com.REDACTED.REDACTED with pid '49,178' because client moved to ForegroundRunning and is not allowed to play in the background. Could this be related? I googled "because client moved to ForegroundRunning and is not allowed to play in the background" and see some similar crash reports from people indicating an intermittent, device-only crash that only affects certain users, such as this post.

Ever find a solution

I notice in the os_log instrument that, on MDM installs on iOS 14 from the App Store, we see three missed SYSPROTO_EVENT event, buffer not big enough from UserEventAgent subsystem com.apple.MemoryMonitor on _pthread_start thread just before we get the _dyld_process_info_create failed message. @eskimo or anyone else, do you know what this means?

On iOS 15, when our app runs we see: AMFI: constraint violation /private/var/containers/Bundle/Application/272392ED-BF0A-48A0-8FB1-4FB707B234A0/REDACTED.app/Frameworks/SwiftProtobuf.framework/SwiftProtobuf has entitlements but is not a main binary for all our .frameworks. I checked and all our .frameworks have an empty plist as their entitlements, even though none of them specify an entitlements plist in anywhere in Xcode. Pray tell why these empty plists are being added Eskimo? And also, why does it trigger a violation in AMFI?

Nevermind, it has nothing to do with the hypothesized infinite loop that I mentioned in the prior post. We ruled it out by disabling our MDM code on first launch and adding a bunch of os_log calls at the start of the app. None of the os_log calls get called, meaning AppDelegate never gets initialized. So we're back to square one trying to figure out this mystery.

Upon further investigation I noticed a Jetsam event around this crash implicating the app's process in being terminated due to using too much memory (2GB!) (see report below). Using up all the memory could only be possible if we have an infinite loop, and I also found several similar crash reports, with EXC_BAD_ACCESS and KERN_INVALID_ADDRESS or KERN_PROTECTION_FAILURE with Segmentation Fault 11 and Code 0xb, that indicate this could be caused by an infinite loop. So, what could cause an infinite loop, but only for MDM installs? I found another thread on this forum (link here) where someone had incurred an infinite loop due to following this code example from WWDC 2013 (link here) where an MDM manager class sets up an observer on NSUserDefaultsDidChangeNotification. Their infinite loop was due to someone putting a write call to UserDefaults in the target method of that observer. >.< So I checked and, sure enough, we have a write call to UserDefaults in the target method of the observer on NSUserDefaultsDidChangeNotification in our MDM manager. It was wrapped with an ivar to prevent the recursion, but it was not a perfect solution obviously. Something about how our iOS 14 build is optimized or the timing of when the method gets called on those builds triggers the recursion, which doesn't happen in iOS 15. In any event... the fix would be to not write to UserDefaults in that method if the change we want to make in UserDefaults already exists. So we're trying that, will reply here if it worked. { "uuid" : "1b20964b-84fa-329a-b8d0-7ad5df6f42ce", "states" : [ "frontmost" ], "killDelta" : 5005, "genCount" : 0, "age" : 73179629, "purgeable" : 0, "fds" : 50, "coalition" : 1975, "rpages" : 196608, "priority" : 10, "reason" : "per-process-limit", "physicalPages" : { "internal" : [ 135870, 60638 ] }, "pid" : 21668, "cpuTime" : 1.3859840000000001, "name" : "REDACTED", "lifetimeMax" : 196608 },

Update: After turning on App Analytics, this crash still isn't syncing up to Xcode's backend. That makes me think it's a watchdog process termination. As well, the .000.ips info of the crash adds the following: _dyld_process_info_create failed with 6 What does this mean? Why would this happen only when the app is installed via MDM, and only on iOS 14?

We usually see this error when launching tests, where the test bundle has a Mach-O type of "Bundle" as it should.

We fixed these issues by adding most of the Xcode executables into the exceptions list of Developer Tools in Security & Privacy system preferences.

There is another trick you can use. First you make a dummy class that conforms to UIWindowSceneDelegate: swift open class MyWindowSceneDelegate: NSObject &amp; UIWindowSceneDelegate {} Since all the requirements of UIWindowSceneDelegate are optional, the compiler will be happy. Afterwards you can do this: swift open class MyRealWindowSceneDelegate: MyWindowSceneDelegate { @objc var window: MyCustomUIWindowSubclass } At runtime when window is resolved, it will be of type MyCustomUIWindowSubclass.