iOS project error: IL Trimmer has encountered an unexpected error.

Debugging my old iOS .NET 9.0 project on my iPad Air worked in Visual Studio Community 2022.

After that I opened the project in Visual Studio Community Insiders and tried to debug the project but then I always get this error:

IL Trimmer has encountered an unexpected error. Please report the issue at https://aka.ms/report-illink The file "obj\Debug\net9.0-ios\ios-arm64\linked\Link.semaphore" cannot be created. Could not find a part of the path 'C:\Users\Kim Strasser\source\repos\IOSTest\IOSTest\obj\Debug\net9.0-ios\ios-arm64\linked\Link.semaphore'.

Then I have tried to change Manual Provisioning to Automatic Provisioning. But with Automatic Provisioning I get this error:

Automatic Provisioning is enabled but no account was selected. Please select a team or switch to Manual Provisioning from the iOS Bundle Signing page.

I have tried Clean and Rebuild Everything and Disable Linking Temporarily(I changed Link Framework SDKs only to Don´t Link) but I still get the same errors. And I have run dotnet workload install ios in VS Insiders Terminal but I still get the same errors.

Changing <TargetFramework>net9.0-ios</TargetFramework> to <TargetFramework>net8.0-ios</TargetFramework> is not working, I get this error in VS Insiders when I change to .NET 8.0:

There is no application host available for the specified RuntimeIdentifier 'ios-arm64'.

In addition, I have tried to create a new iOS project in VS Insiders 11123.170 and there is the same problem with my Apple developer account when I choose Automatic Provisioning.

I changed to Automatic Provisioning and then I can choose between Configure Automatic Provisioning and Manage Accounts.

But I had already downloaded my Apple developer profiles before in Tools-->Options-->.NET MAUI-->Apple-->Accounts-->Configure-->View Details-->Download All Profiles.

Why are my Apple developer profiles not displayed in iOS Bundle signing when I choose Automatic Provisioning? The profiles are displayed when I choose Manual Provisioning.

Hello @Kim Strasser !

Here are the guideline fix error you're having following:

IL Trimmer / Link.semaphore error

Visual Studio 2026 Insiders uses updated .NET 9 iOS workloads and linker behavior. Old projects created in VS 2022 may reference intermediate paths that no longer exist. That’s why the build system fails to create obj\Debug\net9.0-ios\ios-arm64\linked\Link.semaphore. You can try:

• Delete the entire bin and obj folders before building in Insiders.
• Run dotnet workload repair (not just install) to ensure the iOS workload is aligned with your Insiders SDK.
• Compare your .csproj with a new Insiders iOS project and align <TargetFramework> and <RuntimeIdentifier>.
• If the error persists, then it’s a known regression in some Insiders builds, this has acknowledged in Developer Community. Refer: https://developercommunity.visualstudio.com/t/Can-no-longer-build-the-net90-ios-targe/10925303

Automatic Provisioning error

Automatic Provisioning requires your Apple Developer account to be added and a team selected, this must be done explicitly before your provision, see: https://learn.microsoft.com/en-us/dotnet/maui/ios/device-provisioning/automatic-provisioning?view=net-maui-9.0. In VS 2022 you may have already configured this, but Insiders has its own account store.

• Go to Tools → Options → Apple Accounts (or Manage Accounts from the provisioning dialog).
  • Add your Apple ID and sign in.
  • Once added, select your team under iOS Bundle Signing → Team.
  • Then choose Configure Automatic Provisioning to let VS generate the provisioning profile.

TargetFramework mismatch: Insiders builds are forward-looking and may not include the .NET 8 iOS runtime packs anymore. That’s why you see “no application host available for ios-arm64”. Stick with net9.0-ios in Insiders.

For stability: Continue using VS 2022 for production/debugging until Insiders stabilizes.
For Insiders testing:

• Create a new iOS project in Insiders.
  • Add your Apple account and configure provisioning.
  • Migrate your code/assets from the old project into the new one.
  • Keep net9.0-ios as the target.

I hope this help resolve your issues! Please let me know if you stuck anywhere!

It´s not working. I still get the same error. There is no <RuntimeIdentifier> in my iOS .csproj file.

I have tried to debug a different iOS project in Visual Studio 2022. Debugging of the project worked a few weeks ago on my iPad Air but now it´s not working anymore: Error MT1006: Could not install the application The identity used to sign the executable is no longer valid. - Microsoft Q&A

I use Manual Provisioning and a new Signing identity and Provisioning profile in both Visual Studio 2022 and Visual Studio Insiders, they are the same in both projets. I can debug my project on my iPaid Air in VS 2022 but in VS Insiders I get still the same IL Trimmer error when I click on Rebuild.

I had not copied everything from my VS 2022 .csproj file to my VS Insiders .csproj file when I created the VS Insiders project, but the files in the projects are the same. In addition, the VS Insiders iOS project properties are the default properties, I had not changed them, but it is possible that the VS 2022 iOS project properties are not exactly the same. But the iOS Bundle signing properties are the same in each project.

Hello @Kim Strasser !

Since this issue has been reported multiple times in 2025 and remains open without a full resolution in the current Insiders builds as of October 31, 2025.

It manifests as the trimmer failing early in the build process, which prevents the linked directory from being created—leading to the follow-up semaphore file error. The fact that it works in VS 2022 (stable, typically on mature .NET 8 or earlier) but not Insiders highlights the preview nature of the build, where .NET 9/10 SDK integrations and the IL linker (ILLINK) are still being refined.

Your new project in Insiders replicating the issue rules out most .csproj migration problem. Please refer: https://github.com/dotnet/runtime/issues/119495.

Here are some workarounds I can give:

Disable IL Trimming

You can disable IL trimming and publishing trim to skip the problematic trimmer step for Debug builds. Edit your .csproj file and add these properties inside the <PropertyGroup> for your Debug configuration (e.g., under Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'"):

<PublishTrimmed>False</PublishTrimmed>
<TrimMode>None</TrimMode>
<EnableAssemblyILStripping>False</EnableAssemblyILStripping>

If it works, re-enable for Release builds once fixed. This has resolved similar errors in .NET 9 previews for iOS/MAUI projects.

Manually Create the Missing Directory Path 

You can create a new folder named linked in your obj\Debug\net9.0-ios\ios-arm64\ and rebuild the solution. If the trimmer proceeds, it should generate the file inside.

Fallback to .NET 8 Targeting with Workload Repair

Since downgrading to net8.0-ios failed with the "no application host" error (common in Insiders due to incomplete .NET 8 packs), try repairing the workloads first:  

dotnet workload restore
dotnet workload repair

Install the .NET 8 SDK manually from https://dotnet.microsoft.com if not present (check with dotnet --list-sdks). If using a remote Mac build host, verify the .NET 8 SDK is also installed there. Then edit .csproj: Change <TargetFramework>net9.0-ios</TargetFramework> to <TargetFramework>net8.0-ios</TargetFramework>. Restore NuGet packages, clean/rebuild, and debug. This aligns with your working VS 2022 setup and avoids .NET 9 bugs.

If these don't resolve it, you can report your case at https://aka.ms/report-illink (as the error prompts) with full build logs (Output window > Build, set to Diagnostic verbosity via Tools > Options > Projects and Solutions > Build and Run), your exact VS build number, .NET SDK versions on Windows/Mac, and note it's reproducible in a new project. Include that it works in VS 2022. Microsoft is tracking similar issues on GitHub

For MAUI projects, check the .NET MAUI migration guide for any .NET 9-specific steps. Monitor Visual Studio release notes for future Insiders updates that might address this.

I hope this helps!

Hello @Kim Strasser !

Haven't heard from you for a while! I hope everything worked out as expected, if you still need any help, feel free to ping back any time!

If you agree with my suggestion, kindly mark this as final answer to your question, thank you!

iOS projects must build with PublishTrimmed=true. Current value: False. Set 'MtouchLink=None' instead to disable trimming for all assemblies.

I get this error when I use this configuration:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <PublishTrimmed>False</PublishTrimmed>
  <MtouchLink>None</MtouchLink>
  <TrimMode>None</TrimMode>
  <EnableAssemblyILStripping>False</EnableAssemblyILStripping>
  </PropertyGroup>

And I have tried with the following configuration but then I get the previous error again.

IL Trimmer has encountered an unexpected error.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <MtouchLink>None</MtouchLink>
  <TrimMode>None</TrimMode>
  <EnableAssemblyILStripping>False</EnableAssemblyILStripping>
  </PropertyGroup>

.NET 9.0.306 sdk and .NET 10.0.100-rc.2.25502.107 sdk are installed.

Hello @Kim Strasser !

Since you remove PublishTrimmed, but setting TrimMode=None is invalid. The TrimMode only supports values like partial (default for iOS device builds) or full. An invalid value causes the IL Trimmer (linker) to fail with an unexpected error. Remove TrimMode entirely unless you need to explicitly set it to partial or full.

Additionally, your PropertyGroup condition uses Debug|AnyCPU, which typically applies to Android or Windows builds in .NET MAUI projects. For iOS, use a condition that targets the iOS framework (e.g., net9.0-ios or net10.0-ios, depending on your project's TargetFrameworks) and the appropriate platform (e.g., iPhoneSimulator for debug builds). This ensures the settings apply correctly during iOS builds.

You can add this configuration into yours (adjust net9.0-ios if your project targets net10.0-ios instead):

<PropertyGroup Condition="'$(TargetFramework)'=='net9.0-ios' And '$(Configuration)'=='Debug'">
  <MtouchLink>None</MtouchLink> <!--Disables linking/trimming for all assemblies, as recommended by the error message.-->
  <EnableAssemblyILStripping>False</EnableAssemblyILStripping>
</PropertyGroup>

After updating, clean and rebuild the project again. If you're building for a physical iOS device (not simulator), note that partial trimming is default and recommended for performance/size—only disable if you have compatibility issues with libraries. If the IL Trimmer error persists, it may indicate an incompatibility with a NuGet package; try updating packages or isolating by temporarily removing them.

I still get the same error when I use this code for the debug configuration in VS Insiders Version 11201.2. I have not tested the release configuration.

  <PropertyGroup>
    <TargetFramework>net9.0-ios</TargetFramework>
    <OutputType>Exe</OutputType>
    <SupportedOSPlatformVersion>15.0</SupportedOSPlatformVersion>
    <CodesignKey>iPhone Developer: Kim Strasser (...)</CodesignKey>
    <CodesignProvision>MyProject Profile Development</CodesignProvision>
    <ProvisioningType>manual</ProvisioningType>
  </PropertyGroup>
  <PropertyGroup Condition="'$(TargetFramework)'=='net9.0-ios' And '$(Configuration)'=='Debug'">
  <MtouchLink>None</MtouchLink> <!--Disables linking/trimming for all assemblies, as recommended by the error message.-->
  <EnableAssemblyILStripping>False</EnableAssemblyILStripping>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
  <CreatePackage>true</CreatePackage>
  <MtouchLink>SdkOnly</MtouchLink>
  <DebugType>portable</DebugType>
  <MtouchDebug>true</MtouchDebug>
  <Optimize>true</Optimize>
  <UseLlvm>false</UseLlvm>
  <MtouchExtraArgs>--enable-detailed-crash-reports</MtouchExtraArgs>
  </PropertyGroup>

Hello!

Since those troubleshooting steps are all I can provide, if the problem still persists, this might be a regression issue. I will escalate it for further investigation and respond to you once it's resolved. Thank you!