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

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.

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?

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...

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.

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.

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.

@Claude31 I filed a bug report already: FB9036815

@eskimo: Actually the depth of my tree is only around 65 levels, but because each node (NSDictionary) uses an array (NSArray) to store its child nodes, the depth level when counting dictionaries and arrays separately reaches the 128 limit which @Claude31 has mentioned. So for a tree structure this is not that deep at all, and I would expect that the iOS should not have any issues with it. Don't you think so? @all I have already found information about the file format, so I am now able to parse the file myself. It's actually pretty easy. Thanks for all the responses so far.

Actually the App is not sandboxed. But I guess I've found out what's going on here. The problem is WKWebView. If the download of the file is done by WKWebView, then this problem occurs. The reason is probably that WKWebView is using its own private processes to load data from the internet and to render content. So it doesn't matter if the App is sandboxed or not, WKWebViews internal processes are probably sandboxed, and so... If the downloads are made "outside" of WKWebView, there are no problem anymore.

The App is not sandboxed. In the project settings the "App Sandbox" capability is not used. The "hardened Runtime" is active, which is required for Notarization. But even if it would be sandboxed, it should nevertheless be possible to launch and use the App. Why it is working when downloaded with Safari or with the old version of my App, and why does the App from the ZIP not lanuch when downloaded from the new version of my App? As I said, the App is properly signed and notarized. What do I need to do to make sure that my new App can download a ZIP archive with an App update, so that when extracting the ZIP, the App from the ZIP can be launched?

Good new: I received an email from Apple today, where they told me that they gave me the entitlement. Bad news: Unfortunately it doesn't work. I followed the instructions to a new provisioning profile, but the point within this process where I should be able to selecet the new entitlement is not available. I tried with several available options (development, distribution/AppStore), but nothing worked. Any advice? Rigth now I guess that they’ve just forgotten to actualy assign the new entitlement to my account, despite the fact that they already sent the confirmation email.

I'm in the exact same situation. I'm also waiting for a response.

Though there are many things you can do in UIWebView and which still don't work in WKWebView, you should nevertheless start to find a way to migrate your project to use WKWebView. Starting with December 2020, Apple won't accept Apps and updates anymore which still use UIWebView. So WKWebView will be the only option very soon.

Please file a bug report. This is one of the many bugs of iOS 13 (and still not fixed in 13.2.3). There's no solution available right now on the iPad. BTW: There's no such issue on the iPhone and also no such issue when using the old "UIWebView". Only WKWebView of the iPad shows this problem.