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.

[quote='789086022, DTS Engineer, /thread/756216?answerId=789086022#789086022'] The dock icon for your app is determined by the icon set up in your app, while the App Store icon is uploaded to the App Store. When you create a macOS app or any other app on the App Store, you must provide metadata for the app, including the App Store and screenshots. [/quote] To clarify this part. As far as I know, it is not possible to upload the App Store icon separately. It is actually a part of the icon set configured in the app in Xcode. There is one icon called "App Store - 2x" (1024x1024) for that. Here is the reference: @DTS Engineer thank you for the clarification. However, I think that both the documentation and Apple Design Resources are missing information about the App Store icon. I couldn't find any of the following information: Specification for the App Store icon (besides the information that its size should be 1024x1024) Whether the App Store icon should be rounded or rectangular Whether the App Store icon should contain padding like the app icon or not Template for the App Store icon As I mentioned, there is only one template for macOS Sonoma icons, called "Production Templates" at https://developer.apple.com/design/resources The official template is quite misleading because it has 1024x1024 version as presented here: But as you can see in the first screenshot, there is only one icon 1024x1024 in the set and it is for the App Store only. So if you use the one from the template, you'll get the incorrect result as described in the main post. I think the 1024x1024 icon should be removed from the template to avoid confusion between app icon & App Store icon.

What happens if a user installs a "free" app, purchases in-apps and then I convert the app to paid? I guess the user will keep the access to the app + updates because technically it is "bought"?

It is already fixed, no need to use Transporter :)

I don't know what was the problem but I figured out how to solve it. Basically, you need to recreate the target. In my case, I was using "the old approach" with watchOS app and extension app. Now Xcode 14 offers only a single target - maybe that was the problem. Steps that I used: Copy all files from your watchOS app to another location. Delete folder, target, and schemes, remove all remainings from watchOS app. Add watchOS app target using new Xcode. Add copied files from step. 1 Configure build settings, signing, and assets (whatever you need). Very important: set bundle identifier prefixed by your iOS bundle identifier. Very important: set WKCompanionAppBundleIdentifier in info.plist that equals your iOS app bundle identifier. Super important: go to your main iOS app target, general tab, frameworks, libraries... and click "+" and add your watchOS app. Now I like to use first watchOS scheme to install watchOS app first, then change scheme and install iOS app. Now your apps should be able to communicate using applicationContext.