Thanks, that was the right direction, and it found something. Checked every bundle in the archive that was uploaded. There are no nested bundles at all: no PlugIns directory, no Frameworks directory, no app extensions, exactly one Info.plist in the whole package, and one Mach-O built for arm64. So no conflicting value in a nested bundle, and I have stopped trying to override arm64 as you suggested. What the inspection did find is a packaging defect I would not have looked for: the bundle contained a stray editor backup file, LocationDetailView.swift.expbak, 1574 bytes of Swift source, sitting at the top level of the .app. The cause is worth writing down for anyone who searches this later. The project uses Xcode's filesystem-synchronized groups. A file that merely exists in the source folder and is not a recognized source type gets copied into the built product as a resource. There is no target membership to review, because it never had one, and there is no warning. So source code shipped to App Review, and to users, without anything in the project surfacing it. I removed it and added a unit test that fails the build if any editor leftover appears under the source folder, verified by planting a decoy file and watching it fail. I do not claim this caused the installation failure, and I have no way to prove it did. It was the only anomaly in the package. On testing the exact build on hardware: I do not own an iPad. What I am doing instead is running Validate App on the archive in Organizer, exporting the App Store IPA and inspecting the exported package rather than only the archive's .app, and installing through TestFlight on an iPhone, which at least exercises real App Store installation validation even though it is the wrong device family. If anyone has a better way to reproduce installation validation without the hardware, I would take it. I have also asked App Review for the bundle identifier and the exact installation error from the review device, since without a reproduction I cannot tell packaging from the key they cited. Open question for the thread, in case it saves someone else the week: has anyone seen an unexpected resource file in the bundle produce an install failure that App Review reported as a UIRequiredDeviceCapabilities problem?