Doing it in ViewDidLoad is the issue, I think. You might not be guaranteed to have full access to UI elements that haven't fully entered a state of quiescence after (or still during if threaded...?) drawing and initializing. Wrap it in a timer or an asyncAfter call. Also, if you do it throughout your application, consider always dispatching that call to the main thread

I was hoping by now they'd have opened up the DTK to allow some iOS builds, too. :( Kinda feeling like I tossed $500 out the window as it's so limited (ongoing). I'd really figured the MacOS dev-only situation would be very short term, especially as they're SOOOOOOOO close to formally announcing the Apple Silicon Macs. :\

I think this DTK was rushed out by apple to help drum up excitement for the Apple Silicon announcement, and I put a lot of (misplaced) faith in the notion that the MacOS build-only limits would be lifted pretty quickly in updates. (( siiiiiigh )) Ah well.

FWIW, I took my DTK out of the desk drawer today after 6-8 weeks of ignoring it because Xcode was broken with all this same crap. For the first time since getting it, I got the alert to upgrade the OS (Finally!!!), ran through the install, and now Xcode seems to be working. The irony was I was only hooking it up to remove my user profile and send this well running, but entirely useless doorstop back to them with a note saying "thanks for wasting my $500 with this broken-*** software" (more nicely worded than that. maybe. probably.) Maybe I'll hang onto it a little longer now to play with it... Maybe. Literally zero of the options in this and about 100 other threads on the topic (or even tangentially related to the topic) had any effect at all. :\ This is probably the worst beta I've ever participated in. :( And I've been doing this crap for 30+ years.

Ok, I'm impressed. After this update, two force-quit of crashed Xcode startups, and a full power-off restart, my DTK is now fully operational, and it seems to have remove the limitation on building iOS apps, too. So I guess I'll keep using it a while longer. I do love the way it runs. I guess the threats of sending it back with a nastygram worked ;)

I'm getting this too trying to implement a UIViewControllerRepresentable wrapping around image picker. I had my own class / struct for that initially, but figured I messed something up, so I went and snagged a couple of examples from the 'net with the same results. I'm running Xcode 12.4 on Bit Sur 11.2.1 on an M1 mini. I thought I'd do this latest project in SwiftUI, but once again, I'm just feeling like it's not ready for prime time, and this is a show stopper for me; I'm ready to trash it and start over in .XIBs because I've done this same thing 100 times in .XIBs and storyboard with 100% no issues. I even stripped out all the view controller stuff in my ControllerReprestable and just went with a wrapping of a very generic UIViewController.

Try explicitly setting "content-available" to 1 (integer) (as noted by many others), leave out the alert key, AND the sound entry to an empty string. That made the difference for me, after a rather exhaustive diagnostic session. I was omitting the sound entry and it never worked. I tried setting a sound file name and it never worked. Setting it to an empty string ( "" ) worked fine when accompanied by content-available and omitting the alert key. Printing what I receive (as seen below with my various diagnostic print statements) showed: ["sound": , "content-available": 1, "badge": 0]         guard let aps = userInfo["aps"] as? [String: AnyObject] else {             print( "Incoming failed" )             completionHandler(.failed)             return         }         print( aps )         print( "INCOMING" )

I'm able to read the environment object variable just fine, but writing to it triggers a dismiss of the current view. I'm beating my head against the wall on that.