How was this resolved? I am in the same situation, the subscription has been rejected 5 times without any further information. If you can tell how it was resolved I am very happy. I even opened a ticket with apple which is unanswered for 2 weeks now.

Have you tried to just upload the app again with a new Build number so it will be reviewed again? My experience is that every now and then this problem occurs in Apple's test environment, without anybody really knowing why. And the reviewers are not really investigating this. On the next review it will probably work. At least this is my year long experience.

I have found a workaround to this. If you explicitly ask to access a securityScopedResource then it works again. So if you add the following code let access = openUrl.startAccessingSecurityScopedResource() defer { if access { openUrl.stopAccessingSecurityScopedResource() } } then the file can be opened again. But this is clearly against the documentation. In https://developer.apple.com/documentation/security/app_sandbox/accessing_files_from_the_macos_app_sandbox?language=objc the documentation states clearly the following: The operating system implicitly starts security-scoped access on URLs passed from open panels, save panels, or items dragged to your app’s icon in the Dock. This is clearly not happening anymore. I think I will file a bug.

Well it seems by deleting all Localizable files from this target I was able to solve the issue. After that I created a new Localizable file with the same targets and I created all localizations again. Then I was able to copy the already localized version back. After that the conversion to the string catalog is working again.

By the way: Using ISO8601DateFormatter gives the right result for this. But the other side of the API does not accept the Z at the end of the output. This is why I am using a format string.

I stumbled across this answer and while your answer is correct it still misses one point. The DateFormatter produces wrong string results. Especially when using the Locale en_US_POSIX Just run the following code in playground: let dfWithLocale: DateFormatter = {     let df = DateFormatter()     df.locale = Locale(identifier: "en_US_POSIX")     df.dateFormat = "YYYY-MM-dd'T'HH:mm:ss"     df.timeZone = TimeZone(secondsFromGMT: 0)     return df }() let dfWithoutLocale: DateFormatter = {     let df = DateFormatter()     df.dateFormat = "YYYY-MM-dd'T'HH:mm:ss"     df.timeZone = TimeZone(secondsFromGMT: 0)     return df }() var date = Date().addingTimeInterval(-60*60*24*365*3) while date < Date() {     let stringWithLocale = dfWithLocale.string(from: date)     let stringWithoutLocale =  dfWithoutLocale.string(from: date)     print("Date: \(date) as StringWithLocale \(stringWithLocale) as StringWithoutLocale \(stringWithoutLocale)")     date = date.addingTimeInterval(60*60*24) } This produces wrong output exactly around December 26 to December 31! Here is the relevant output. In the middle the date as string using the locale, on the right the string using no locale and on the left the date with string interpolation. Date: 2021-12-24 08:18:57 +0000 as StringWithLocale 2021-12-24T08:18:57 as StringWithoutLocale 2021-12-24T08:18:57 Date: 2021-12-25 08:18:57 +0000 as StringWithLocale 2021-12-25T08:18:57 as StringWithoutLocale 2021-12-25T08:18:57 Date: 2021-12-26 08:18:57 +0000 as StringWithLocale 2022-12-26T08:18:57 as StringWithoutLocale 2021-12-26T08:18:57 Date: 2021-12-27 08:18:57 +0000 as StringWithLocale 2022-12-27T08:18:57 as StringWithoutLocale 2021-12-27T08:18:57 Date: 2021-12-28 08:18:57 +0000 as StringWithLocale 2022-12-28T08:18:57 as StringWithoutLocale 2021-12-28T08:18:57 Date: 2021-12-29 08:18:57 +0000 as StringWithLocale 2022-12-29T08:18:57 as StringWithoutLocale 2021-12-29T08:18:57 Date: 2021-12-30 08:18:57 +0000 as StringWithLocale 2022-12-30T08:18:57 as StringWithoutLocale 2021-12-30T08:18:57 Date: 2021-12-31 08:18:57 +0000 as StringWithLocale 2022-12-31T08:18:57 as StringWithoutLocale 2021-12-31T08:18:57 Date: 2022-01-01 08:18:57 +0000 as StringWithLocale 2022-01-01T08:18:57 as StringWithoutLocale 2021-01-01T08:18:57 I am not sure when this started to go wrong. I am running this with macOS 13.2.1. Running the same in the playground for iOS gives the same result.

Just updated to macOS 12.2 and the problem is still there. Is somebody else successful with the pairing on macOS 12.2? This is really annoying. Pairing of the same device, using the identical code on iOS works flawlessly.

Hi, thanks for your answer. Of course it is an idea to just use withCheckedThrowingContinuation(function:_:) to introduce my own async functions to existing functions with completions, but it just seems odd, that Apple just does not supply them out of the box. Maybe another beta will.