The suggested workaround is not really a true workaround, because although it does provide the user with a (somewhat obscure) way to dismiss the mail compose view controller, it doesn't get the little dialog asking the user whether to save the draft.

I finally got tired of the iOS 18.6 runtime in /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime refusing to die, and went ahead and killed it as already described above: Shut down. Start up into recovery. In the Terminal in recovery, say csrutil disable to turn off SIP. Restart. In the normal Mac interface, in the Terminal, cd into /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime and delete (using sudo rm -rf) any .asset folder that is no longer desired. Shut down. Start up into recovery. In the Terminal in recovery, say csrutil enable to turn on SIP. Restart. I'm not seeing any negative effects.

@Frameworks Engineer The issue with SKTestSession is not fixed in iOS 26.6. I have reported the problem in a feedback (FB22836426). In my unit tests, I test the product purchase with a StoreKit Configuration. My test begins by creating a testing session: @Test func testPurchase() async throws { let session = try SKTestSession(configurationFileNamed: "StoreKitConfiguration") session.disableDialogs = true session.clearTransactions() The test then runs my app's code that performs the purchase: let result = try await product.purchase(confirmIn: scene) At that moment, the user purchase dialog appears and the test hangs, waiting for the user to perform the purchase. That is wrong. I said disableDialogs = true; the user dialogs are exactly what is NOT supposed to happen!

Same thing here; Xcode doesn't see some of the previously downloaded sim runtimes. Also when launching Xcode it's kind of random whether it will see the sim runtimes I do have installed. Whatever the mechanism is for maintaining these things, it's pretty fragile.

The workaround is to download and use the 26.2 simulator for testing. — This ongoing issue is really a pity, because Apple claimed that this would be fixed in Xcode 26.5.

My app is a game whose board layout can make no sense in portrait orientation. I'm willing to make the window resizeable, within limits, but it absolutely must remain in landscape orientation. How am I, and the thousands of developers like me, supposed to cope?

The trouble here, if I may say so, is that Apple has not sufficiently thought this through. There are some apps, perhaps many apps, perhaps very many apps, that rely on a fixed aspect ratio. (Games are the obvious example.) Once established at launch, i.e. by the screen aspect ratio, the window's aspect ratio absolutely needs to remain the same; the app interface cannot make any sense in any other ratio. This is exactly what UIRequiresFullScreen allows us to enforce. With it, my apps do not compel the app to fill the screen on iOS 26, but they do compel the app to maintain the screen's aspect ratio. If Apple wants to take this flag away, they need to provide some other mechanism that does the same job.

Okay, I've worked out workarounds for both problems; see https://stackoverflow.com/a/79921602/341994

"And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance" That part is what I came here to complain about. (The system colors being different in a popover does not seem to me to be a bug, because a popover is "elevated" so the colors are different.)

Just to be clear, this has nothing to do with NSStatusItem or LSUIElement. Simply make a new Mac project in Xcode, in Swift, with Storyboard. Run it. You will see the console fill with these warnings.

If you don't want the overflow menu, set the navigation item's style as .browser.

I'm having the exact same issue. I complained about this when this requirement was first promulgated, and here it is happening again. I do not have a new version of any of my apps to submit at this time; does this mean that I cannot update my age ratings now, and that therefore I will never be allowed to update any of my apps ever again??? What in the blue-eyed tunket is going on here????

Sorry for the noise — it turns out that the task ID must begin with the app's bundle ID exactly.

Sorry to barge in on this thread, but I am completely unable to get BGContinuedProcessingTask to work in a UIKit app (the task never starts, the heads-up progress never appears), even though the very same code in a SwiftUI app works just fine. Is this by design? It wasn't mentioned in the video.

I have sent a complaint about this to Apple. The email and the App Store Connect banners specifically say that action is required now, but the new questions, though visible, are not editable so no answers can be provided.