ILLINK errors when compiling MAUI apps on Mac - says targeting version that I'm not

[sumowesley]

Description

When trying to compile an app from within VS Code or outside, I get the following:
ILLINK : warning MT0079: The recommended Xcode version for Microsoft.MacCatalyst 18.0.8303 is Xcode 16.0 or later. The current Xcode version (found in /Applications/Xcode-15.4.0.app/Contents/Developer) is 15.4. [/Users/Shared/develop/Messing/RunTester/RunTester.csproj::TargetFramework=net8.0-maccatalyst]
ILLink : unknown error IL7000: An error occurred while executing the custom linker steps. Please review the build log for more information. [/Users/Shared/develop/Messing/RunTester/RunTester.csproj::TargetFramework=net8.0-maccatalyst]
ILLINK : error MT0180: This version of Microsoft.MacCatalyst requires the MacCatalyst 18.0 SDK (shipped with Xcode 16.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only in your project's iOS Build Options > Linker Behavior (to try to avoid the new APIs). [/Users/Shared/develop/Messing/RunTester/RunTester.csproj::TargetFramework=net8.0-maccatalyst]
ILLINK : error MT2301: The linker step 'Setup' failed during processing: This version of Microsoft.MacCatalyst requires the MacCatalyst 18.0 SDK (shipped with Xcode 16.0). Either upgrade Xcode to get the required header files or set the managed linker behaviour to Link Framework SDKs Only in your project's iOS Build Options > Linker Behavior (to try to avoid the new APIs). [/Users/Shared/develop/Messing/RunTester/RunTester.csproj::TargetFramework=net8.0-maccatalyst]
/Users/karlsouthern/.nuget/packages/microsoft.net.illink.tasks/8.0.8/build/Microsoft.NET.ILLink.targets(87,5): error NETSDK1144: Optimizing assemblies for size failed. Optimization can be disabled by setting the PublishTrimmed property to false. [/Users/Shared/develop/Messing/RunTester/RunTester.csproj::TargetFramework=net8.0-maccatalyst]
1 Warning(s)
4 Error(s)

I'm targeting MacCatalyst 13.1 by default

Steps to Reproduce

1. Create a new MAUI app: dotnet new maui -n RunTester
2. Change directory and run: dotnet build -t:Run -f net8.0-maccatalyst
3. read and weep when you see the ILLINK errors

Link to public reproduction project repository

No response

Version with bug

8.0.82 SR8.2

Is this a regression from previous behavior?

Yes, this used to work in .NET MAUI

Last version that worked well

8.0.82 SR8.2

Affected platforms

iOS, macOS

Affected platform versions

Mac 14.6.1, DotNet 8.0.304, Xcode 15.4, Workloads 8.0.82/8.0.100

Did you find any workaround?

No, although I could run an iOS app by connecting from Visual Studio on Windows, connecting to my Mac and running it remotely

Relevant log output

See above

[sumowesley]

I should add that I have removed and added the MAUI workloads again

[sumowesley]

I've just performed a workload update on my x64 iMac and am in the same predicament; I'm on a Sonoma 14.6.1 platform, Xcode 15.4 as the default, dotnet 8.0.304, maui workload 8.0.82/8.0.100. Is it safe to assume that the only way forward is to install Xcode 16 and upgrade dotnet to 8.0.402? (Edited: removed need to upgrade to Sequoia)

[sblom]

I'm worried that I just painted myself into the same corner.

[HobDev]

Unable to develop on Mac due to exact same error

[HobDev]

I've just performed a workload update on my x64 iMac and am in the same predicament; I'm on a Sonoma 14.6.1 platform, Xcode 15.4 as the default, dotnet 8.0.304, maui workload 8.0.82/8.0.100. Is it safe to assume that the only way forward is to upgrade to Sequoia, install Xcode 16 and upgrade dotnet to 8.0.402?

as per the document over here the supported version of Xcode is 15.4

[sumowesley]

as per the document over here the supported version of Xcode is 15.4

@HobDev, indeed so. I was surprised to be told I needed v16, especially as I'm targeting iOS 17.5 and Mac Catalyst 13.1, neither of which need Xcode 16.

[sumowesley]

I can confirm that I can compile again by upgrading to Xcode 16 with Dotnet 8.0.402.

[jaysidri]

We've encountered the same issue on our devops pipe building an iOS app that worked fine on Thursday but is now failing.

We currently target iOS 17. Using macos-13 agent, dotnet sdk 8.0.204, XCode 15.2.

How can this fail when we have made no changes to the configuration or code?

The error:

`
ILLink : iOS error IL7000: An error occurred while executing the custom linker steps. Please review the build log for more information. [/Users/runner/work/1/s/xxx/xxx.csproj::TargetFramework=net8.0-ios]
/Users/builder/azdo/_work/1/s/xamarin-macios/src/build/dotnet/ios/generated-sources/UIKit/UITextField.g.cs(823): error MT4162: The type 'UIKit.NSAdaptiveImageGlyph' (used as a parameter in UIKit.UITextField.InsertAdaptiveImageGlyph) is not available in iOS 17.2 (it was introduced in iOS 18.0). Please build with a newer iOS SDK (usually done by using the most recent version of Xcode). [/Users/runner/work/1/s/xxx/xxx.csproj::TargetFramework=net8.0-ios]

/Users/builder/azdo/_work/1/s/xamarin-macios/src/build/dotnet/ios/generated-sources/UIKit/UITextView.g.cs(773): error MT4162: The type 'UIKit.NSAdaptiveImageGlyph' (used as a parameter in UIKit.UITextView.InsertAdaptiveImageGlyph) is not available in iOS 17.2 (it was introduced in iOS 18.0). Please build with a newer iOS SDK (usually done by using the most recent version of Xcode). [/Users/runner/work/1/xxx.csproj::TargetFramework=net8.0-ios]

ILLINK : error MT2362: The linker step 'ClassHandleRewriter' failed during processing: One or more errors occurred. (The type 'UIKit.NSAdaptiveImageGlyph' (used as a parameter in UIKit.UITextField.InsertAdaptiveImageGlyph) is not available in iOS 17.2 (it was introduced in iOS 18.0). Please build with a newer iOS SDK (usually done by using the most recent version of Xcode). [/Users/runner/work/1/s/xxx/xxx.csproj::TargetFramework=net8.0-ios]
) (The type 'UIKit.NSAdaptiveImageGlyph' (used as a parameter in UIKit.UITextView.InsertAdaptiveImageGlyph) is not available in iOS 17.2 (it was introduced in iOS 18.0). Please build with a newer iOS SDK (usually done by using the most recent version of Xcode).
)

`

[EddyCwdry]

We've encountered the same issue on our devops pipe building an iOS app that worked fine on Thursday but is now failing.

We do not target iOS 18. Using macos-13, dotnet sdk 8.0.204, XCode 15.4.

How can this be failing when we made no changes to the config or code?

@jaysidri This has been happening since about 2 days ago for us, I hoped over the weekend someone else would have fixed it. Best I can tell the dotnet install maui is installing newer versions and now these errors are happening

[jaysidri]

@EddyCwdry Yeah, looks like someone's pushed something they ought not to. Long weekend where I'm located but this was certainly building ok last week and now everything's broken. It's a great way to start the week :)

I'm also seeing this on my logs:

ILLINK : warning MT0079: The recommended Xcode version for Microsoft.iOS 18.0.8303 is Xcode 16.0 or later. The current Xcode version (found in /Applications/Xcode_15.2.app/Contents/Developer) is 15.2. [/Users/runner/work/1/s/xxx/xxx.csproj::TargetFramework=net8.0-ios]

The version of MAUI my project references:

    <PackageReference Include="Microsoft.Maui.Controls" Version="8.0.70" />

..which ought to build with Microsoft.iOS 17.2.8078 according to https://github.com/dotnet/maui/wiki/Release-Versions but somehow managed to pull down 18.0.8303 (!).

[jaysidri]

I realise this was raised for broken builds for Mac but I have the same issue on iOS this morning and got the build to work by:

1. Updating build to use .NET SDK 8.0.402 (for workload sets support) -- see: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-workload-sets

2. "Pin" the version when installing workload: dotnet workload install maui android ios --version 8.0.402.0

I'm now able to build this using Xcode 15.4 and macos-14 agent

[EddyCwdry]

@jaysidri thank you! pinning the workload version did the trick for me too.

[jfversluis]

Looks like the author and other people have managed to fix this, great work and thanks for the help here everyone!

Best spot right now is indeed to update to all the latest bits of everything. Pinning a workload set is now really easy and a great idea for CI pipelines so that it doesn't update without you knowing when the build agents are not under your control.

[TiberiusDRAIG]

@jfversluis I'm not sure this should be closed, should it? Isn't the issue here that MAUI doesn't support XCode 16 in .NET 8 but the latest workloads are forcing a version of Microsoft.MacCatalyst that requires it. Pinning to older workloads feels like a stop-gap, but should the workload issue itself not be resolved if this is never going to be supported in .NET 8?

[jfversluis]

If you want to build against Xcode 15 you can use the 8.0.402.0 version as mentioned above. If you want to use Xcode 16 you can use 8.0.402.1. So depending on what your requirements are today you can choose one of both. Both work with .NET 8 today so I'm not sure what else there is to do

[TiberiusDRAIG]

@jfversluis I've just gone back and checked the .NET 8 XCode situation with MAUI as the way that has been handled is where I was confused; originally the tickets indicated that support for XCode 16 would not be coming to .NET 8, so our dev team is currently still sitting on Sonoma on the Macs using XCodes to pin to 15.4. I appreciate this is now off-topic, but is there somewhere I should have been looking for an announcement on that? I see there's a new community stand-up from yesterday that I haven't watched yet so maybe it's covered there.

Just so I'm clear, are we safe to update to Sequoia and XCode 16 with .NET 8 MAUI now?

[jfversluis]

I think it is mentioned in the community standup and also in the pinned issue we have on this repo for it: #24819

[TiberiusDRAIG]

Okay, thanks - I will watch the community stand up this evening after work. I guess the problem is that we were explicitly told originally that it wasn't coming to .NET 8, so we had resigned ourselves to being stuck on Sonoma until .NET 9, therefore had no reason to come back and check because there was no indication Microsoft's position was going to change, then I hit this issue a few minutes ago on DevOps Pipelines and it completely threw me.

Anyway, if it works that's all I care about - thanks for clarifying @jfversluis! 😎