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.

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.

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.

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.

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.

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.