I needed the G4 certificate from here. Maybe because it’s a year later from when the above solution was posted? In any case this is pretty messy.

Interestingly, running --upload-package a second time, hours later, results in this: Getting list of providers... Beginning delivery... Resuming package upload to the App Store… Requesting upload instructions from the App Store… Completing upload… File 'OurApp.ipa' complete. Uploaded asset is processing. No errors uploading '../exports/OurApp.ipa' And the app is now uploaded and processing.

I see this behavior, too, in Xcode 13.2

I still frequently encounter this issue today with Xcode 13.

Same here with Xcode 13.2.1. FB9828542 Apple, you need to stop abandoning things before we all have access to a replacement.

We just ran into this today. We also have no watchOS component in our app. Currently have a support ticket open with Apple, they're escalating it.

I get this a lot too. Filed FB9807088

Ah. There was a user setting VALID_ARCHS that I think an old Xcode upgrade created (I certainly didn't). It's a very old project.

This is still a problem, two years later, in Xcode 13.1. I've written feedback about it.

Hmm. We already have the export compliance plist key, but have two out of many users with "no builds available."

Ah I saw that headline but almost subconsciously dismissed it thinking it was just an announcement of the new thing. That'll learn me. Thanks!

I've verified that it's fixed in iOS 15b1. Apple really needs to back-port this fix. I worked around it by posting a notification in .onAppear() higher up the hierarchy, where .onAppear was being called appropriately.

I ran into this today. I can't explain it, but it's a real issue. Where did you read about the filed bug, @cyclic?

It seems to require an inordinate amount of free space to decompress, double or triple the size. Xcode 13b1 is 33 GB on my disk (although Finder seems to have lost its mind reporting the size). I needed over 100 GB free to decompress it the other day. BTW, I don't recommend b2, as it fails to compile some Swift code that depends on CF_RETURNS_NOT_RETAINED in Obj-C headers (like AVCapturePhoto).

13b1 is definitely much faster for me. I'm going to try using it day-to-day, and then revert to 12.5 for builds to submit.