Interesting idea, but as forum posts aren't formal requests, be sure to make an enhancement request against the tools using the feedback bug report link, below, being sure to add your report number(s) to your thread for reference, thanks and good luck.

A daily FAQ - be patient while the backend catches up with itself, being sure to -not- hammer the process with repeated uploads in the mean time.

The hallmark of any robust OS is how well it tolerates and survives over time, the details of which are buried in various SDKs and APIs, some public, most private, I suspect. Private can also mean the 'blackbox' stuff that Apple keeps out of the public's and competitor's view. We're left to not only imagine the details, but to also admire the hard work, testing and coordination across hardware and software teams, witnessed by the stunningly proficient results that are clearly behind such efforts. I'd not expect Apple would survive very long if the 7 secret spices and herbs were to become known to the world. Frameworks, BTW, are compiled/baked into an OS, morphed into the binary, vs. being 'included'.

I don't know what incompatibility issue this error refers to The error literally tells you that it refers to platform, which is device. Devices include OSs and sport various hardware options. So while that error may be the backend's best quess (and could be well off the mark), it means what it says - the device being used is not compatible. All it doesn't say is why. What is the status of that app? How long ago was the code generated? Did you monkey with date/time on that device and forget to make it actual? Does the device have sufficient free space? Has the device been recently upgraded to a newer and/or beta OS? Still no joy, flush that code, make a few new ones and put them to the test. Good luck.

Right-click the Info.plist file in your project and choose to > Open as > Source Code, and remove this entry: <key>UIUserInterfaceStyle</key> <string></string> Then clean-build-folder and try again. Good luck.

How long has it been since it was approved and released? If it was in the last day, you might need to just be patient. Is it available in other stores, at least? If you care to name it, perhaps someone can double check...

However, I think that if I take it off sale, I can never put this first approved version back on sale Perhaps based on anecdotal rumor, that seems a misinterpretation of a process that has never worked the way you speculate. Not sure why you're asking if you've already convinced yourself of the outcome, but as long as you reach your goal, I'm on your side.

Stop the build, clean the build folder, restart Xcode and try again, but not until you confirm several tens GB free space, trash emptied, on your SSD. Good luck.

Wby are you using auto code signing with a process that seems to scream for manual? You may not have the flexibility you want when you allow the process to assume control. I'd switch to manual, and then put efforts into sorting that out, instead of getting into a cage match w/auto.

Did you try disabling auto code signing? I think you need to walk away from wildcards in your example. You may need to reach out to support directly, via contact us below, and ask them to help untangle things. But if you have a working solution in this example, I'd stick with it, regardless. Good luck.

Not sure I understand your idea...perhaps because you're new to mobile apps, you're still forming it up. Suggest you spend time in the HIGs as an investment in your mobile dev future: https://developer.apple.com/design/human-interface-guidelines/ios/ In the mean time, see the ASRGs/Performance: https://developer.apple.com/app-store/review/guidelines/#app-completeness As for definitive, know that in the end, it's up to app review what they will/won't approve/reject - all you can hope for here are opinions from volunteer referees. No one here can make any 'definitive' promise you'll succeed, so, running the review gauntlet is the best you can hope for when it comes to that requirement. Good luck.

See your other/duplicate thread: https://developer.apple.com/forums/thread/659971?answerId=632081022#632081022

The aaguid delivered from safari was 16 zero bytes. Is it correct to be passed by this value? The length of credentialId is 20 bytes, not 32 bytes. Is this correct? Quoting that link: Verify the Attestation counter (4 bytes) — The number of times your app used the attested key to sign an assertion. aaguid (16 bytes) — An App Attest–specific constant that indicates whether the attested key belongs to the development or production environment. Apps generate keys using the former during development, and the latter after distribution, as described in com.apple.developer.devicecheck.appattest-environment. credentialId (32 bytes) — A hash of the public key part of the cryptographic key pair being attested. So, no, zero bytes does not an identifier make, and, no, not 20 bytes.

You can only have one build in review at a time. If you push another build, what happens to the one under review depends on what you choose for next step when uploading another... store, testflight internal testing only, etc. You don't detail your end game here, so you may need to pays yer, money and takes yer chances. See App Store Connect Help for details on app statuses.

Not sure there is a simple way, if at all. See this url for discussion: h ttp://hints.macworld.com/article.php?story=20131022070219858