Unsupported Architectures during upload to store

Hi @Natalie van Gogh ,

Thank you for sharing the details and the steps you have already taken. I understand how frustrating a persistent issue like this can be. Let us use your findings to narrow down the cause.

The immediate issue is that libSkiaSharp.framework inside the IPA contains an unexpected x86_64 architecture, which is typically associated with Intel-based simulator builds rather than physical iOS devices. I suggest investigating this architecture issue first, then checking whether the PIE, segment alignment, and encryption errors remain.

Because each .NET for iOS workload requires a specific Xcode version, it would be helpful to confirm the exact SDK, workload, and active Xcode combination. Also, “latest SDK and workload” may not necessarily reflect the versions currently selected for the project, as these can be influenced by a global.json file or workload-set configuration.

Could you run the following commands from the MAUI project directory and share the output?

dotnet –version 
dotnet –info 
dotnet workload list 
dotnet workload –info 
xcodebuild –version 
xcode-select –p 

Please also share:

The iOS target framework from the .csproj

The SkiaSharp package versions

Any RuntimeIdentifier or RuntimeIdentifiers entries

The contents of global.json, if present

As a diagnostic test, you can then rebuild the MAUI application project explicitly for ios-arm64:

dotnet publish <your-project.csproj> \ 
-f <your-ios-target-framework> \ 
-c Release \ 
-p:RuntimeIdentifier=ios-arm64 \ 
-p:ArchiveOnBuild=true 

Before uploading the new IPA, extract it and inspect the native binary:

lipo -info Payload/VeloDS.app/Frameworks/libSkiaSharp.framework/libSkiaSharp 

If it reports only arm64, try uploading the new IPA and check whether the remaining validation errors persist.

If it still reports arm64 and x86_64, please share the command outputs, project configuration, SkiaSharp versions, and new lipo result so we can investigate the native package assets selected during the build.

For now, I would avoid updating or changing additional components until the current environment has been captured.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

I think App Store only accepts the device‑safe arm64 slice, and x86_64 in the ipa stops the upload every time, so unzip it and run lipo -info to make sure libSkiaSharp shows arm64 only. and when x86_64 keeps showing up, it means the build picked the simulator slice of SkiaSharp, so publish with RuntimeIdentifier=ios-arm64 in a clean folder to force the correct native assets.

The root cause is almost certainly not SkiaSharp itself — it's that your dotnet publish picked up the simulator slice (x86_64) instead of the device slice (arm64). This is a common side effect after upgrading Xcode to 26.6/27 and pulling a fresh .NET for iOS workload.

Here's what to check, in order:

1. Active Xcode. You have both Xcode 26.6 and 27 installed. Each .NET for iOS workload is validated against a specific Xcode version. If the workload targets 26.x but xcode-select points to 27, the build can produce garbage. Run:

xcode-select -p

Make sure the active Xcode matches the one your workload was built for.

2. Explicitly set the RuntimeIdentifier on publish. This is the key step. Without it, publish may pull simulator assets:

dotnet publish <your-project.csproj> \

Per the official docs, ios-arm64 is the correct RID for a release IPA.

3. Inspect the IPA after building. Unzip and run lipo:

lipo -info Payload/VeloDS.app/Frameworks/libSkiaSharp.framework/libSkiaSharp

If it still shows x86_64, the build is stubbornly pulling the simulator package. In that case, do a clean and rebuild in a fresh folder (no leftover obj/bin). Stale intermediate artifacts can drag in the wrong slice.

4. Check global.json and RuntimeIdentifier in the csproj. If the project hardcodes <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier> or a global.json pins an old SDK, that will override the command line. Remove anything stale.

5. SkiaSharp / workload mismatch. If after forcing ios-arm64 lipo still reports a fat binary containing x86_64, the version of SkiaSharp.Views.Maui.Controls you're using may not ship a clean arm64 device asset for your iOS target framework. Check the package version and try rolling back to the previous stable release.

The other errors (PIE, Invalid Segment Alignment, LC_ENCRYPTION_INFO) are almost always downstream of the first one — once x86_64 is gone from the IPA, they should disappear. Don't change anything else until lipo -info reports arm64 only.

The issue fixed by removing the x86_64 architecture from the SkiaSharp package in the NuGet location on the Mac machine.

Step 1: goto skiasharp.nativeassests.ios location -

        cd ~/.nuget/package/skiasharp.nativeassests.ios

Step 2: cd <skiasharp_version>

Step 3: cd runtime/ios/native/libskiaSharp.framework

Step 4: lipo -remove x86_64 libskiasharp -o libSkiaSharp

And then publish the ios application again:

dotnet publish YOUR_APP.csproj -f net10.0-ios -c Release -p:ArchiveOnBuild=true -p:RuntimeIdentifier=ios-arm64