While reviewing our app to prepare for macOS Monterey, I noticed an error when restoring purchased subscriptions. The error is issued via the following log method: - (void)paymentQueue:(SKPaymentQueue*)queue restoreCompletedTransactionsFailedWithError:(NSError*)error The error is the following: Error Domain=SKErrorDomain Code=0 "UNKNOWN_ERROR" UserInfo={NSLocalizedDescription=UNKNOWN_ERROR, NSUnderlyingError=0x600003c9b690 {Error Domain=ASDErrorDomain Code=950 "Unhandled exception" UserInfo={NSLocalizedDescription=Unhandled exception, NSLocalizedFailureReason=An unknown error occurred}}} Is this error known? Has the API for macOS Monterey changed? How can we solve that issue?

I have noticed that our app on macOS Monterey cannot find email files with .emlx or .eml extension stored in directories shared with the app. I am aware that email indexing on macOS Big Sur has migrated to Core Spotlight and thus can no longer be found via Spotlights. However, a metadata importer for the file formats is available under macOS Big Sur. So if files are in either file format and have been placed in a shared directory, they can be found via Spotlight. Under macOS Monterey I find that the full text of such files is not indexed. You can reproduce this behaviour with the following examples. Precondition: In one of the accessible directories, for example for documents, there is at least one file with the extension .emlx or .eml. The following query shows a list of emails in the user directory: mdfind -onlyin ~ "kMDItemContentTypeTree == 'public.message'" The following query returns the corresponding email with the filename 20.emlx: mdfind -onlyin ~ "* == '20.emlx' && kMDItemContentTypeTree == 'public.message'" The following query already returns no results. A tokenizing of the titles does not take place: mdfind -onlyin ~ "* == '20' && kMDItemContentTypeTree == 'public.message'" The following question does not return any results, although the word is contained in the text of an e-mail: mdfind -onlyin ~ "kMDItemTextContent == 'apple' && kMDItemContentTypeTree == 'public.message'" Does anyone know if the reason is that this is an early beta version or do we need to prepare for a helper solution, for example with SKSearch Kit?