.NET iOS regression: dotnet build before dotnet publish adds stale .dll and .aotdata files to the final app bundle payload

[viniciusjarina]

Apple platform

iOS

Framework version

net10.0-*

Affected platform version

.NET SDK 10.0.300 and iOS workload 26.5.10284

Description

This appears to be a regression in the .NET iOS workload.

For an iOS app targeting net10.0-ios, running dotnet publish directly produces the expected smaller app bundle.

However, if dotnet build is run first, and then dotnet publish is run on the same project with the same configuration and RID, the final .app / .ipa incorrectly includes extra managed assemblies and *.aotdata.arm64 files in the app bundle.

This significantly increases the final app size and changes the published payload contents, even though publish should produce the same final bundle regardless of whether build was run beforehand.

The behavior looks like dotnet publish is reusing stale outputs left by dotnet build and is not cleaning those files from the app bundle before creating the final IPA.

I noticed this seeing that the size of iOS artifacts were much bigger when compared with previous builds.

Steps to Reproduce

Using a minimal iOS app (iOSTest.csproj):

1. Clean outputs.
2. Run:

dotnet restore /Users/viniciusjarina/projects/iOSTest/iOSTest.csproj -r ios-arm64
dotnet build -c Release -r ios-arm64 /Users/viniciusjarina/projects/iOSTest/iOSTest.csproj
dotnet publish -c Release -r ios-arm64 -p:ArchiveOnBuild=true -p:BuildIpa=true /Users/viniciusjarina/projects/iOSTest/iOSTest.csproj

3. Inspect:

/Users/viniciusjarina/projects/iOSTest/bin/Release/net10.0-ios/ios-arm64/iOSTest.app

4. Clean outputs again.
5. Run only:

dotnet restore /Users/viniciusjarina/projects/iOSTest/iOSTest.csproj -r ios-arm64
dotnet publish -c Release -r ios-arm64 -p:ArchiveOnBuild=true -p:BuildIpa=true /Users/viniciusjarina/projects/iOSTest/iOSTest.csproj

6. Inspect the same app bundle and compare contents.

Expected behavior

Running dotnet build before dotnet publish should not change the final published app bundle contents.

The final .app / .ipa should match the publish-only result and should not contain stale managed assemblies or .aotdata files.

Actual behavior

After dotnet build -> dotnet publish, the app bundle contains extra files that are not present in the publish-only output.

On the minimal repro app, these extra files are:

Microsoft.iOS.aotdata.arm64
Microsoft.iOS.dll
System.ComponentModel.TypeConverter.aotdata.arm64
System.ComponentModel.TypeConverter.dll
System.Drawing.Primitives.aotdata.arm64
System.Drawing.Primitives.dll
System.Drawing.aotdata.arm64
System.Drawing.dll
System.ObjectModel.aotdata.arm64
System.ObjectModel.dll
System.Private.CoreLib.aotdata.arm64
System.Private.CoreLib.dll
System.Runtime.aotdata.arm64
System.Runtime.dll
aot-instances.aotdata.arm64
iOSTest.aotdata.arm64
iOSTest.dll

Bundle comparison from the repro app:

• build -> publish: 26 files, 5,539,028 bytes
• publish only: 9 files, 2,986,340 bytes

Regression?

Yes, likely.

Known-good CI evidence from 2026-04-07:

• .NET SDK: 10.0.201
• iOS workload: 26.2.10217
• Host: osx-x64

That CI build ran dotnet build before dotnet publish and still produced a small IPA.

Known-bad evidence:

• local repro with SDK 10.0.201 / 10.0.202 using iOS workload 26.2.10233
• local repro with SDK 10.0.300 using iOS workload 26.5.10284

This suggests the regression may have been introduced between:

• 26.2.10217 (good)
• 26.2.10233 (bad)

Environment

Minimal repro environment:

.NET SDK:
Version: 10.0.300
Workload version: 10.0.300-manifests.2db5797b

Installed workloads:
ios 26.5.10284/10.0.100
maccatalyst 26.5.10284/10.0.100
macos 26.5.10284/10.0.100
tvos 26.5.10284/10.0.100

Additional notes

This also reproduces on a larger real project, but the minimal iOSTest repro is enough to demonstrate the problem clearly.

Relevant workload source area:

It appears _CoreCreateIpa packages the existing app bundle as-is, while stale files left by the earlier build step are still present in AppBundleDir and are not removed before publish/package.

Did you find any workaround?

Avoid call dotnet build before call dotnet publish

Build logs

Binlogs.zip

[kerams]

This is what caused #25443.

• Build a project in Release with <UseMonoRuntime>false</UseMonoRuntime> for Remote Device in VS
• Switch to <UseMonoRuntime>true</UseMonoRuntime>, dotnet publish connecting to a Mac
• Significantly inflated IPA archive contains CoreCLR files

[rolfbjarne]

Part of the reason for this is that dotnet publish is really implemented as dotnet build + "zip up the result".

Another part is that we don't keep track of which existing files are still needed and which aren't during the build (so we can't tell which files can be deleted because they're outdated).

This typically shouldn't cause a problem when the build configuration is exactly the same between dotnet build and dotnet publish (in which case the output should be exactly the same, and there would be no outdated files), but I suspect a default build setting differs and that causes this.

In any case I'll have a look and see what I can found out.

[viniciusjarina]

But this happens with a blank “dotnet new ios” app 😕