Guideline 2.3 rejection citing UIRequiredDeviceCapabilities when the only value is arm64

Question

Created 4w

Replies 2

Boosts 0

Participants 2

My app was rejected under Guideline 2.3 (Accurate Metadata) with the standard text saying the UIRequiredDeviceCapabilities key is set up so that the app will not install on the review device. The review device was an iPad Air 11-inch (M3) on iPadOS 26.6.

I inspected the Info.plist inside the exact archive that was uploaded. Everything relevant:

UIRequiredDeviceCapabilities = (arm64) UIDeviceFamily = (1, 2) MinimumOSVersion = 18.0 Binary architectures = arm64 Built with Xcode 26.6, iOS 26.5 SDK

An iPad Air 11-inch (M3) is arm64, is device family 2, and runs an OS far above 18.0, so as far as I can tell nothing in that plist can prevent installation. arm64 is the value Xcode injects automatically, and I have never declared the key myself.

What I have already checked:

There is no UIRequiredDeviceCapabilities in my source Info.plist and no INFOPLIST_KEY build setting for it. The value is injected at build time. I added the key to my own Info.plist as an empty array to try to override the injection. Xcode still writes (arm64) into the built plist, so I cannot remove it. I built the same Release configuration and installed it on an iPad Air 11-inch (M3) simulator running iPadOS 26.2, the highest iPadOS available to me. It installs and launches with no error. There are no app extensions. One target, TARGETED_DEVICE_FAMILY = "1,2".

My questions:

Is arm64 in UIRequiredDeviceCapabilities known to trigger this rejection on iPadOS 26 review devices, or is something else being reported under this template? Is there any supported way to suppress the value Xcode injects, or will the array always contain arm64 for an arm64-only binary? If the installation failure was real but caused by something other than this key, what else produces an install failure that App Review would attribute to UIRequiredDeviceCapabilities?

Context for why I am asking here and not only in App Store Connect: the build sat in Waiting for Review for about a week and a half, I used my expedited request, it was rejected on this, I replied in Resolution Center with the plist contents and received no answer, and the resubmission is back in Waiting for Review. I am not asking anyone here to change a review outcome. I am trying to find out whether this is a known issue with the key so I can stop guessing.

Any pointer would be appreciated.

Answer 1

GetResubmit OP

3w

arm64 itself is expected here—Apple’s documentation says it should be included for 64-bit apps and embedded bundles. I would not keep trying to remove or override it.

The next step is to inspect the exported IPA from the exact submitted archive, not only the main app’s plist. Check UIRequiredDeviceCapabilities, UIDeviceFamily, MinimumOSVersion and supported architectures in every embedded extension and framework. A conflicting value in any nested bundle can produce an installation failure that App Review reports against the app generally.

Also test that exact build through TestFlight on a physical compatible iPad after deleting any previous installation; a simulator install does not fully reproduce App Store installation validation.

If every bundle contains only compatible values, reply without another speculative binary change. Attach the plist output for all bundles, identify the submitted build number and request the exact bundle identifier and installation error that failed on Apple’s device. Since arm64 is valid for the stated review device, the rejection may be using a generic template for a different packaging or installation problem.

Answer 2

lucioduran OP

3w

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?