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

Today suddenly notifications started working extremely fast, within one second or so. This is weird.

I figured out what is causing this issue. It turns out that the additional language is installed based on bundle id of your project O_O! So if you set the bundle id to "pl.app.keyboard" the Polish language will be installed. If you change it to "de.app.keyboard" the German language will be installed. This is definitely a critical bug in iOS, because it messes up suggestions while typing by installing unwanted language. I reported it in the feedback assistant: #FB13954760 and I also created TSI: #7913047

It turns out, that it's not project-specific. I was just able to create a new project, add a keyboard extension, run it on the simulator, and adding the keyboard installs automatically Polish language for the system. Even though, on macOS used to build the app I removed Polish from all system settings (Language & Region + Keyboards), so I have no idea where it comes from in the app.