I have started implementing support for the new App Store Server notifications (version 2): https://developer.apple.com/documentation/appstoreservernotifications/receiving_app_store_server_notifications I am not sure how to prevent a possible mad-in-the-middle attack when using those notifications. The decoded header that I get for notifications in the Sandbox environment is missing the "kid" field that is used to identify the key used to generate a signature. Yes, I understand the the whole entire certificate chain is available in the "x5c" field and it could be verified by itself. However, this does not guarantee that a notification was signed by Apple. This approach (with no specific key, with a certificate chain in x5c) works fine when verifying a receipt on device with StoreKit 2 but it does not work when getting a notification on a server.

If you have a Siri phrase for an app Intent: phrases: ["Show me my books on \(.applicationName)"] What is the right format to localize that phrase in a strings file? genstrings does not work for that phrase. I assumed that it would be: "Show me my books on ${applicationName}" = "Show me my books on ${applicationName}"; But that does not work.

I have noticed a strange problem today. I have uploaded a build of my app to TestFlight for internal testing using Xcode 12 beta 3. The app has widgets and if I run the app locally from Xcode widgets are working on device. However, when I install a beta from TestFlight the widgets are not suggested by iOS and I can see in the logs that the widgets are actually crashing (something is going on with WidgetKit in the crash logs). This has started only with beta 3, I have previously used TestFlight with widgets in beta 1 and beta 2. Does anyone else have this problem? My feedback number is FB8122742.

I am trying to submit an app from Xcode 13 beta 1 to App Store Connect for internal TestFlight testing. After submission my binary is marked as invalid and I get the following email: ITMS-90338: Non-public API usage - The app contains or inherits from non-public classes in AppClips/App Clip.app/App Clip: NSConstantArray ,The app contains or inherits from non-public classes in Watch/WatchOS App.app/PlugIns/WatchOS Extension.appex/WatchOS Extension: NSConstantArray, NSConstantIntegerNumber  Uploading the same app from Xcode 12 results in a successful submission. Feedback FB9157492. Anyone else with the same problem?

Xcode 12 beta 3 has the following change: Interface Builder now supports the two-column and three-column styles for UISplitViewController introduced in iOS 14. (57025285) Which is great is you want to adopt the new Split View Controller API added in iOS 14. However, if you need to support iOS 13 for the time being, it might be easier to keep using the old API instead. And it looks like since Xcode 12 beta 3, there is no easy way to do that if you use Storyboards. Any UISplitViewController created with a Storyboard will use either a two column or a triple column style. And because of that there will be significant change in behaviour, new delegate callbacks will be used, etc. The only workaround that I found so war is to create a UISplitViewController manually, this way it gets the legacy style (UISplitViewControllerStyleUnspecified) and the classic API is used. Does anyone have a better solution?

Has anyone tried creating a widget with WidgetKit for macOS Big Sur? I mean a widget for a Mac app. WidgetKit simulator crashes when I try debugging my widget. Same happens when I try running a widget with a new project in Xcode (FB8126474).