Unsupported Architectures during upload to store

Hi @Natalie van Gogh ,

Thank you for sharing your final solution.

Here are some additional insights, the key finding here is that setting the project to ios-arm64 alone did not remove the x86_64 slice from the packaged libSkiaSharp.framework. Your lipo result still reported both x86_64 and arm64.

Your workaround addresses that remaining architecture directly as part of the iOS Release build.

Keep the Release build targeted to arm64

The project can remain explicitly configured for the iOS device runtime:

<PropertyGroup Condition="$(TargetFramework.Contains('-ios')) and '$(Configuration)' == 'Release'">
      <Platforms>arm64</Platforms>
      <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
      <ArchiveOnBuild>true</ArchiveOnBuild>
      <BuildIpa>true</BuildIpa>
</PropertyGroup>

Microsoft's MAUI publishing guidance uses ios-arm64 as the Runtime Identifier when publishing an iOS application for device/App Store distribution.

Remove the remaining x86_64 slice during the Release build

Since libSkiaSharp.framework was still being packaged with both architectures, the additional build target uses lipo to inspect the framework and remove x86_64:

<Target Name="StripSkiaSimulatorSlice" Condition="$(TargetFramework.Contains('-ios')) and '$(Configuration)' == 'Release'">
       <Exec Command="xcrun lipo -info &quot;$(AppBundleDir)/Frameworks/libSkiaSharp.framework/libSkiaSharp&quot;" />
       <Exec Command="xcrun lipo -remove x86_64 &quot;$(AppBundleDir)/Frameworks/libSkiaSharp.framework/libSkiaSharp&quot; -output &quot;$(AppBundleDir)/Frameworks/libSkiaSharp.framework/libSkiaSharp&quot; || true" />
       <Exec Command="xcrun lipo -info &quot;$(AppBundleDir)/Frameworks/libSkiaSharp.framework/libSkiaSharp&quot;" />
</Target>

This directly removes the architecture identified by the App Store validation error while leaving the required arm64 slice in the framework. In your case, this was necessary because explicitly publishing with ios-arm64 had still produced a framework containing both architectures.

Run the target as part of the signing flow

Adding the target to CodesignDependsOn makes the workaround part of the Release build process:

<CodesignDependsOn>
       $(CodesignDependsOn);StripSkiaSimulatorSlice
</CodesignDependsOn>

This is particularly useful in your scenario because the adjustment is made to the framework included in the iOS build rather than modifying the SkiaSharp package in the local NuGet cache. You had specifically noted that you did not want to modify the NuGet package because the same machine is also used to build the Android version.

So, in summary, the approach is:

Release iOS build 

↓ 

Target ios-arm64 

↓ 

Inspect packaged libSkiaSharp 

↓ 

Remove remaining x86_64 slice 

↓ 

Verify the resulting architecture 

↓ 

Continue with code signing / IPA generation 

Thank you again for taking the time to share your findings with the community. If you found my explanation was helpful or informative to your solution, I would greatly appreciate it if you could follow this guide so others with the same issue can benefit as well.

Thank you.

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.

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

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.

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.