That's how this company operates. In such important process like app review where a single decision can destroy your business, there should be an independent mediator who can resolve disputes, but there is none, because they don't care, this is how those big companies operate. So the whole process is a random thing, you will notice sooner or later that you may get rejected and other apps in the App Store do the same and they are fine. It's all random and depends on who is assigned to your review. I also noticed that there are some cases which are incorrectly implemented in their automation and if I don't add extra info in review notes, I will get rejected every time for the same thing, even though it is invalid.

I confirm everything you wrote. The wait for a review is now significantly longer. And I can tell you that no, they aren't doing anything about it. The quality of Apple's services is going down drastically. They don't fix reported critical bugs, and they introduce new ones with every update. Reviews are just another step in lowering quality. Not to mention that the review process is not a charity work, we pay the annual subscription and 15-30% in fees from sales... And that's what we get in exchange - making dev lives miserable by rejecting apps for every tiny thing and waiting for days for a review. I also observed a significant drop in installations since April, so they also changed something in algorithms. I will be adding a direct distribution in the near future too. The review process and wait time is unacceptable.

I managed to perform multiple tests on the physical Apple Watch and I can confirm that the root cause of this problem is the app intent shared between watchOS and widget extension target. Having this file in a single target solves the issue. However, this approach can’t be used to workaround this issue because the widget configuration intent is by design supposed to be used in these two targets. Otherwise, tapping on a widget produces silent errors, which I included in the previous post. Also, sharing intents is necessary to be able to perform ClockKit complications migration and to check widgets configuration from the watchOS app. So we found the root cause, but we don’t have any suitable workaround yet. This problem is clearly watchOS bug. Additionally, I also observed that sharing the intent between iOS app and widget extension doesn’t cause this issue. So it happens only when the intent is shared between watchOS app and widget extension. Also, the problem isn’t caused by sharing the localization file. It all depends on target membership of the intent file.

Hi, I'm using the latest Xcode (26.4.1) and I'm targeting iOS 16.6. Also, make sure that you don't provide parametrized summary - in this case it works correctly. I'm using something like that: static var parameterSummary: some ParameterSummary { Summary("List Items") { \.$collections } } The issue occurs only if you have the "form" view. It's easily reproducible with this configuration. I tried also with an optional array [String]? and it doesn't help. I've found a workaround which in my case is suitable. I added predefined values this way: @Parameter(title: "Collections", optionsProvider: CollectionsOptionsProvider()) var collections: [String]? However, it isn't good enough if someone needs a completely custom input.

I experience the same problem. Have you managed to resolve it?

Hopefully this is not too late. I've been quite swamped these days... No, I'm still trying to resolve this problem. Thank you for investigating it. Tomorrow, I will be able to check it on a physical device. However, even if this is a workaround, it won't help in my case, because I need to have access to intents from the watch app to check a couple of things and to perform old complications migration from ClockKit to WidgetKit. Also, intents should be shared between the watchOS app and widgets extension. If you don't share it and tap on a widget you get these warnings in the console: Failed to instantiate type ConfigurationAppIntent by name (12WatchWidgets22ConfigurationAppIntentV). The type with this mangled name does not exist in the process’s memory space. [InitializeAction <<E:A1CC23EC19DC>>] Could not find an intent with identifier ConfigurationAppIntent, mangledTypeName: Optional("12WatchWidgets22ConfigurationAppIntentV") associateAppIntent(forUserActivity:) - Error converting INIntent to App Intent: AppIntents.PerformIntentError.intentNotFound You can check this if you run your project from Xcode (watchOS app target) and tap on a widget.

@DTS Engineer so what's going on with this issue? I created DTS ticket as requested, I provided reproducible minimal project, and the only thing I received is this message... Thank you for providing this information. It is quite intriguing and I believe it would be prudent to file a bug report to investigate the underlying cause of this issue. As we do not encounter any localization-related problems on watchOS, it is possible that you have identified an issue that requires our attention. Please submit a complete bug report regarding this issue using Feedback Assistant So the localization isn't working and this bug is going to be ignored for the next couple of years? Great support in exchange for a yearly developer subscription and a 15% fee on app sales. Not to mention another truly critical bug that hasn't been fixed for 2 years... https://developer.apple.com/forums/thread/757380

I ran some tests and can confirm that with Xcode 26, xcodebuild now works just as fast as Xcode 16 with the workaround. This is true both when rebuilding the app without any changes and when performing incremental builds after making changes. I also noticed that Xcode 26 no longer calls the slow developerservices2.apple.com. Instead, it uses https://ocsp2.apple.com, which is much faster.

We have a similar issue with MP4 files. It works well with HLS, but with MP4 the AVPlayer requests all chunks like (, ), so basically, it ends up downloading the same video multiple times during a single playback... It seems like the streaming is broken.

Great investigation guys! Indeed those requests are very slow, on my side they take around ~20 seconds: Blocking developerservices2.apple.com significantly improves build time. As @FelixII suggested, the solution is to block it in /etc/hosts by adding: 127.0.0.1 developerservices2.apple.com or probably a better option to use something like Proxyman app to temporarily block/unblock it. Keep in mind that blocking this domain will probably result in Xcode being unable to automatically register devices, capabilities, etc. I guess we need to wait for some fix from Apple. Probably some cache?

I figured it out: You can connect any Bluetooth keyboard to an iPhone, it should behave the same way as on iPad. Hitting the globe button once should show a list of keyboards, if I select my custom keyboard it appears automatically on the screen even if the hardware keyboard is connected. Then I can quickly switch between two most recent keyboards by hitting Globe button again.

I figured it out. It turns out that I can directly use xcrun xccov on xctestresult file.

Is there any alternative or is that functionality abandoned? How can I get code coverage for a specific file?

@DTS Engineer Actually, it's not an alternative to me. The command you mentioned doesn't provide the archive id which I'm later using to export xccovarchive and retrieve code coverage for a file. So first I export archive (using the id retrieved from the first command): xcrun xcresulttool export --type directory --id <ArchiveRef> --path <xcresult path> --output-path <path> which is also deprecated. And then I read the code coverage for a specific file with: xcrun xccov view --file <file> <xccovarchive path> So how do you achieve the same without using deprecated commands?

It is a critical bug in iOS which has no workaround and seriously affects users... yet it's still not fixed even though first reports appeared 6 YEARS ago! Here are other reports: https://developer.apple.com/forums/thread/757380 https://stackoverflow.com/questions/53069262/ios-adds-new-preferred-language-when-installing-my-3rd-party-keyboard My tickets: FB: 13954760, TSI: 7913047