This is a giant step backwards. One of the nice things about macOS is the built in apache including PHP. Please reconsider this.

A few people have reported that copying and renaming the 14.5 DeviceSupport folder to 14.6 within Xcode will work.

Just an update By changing all the Code Signing Identities to "Apple Distribution" it now is accepted by Transporter, but the app itself does not run and fails under a "spctl -a -v" check, but passes a check with "codesign -v --strict --deep --verbose=2" The internal embedded.provisionprofile seems to have different entitlements than I specified in my --entitlements when signing. Honestly, I spend 40% of my time coding my app and 60% fighting with certificates, signing, entitlements, provisioning and all the other junk that we have to do now. I miss the days of CodeWarrior and even MPW when things just worked.

I have filed a DTS incident for this as it is a fairly complex project.

I did check with codesign. This is the result of "codesign -d --entitlements :-" If I use Archive, Xcode does not build my two dependent modules (the bundle and the launcher) even though in the Schema they are build in the order "launcher, bundle, app" and "Find Implicit Dependencies" is checked. Normally I use "Build for Profiling" which is configured for Release, with a script to do the code signing which has worked from Xcode 4 to Xcode 11. When I try to Archive it, I get output, but also: /Volumes/Vault/Beta/EarthDesk 7.5 β/productbuild:1:1: directory "/Users/trygve/Library/Developer/Xcode/DerivedData/EarthDesk-cxaqpchwzcdrtucehxedgouyvlju/ArchiveIntermediates/Build App Store Package/IntermediateBuildFilesPath/UninstalledProducts/macosx" does not exist for writing "EarthDesk.pkg".

I am running into this same problem. Checking the code sign gives me: valid on disk satisfies its Designated Requirement and both the main app and helper app have: keycom.apple.security.app-sandbox/key true/ Yet when trying to upload I get: ERROR ITMS-90296: "App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "com.xericdesign.earthdesk.mas.pkg/Payload/EarthDesk.app/Contents/Library/LoginItems/EarthDesk Launcher.app/Contents/MacOS/EarthDesk Launcher" )] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app."

The same thing affects System Pref Panes. Five years and no results so I would not ever expect this to work. Sigh.

I was able to disable SIP completely (in 10.15 it was possible to disable only the debugging aspect of SIP) and then attach to legacyLoader. You need to set the following as the launch executable: /System/Library/Frameworks/PreferencePanes.framework/Versions/A/XPCServices/legacyLoader.xpc/Contents/MacOS/legacyLoader And check the box that tells it to wait for launch. When you open System Preferences and try to load your pane, the OS will launch legacyLoader. Personally, I think Apple really dropped the ball on this as there is no way to debug them without disabling SIP and I plan to remove my app from System Preferences (where it has lived since 2007).

What seems to work is either editing the description of the IAP (edit > save > revert > save), or doing the same thing with the Cleared for Sale checkbox. After making these changes, the IAPs showed up within 8 hours. The 5 IAPs that I left untouched are still not available 48 hours after the app was released. I just did a similar edit to these, so hopefully within 8 hours, they show up too.

What seems to work is either editing the description of the IAP (edit > save > revert > save), or doing the same thing with the Cleared for Sale checkbox. After making these changes, the IAPs showed up within 8 hours. The 5 IAPs that I left untouched are still not available 48 hours after the app was released. I just did a similar edit to these, so hopefully within 8 hours, they show up too.

Same problem here. Approved for Developer Release: Jul 29, 2020 at 2:50 PM Ready For Sale: Jul 30, 2020 at 6:15 AM It is now the 31st at 2:00pm and the IAPs are still not available in the production version (they work fine in the sandbox/TestFlight). All my banking, tax, contracts are fine, the app is "Ready for Sale" and all the IAPs are "Approved". It weird that they would not configure the system to make sure all the IAPs are propagated and fully ready before making the owning app available.

Same problem here. Approved for Developer Release: Jul 29, 2020 at 2:50 PM Ready For Sale: Jul 30, 2020 at 6:15 AM It is now the 31st at 11:30am and the IAPs are still not available.

I have run into this too. I submitted a tvOS app with 8 IAPs (Renewable). The app was rejected for a EULA issue which we fix and resubmitted the same binary. It was rejected again because the IAPs did not load and the price buttons did not populate. I then made a new build and submitted but because the 8 IAPs are all 'Waiting For Review", there is no way to attach them to the latest build. So frustrating.