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

Any solution? @buster6060 have you reported this issue using Feedback Assistant?

Still not fixed and no feedback in the ticket (besides "There is no workaround DTS can provide (...)" from DTS team). Seems like installing random languages on user devices and breaking text suggestions while typing is not a big deal for Apple, all man-power is delegated to memoji development.

It turns out that CoreData+CloudKit cannot preserve custom key-value pairs from CKShare either. It works for a couple of seconds and then the NSPersistentContainer stops returning both title and custom key-value pairs even though they are available in CloudKit Console... I can't believe how buggy CloudKit integration is. It's a bug after bug, 20% of the integration are workarounds and hacks to fix faulty CloudKit+CoreData behavior... And this SDK is available since 2019 O_O. This should never leave beta at this state... Reported: FB14916959

The same on my side, I'm suddenly not able to get any records, neither via CloudKit Console or CKContainer programmatically: <CKError 0x60000098ddd0: "Server Rejected Request" (15/2000); op = 7AAB6A29B663472C; uuid = XYZ; Retry after 31.0 seconds; container ID = "iCloud.XYZ"

Just a hint for others: if you use a Panel(which doesn't take over the focus) as your main app window on macOS, make sure that it triggers NSApplication.willBecomeActiveNotification. Otherwise, the synchronization will be completely broken as the CloudKit SDK mainly awaits activation notifications, which are not sent if the app doesn't capture the focus. Often neither the export nor import will work in this case, unless you open some other, regular window. The best solution at this point is to use the workaround that I posted and send manually activation events periodically (I'm curious if it's not going to generate tons of fake analytics). For now, the synchronization is unreliable unless you send those events manually, we have to wait for a fix.

Another pitfall of CoreData+CloudKit. This issue still occurs.

Weird, suddenly I stopped receiving this error. Maybe it required a couple of hours to propagate some information, not sure. Nevertheless, it seems like CloudKit synchronization is not stable on Keyboard Extension. Sometimes it works, but I guess, the only reason why it works is because underneath the main app starts in the background. After a minute or so, the keyboard stops synchronizing changes with Cloud and I have to start the main app to synchronize. Not even restarting the keyboard helps.

I think I figured out what's going on with synchronization. Why it takes so long. After I migrated to CoreData + CloudKit it turned out that it synchronizes remote changes only after deactivating and activating the app again (my macOS app). I was able to confirm that the underlying mechanism relies on willBecomeActiveNotification notification. After this notification is received, the synchronization is instant. However, without it, even if the app is in the foreground it may take a long time to synchronize remote changes. As a workaround, I discovered that sending NotificationCenter.default.post(.init(name: NSApplication.willBecomeActiveNotification)) forces Core Data synchronization. Unfortunately, it's just a workaround, not a reliable solution...