I have the very same problem with some of my apps using a standard developer account. So this is not limited to enterprise accounts and apps. But this is not the same for all apps and all platforms. All of my Apps fail to run with this error on my iPad Air 2 if these were installed under iOS 14 directly from XCode. Some will even fail if I install the AppStore or TestFlight version of the App, but some will actually work when installed from the AppStore or TestFlight. I do not see any pattern here, why some do work and some don’t (when coming from the AppStore). And more strange: there are even Apps which fail when installed from the AppStore on the iPad, but does work without any issue on my iPhone (6s plus). So iPadOS 15 behaves differently than iOS 15. Hopefully this is considered as bug and will be addressed by Apple in the next beta releases. At least the App releases from the AppStore should still run under iOS 15. small addition to my post: after some more testing it turned out that the issue with the apps installed from the AppStore were caused by the AppStore failing to install the App or update properly. Even though the App appears on the homescreen and got a blue dot which indicates a new or updated App, the App was not installed properly and seems to be damaged. Deleting the App and installing from scratch again solved the issue (of course this is still bad because deleting an App will also delete its (user) data). So the only remaining issue is that apps installed from Xcode before the iOS 15 release can fail to run.

This API is a little bit strange, or still very buggy. Just presenting the MKLookAroundViewController does not let you navigate at all. I hope that this is just a bug. But what is working is this: Add the MKLookAroundViewController as child to your main viewcontroller. Then add the view of MKLookAroundViewController as a subview somewhere in your main view controller and make sure it is visible. The view of MKLookAroundViewController will now show a static image of the street and if you tab on this view the MKLookAroundViewController will actually open as "ViewController" in fullscreen (like it would be presented). Which means you do not present MKLookAroundViewController yourself, instead you let the view of MKLookAroundViewController do this for you after the user taps on this view. This also means it is currently impossible to "navigate" without having the user to do this extra tap on this extra view. I'm not sure if this is supposed to work this way. But in my opinion this doesn't make much sense, because you can't really do anything useful with this "extra" view. You only need it to indirectly present the MKLookAroundViewController. It would make much more sense to be able to simply present the MKLookAroundViewController directly without the need to show this extra view. But the fact that the delegate has methods which are called when entering/leaving the fullscreen mode indicates that Apple probably is serious about this. If you would present or dismiss the MKLookAroundViewController yourself, you would not need these delegate messages.

As far as I know, you can't have any working button or slider or any kind of user interaction control in live activity widgets. All touches will directly launch the corresponding App. You can only have "Links" which can deep link into your App. You can use different URLs for these links to do different things within your App.

Some additional findings: The problem seems to be related to updates to the Live Activity content. Which means as soon as the main App sends an updated status to the live activity, VoiceOver starts reading all content multiple times. If you only setup the content of the Live activity once, the content is only read once. The update interval itself seems to be irrelevant. So it doesn't matter if I send updated content to the widget every second or every minute. As soon it was updated, Voiceover is failing...

OK, I think I've found the reason for this problem: The problem seems to be the size of the image I try to show in the complications. I could not find any information about the concrete sizes of the different complication variations (these might be larger on larger watches than on the smaller models). So I initially tried a size of 128x128 px. This caused runtime errors in the Xcode preview and inspecting the error message saying that the image size was too large and the maximum would be 124x124px (circular) and 93x93px (corner) etc. (the numbers can be slightly different) Therefore I created matching images of these sizes and have used these. This works fine for the simulator and the previce in Xcode. But when I run the complications on a real device, the allowed image sizes seem to be even smaller. Unfortunytely there are no error messages or console messages when running complications on a real device, so we are debugging blind... So reducing the image sizes even further made the complications appear on the device as well. This actually leads to the problem that for the circular complication on most watch faces an image size of 120x120 is too large, but for the cirular complication for the „large numbers“ watch face this image size is too small to be not blurry. The final question is, where can we find information about how large images should or can be for the different kinds of complications? When these images are too small, they look blurry, if they are too big, they waste space or cause errors. But what are the sizes which should be used?

Same problem here. Yesterday it did work just fine. Strangely, this also applies to beta releases so I can't even submit an App via TestFlight.

Same problem. But it also affects beta releases, so you can't even submit to TestFlight.

Without seeing the code, it’s hard tell what exactkly is going on. But I would guess that the Map is simpy embedded into your view with the „safearea“ margins still active, so the system will automatically move the map away from dynamic island and other system elements at the screen borders, so the view is not partly hidden. And if you add your own margins to the view you might get such a big unused area… So no navigation bar needs to be involved here.

In the „Capabilities“ secion you need to add the „background modes“ capability and here check the „location updates“ option. And in the „Info.plist“ you have to either add the key NSLocationAlwaysAndWhenInUseUsageDescription or the keys NSLocationAlwaysUsageDescription and NSLocationWhenInUseUsageDescription. The value for these keys must be a string explaining why your App needs the location services.

I can experience the same issue and this bug breaks some features of my App as well. But I’ve found some kind of workaround: If you overide WKWebView you can override buildMenu(with builder: UIMenuBuilder) there. Within this method you first call super.buildMenu(with builder: UIMenuBuilder) to let the webview do its menu configuration and then you can do your own menu configuration (for example adding your own menu items). This might not be the most elegant solution, but at least for my project it is an easy workaround and works well.

A strange thing happened: The rejected items were approved recently, though I did not submit the items for review again. But I won’t complain if it stays this way.

At least now it works. For unknown reasons it did not work in my main project yesterday, repeatedly. But since yesterday the code was changed a lot and the Mac was also restarted, so whatever has caused the glitch, it can no longer be reproduced.

I'm currently looking for the very same thing. I guess you need to request the "com.apple.developer.web-browser.public-key-credential" entitlement for your App, which will then unlock the Webauthn code within WKWebView. The documentation from Apple doesn't tell much at all, unfortunately. At least this seems to be the case on the iOS platform when you have the "com.apple.developer.web-browser" entitlement (this entitlement is iOS only).

I’m having the same problem, only with another Lib: This is what the E-Mail from Apple sais about my App: Although delivery was successful, you may want to correct the following issues in your next delivery. Once you've corrected the issues, upload a new binary to App Store Connect. ITMS-90863: Macs with Apple silicon support issue - The app links with libraries that aren’t present in macOS: /usr/lib/swift/libswiftWebKit.dylib And I notice that the App can’t be installed on my Mac via Testflight. The latest AppStore version of the App can be installed on the Mac (from with the AppStore). I’m not sure when exactly the issue has started, but there are other threads in the Apple developer forum where developers have the very same problem: https://developer.apple.com/forums/thread/766061 https://developer.apple.com/forums/thread/756325 https://developer.apple.com/forums/thread/771068

Just a followup: Apple just approved the "com.apple.developer.web-browser.public-key-credential“ entitlement for my App. And the first tests look good. The „Webauthn“ demo pages which failed before do now work fine. So this entitlement seems to be the correct approach.