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?

Our app was rejected because of an outdated entitlement key. We have to use this key, because othervise our app won't. work.Our app makes use of the scripting bridge. I we follow the documentation, we should use the com.apple.security.automation.apple-events key. The app would prompt a dialogue to ask the user to grant access to apple events.In practice, I doeasn't work. We need to add com.apple.security.temporary-exception.apple-events for the particular app, we use scripting bridge for. If we do that, the system promts the dialogue as expected and the spcipting bridge wordls. I seems to be a bug of macOS. However we need to resolve the issue, because the app is rejected and the reviewer doesn't respond to our explanation. I don't understand the problem. The seucrity mechanism of macOS is working and the user experience is aligned with Apple's requirements. We just need to use the old entitlement as a workaround until Apple will fix this bug. We also want to be compatible with Sierra and High Sierra, which don't know the new entitlement, that is introduced with Mojave.Some ideas?

We need to parse emails in our app, that are sometimes encoded in NSISOLatin1StringEncoding instead of NSUTF8StringEncoding. Unfortunately the convenient method stringByReplacingPercentEscapesUsingEncoding for NSString objects is deprecated. The recommended method stringByRemovingPercentEncoding is not sufficient for our use case. How to transform NSString objects with iso-8859-1 encoding?