The below provides a quick and simple solution:
private struct _ShowsWidgetContainerBackground: EnvironmentKey {
static let defaultValue: Bool = true
}
extension EnvironmentValues {
var showsWidgetContainerBackgroundWithFallback: Bool {
get {
if #available(iOSApplicationExtension 17.0, *) {
self.showsWidgetContainerBackground
} else {
self[_ShowsWidgetContainerBackground.self]
}
}
set {}
}
}
You can use the new environment key showsWidgetContainerBackgroundWithFallback in place of showsWidgetContainerBackground.
Post not yet marked as solved
I've noticed that even after quitting Xcode 13 and simulators, the battery drain is still there (M1 Max 2021). I'm not just closing windows - I'm quitting the applications completely.
It's most noticeable while my MacBook sleeps: the battery consistently loses 2% or so per hour. Not a big deal for a couple of hours, but if I leave my MacBook sleeping for 2 or 3 days, I come back to find the battery almost dead. This is very consistently reproducible. If I open Activity Monitor, the '12 hr battery drain' records show that Xcode was indeed the main culprit, despite the fact it was no longer running.
Also reproducible: if I cold start my MacBook, and don't open Xcode, sleeping will drain almost no battery, even over longer timespans. Although it might seem odd that the battery drain persists after quitting, it's pretty clearly Xcode that is at fault.
Post not yet marked as solved
Spent some more time digging - I went as far as disassembling UIKitCore to see what changed. While debugging I noticed some slight differences to a UIScrollView private method between iOS 14/15 (_findScrollableAncestorIfNeededWithEvent:).
By subclassing a scroll/collection view and overriding + returning nil from _parentScrollView, you can get the iOS 15 logic to more closely follow what iOS 14 does. This fixes the modal drag issue, but it's not exactly a great workaround... pretty sure Apple won't want us overriding this private API (who knows what other effect it might have).
Post not yet marked as solved
(If anyone at Apple happens to be reading this, I've attached a demo project to FB9575496 demonstrating the issue).
Post not yet marked as solved
Doing some digging... it appears the problem has been around in some form for a while, so it doesn't seem related to the iOS 14 release. What's not clear is what the underlying cause is or how to fix it:
https://developer.apple.com/forums/thread/658174
Try searching google for a few values of 'The current version requires OS X <iOS version> or later' too and a few results show up (I can't link them here due to external URL linking rules)
Post not yet marked as solved
Just wondering if you found any solution to this? I'm also seeing the same issue, although my error mentions OS X 12.0...
https://developer.apple.com/forums/thread/660488
It seems as though OS X (version) is using the minimum iOS version instead of the minimum macOS version, given that your error mentions OS X 13.0.
Post not yet marked as solved
Any idea why users would see such a comment? @KMT it's not too clear to me... the only way I can explain this is that the iOS minimum version is being incorrectly used in place of the macOS version.
Yeah, hoping this gets resolved on Apple's end somewhere. I guess it's possible there's something that's changed on the macOS binary from my side too though.
Post not yet marked as solved
That's surprising. Does it really ask for OSX 12.0 (they now speak of MacOS and 12.0 does not exist (next to come is 11)). @Claude31 - unfortunately, yeah it really does say that. My best guess is that it's taking the minimum iOS version number (it's a catalyst app) and using it in a macOS context.
Post not yet marked as solved
I’m also running into exactly the same issue - older app with a prefix ID != team ID, and uploading a MacOS universal build doesn’t work. Automatic signing says the team ID is invalid (because it’s not a team ID), manual signing says the application identifier entitlement is invalid. I’m in communication with Apple dev support but the responses haven’t been very helpful so far. Did you manage to get a real answer from Apple on this?
Post not yet marked as solved
I spent some time getting to the bottom of this: The root view controller in my macOS catalyst scene was a collection view controller. If I wrap this in a navigation or split view controller, drag works without crashing. It’s not great, but I guess somewhere the parent view controller was being requested by macOS, and there was none... you can turn the navigation bar off in a navigation controller and the fix shouldn’t be noticeable. YMMV though, perhaps there are multiple things that can lead to this issue. Unfortunately even with drag working, drop doesn’t seem to register for me, but this is one step closer. Let me know if drop works for you.
Post not yet marked as solved
Unfortunately I'm seeing exactly the same issue. Did you manage to solve this?
