Microsoft.AppCenter.Crashes clang++ exited with code 1 when compiling for ios-simulator on pair arm64 mac in VS for Windows

jsiemensLatitudegeo commented 1 year ago

Description

If you try to use the Microsoft.AppCenter.Crashes in a .net maui app in Visual Studio for Windows paired with an arm64 Mac, deploying to the ios simulator, then you get an error:

Severity Code Description Project File Line Suppression State Error clang++ exited with code 1: ld: in /Users/[user]/Library/Caches/Xamarin/mtbs/builds/MauiApp1/baf8b3e6a4f75682439ae911f842ade66bd1741bc02fc255b853516d938283c3/obj/Debug/net7.0-ios/iossimulator-x64/linker-cache/AppCenter.a(MSACAppCenter.o), building for iOS Simulator, but linking in object file built for iOS, file '/Users/[user]/Library/Caches/Xamarin/mtbs/builds/MauiApp1/baf8b3e6a4f75682439ae911f842ade66bd1741bc02fc255b853516d938283c3/obj/Debug/net7.0-ios/iossimulator-x64/linker-cache/AppCenter.a' for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) MauiApp1 C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk\16.4.7098\targets\Xamarin.Shared.Sdk.targets 1274

Repro Steps

Create new maui app in VS for Windows
Pair to Mac (arm64 - eg. m1 or m2)
Build and deploy to ios simulator

Details

What is your app platform (Xamarin.Android or Xamarin.iOS or UWP)?
- e.g. MAUI on all 3 platforms (Android, iOS and UWP).
If using Xamarin.Forms or if using portable/shared code to call our SDK APIs, are you using shared project, PCL code or .NET standard code for the application? Which .NET standard version or which PCL profile?
- e.g. Multitargeting
Which SDK version are you using?
- e.g. 5.0.2
Which OS version did you experience the issue on?
- e.g. iOS 16.4 Simulator
What device version did you see this error on? Were you using an emulator or a physical device?
- e.g. iPhone 14 Simulator running iOS 16.4
What third party libraries are you using?
- Just yours
Please enable verbose logging for your app using AppCenter.LogLevel = LogLevel.Verbose before your call to AppCenter.Start(...) and include the logs here:

AlexeyStarkov commented 8 months ago

@durandt valid guess about VSCode. Definitely worth to try this Lego-like notepad on steroids finally. I hope preparing it for work will take less than another two days.

When it comes to staying with .net7, upgrading to .net8 is my try to run away from other bugs/issues I have lost hope of overcoming.

durandt commented 8 months ago

I agree we really should be upgrading to .NET 8 asap (for a variety of reasons, some that you just mentioned). I was just mentioning that this issue is a pretty big blocker.

dmn-star commented 8 months ago

@AlexeyStarkov

However, the issue is still there when I target the Android. I mean, c'mon, why does iOS-related crap impact Android builds at all?!!!

Because there is not really an iOS or Android build here, just an all-in-one build for all targets. You can temporary delete net8.0-ios from the line in your project, if you only want to work on android part. <TargetFrameworks>net8.0;net8.0-android;net8.0-ios</TargetFrameworks>

asierpn commented 8 months ago

We had the same issue and with these project settings it works fine in both Debug and Release in our .NET8 iOS app (not MAUI).

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0-ios</TargetFramework>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>true</ImplicitUsings>
    <SupportedOSPlatformVersion>15.0</SupportedOSPlatformVersion>
    <EnableAssemblyILStripping>False</EnableAssemblyILStripping>
    <ProvisioningType>manual</ProvisioningType>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
    <MtouchLink>SdkOnly</MtouchLink>
    <CodesignKey>XXXX</CodesignKey>
    <CodesignProvision>XXXX</CodesignProvision>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
    <MtouchLink>SdkOnly</MtouchLink>
    <CodesignKey>XXXX</CodesignKey>
    <CodesignProvision>XXXX</CodesignProvision>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Maui.Essentials" Version="8.0.6" />
    <PackageReference Include="Microsoft.AppCenter.Analytics" Version="5.0.3" />
    <PackageReference Include="Microsoft.AppCenter.Crashes" Version="5.0.3" />
    <PackageReference Include="SQLitePCLRaw.bundle_green" Version="2.1.7" />
  </ItemGroup>
</Project>

AlexeyStarkov commented 8 months ago

@AlexeyStarkov

However, the issue is still there when I target the Android. I mean, c'mon, why does iOS-related crap impact Android builds at all?!!!

Because there is not really an iOS or Android build here, just an all-in-one build for all targets. You can temporary delete net8.0-ios from the line in your project, if you only want to work on android part. <TargetFrameworks>net8.0;net8.0-android;net8.0-ios</TargetFrameworks>

Sorry. It was a rhetorical question caused by Xamarin -> MAUI migration frustration.

AlexeyStarkov commented 8 months ago

We had the same issue and with these project settings it works fine in both Debug and Release in our .NET8 iOS app (not MAUI).

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0-ios</TargetFramework>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>true</ImplicitUsings>
    <SupportedOSPlatformVersion>15.0</SupportedOSPlatformVersion>
    <EnableAssemblyILStripping>False</EnableAssemblyILStripping>
    <ProvisioningType>manual</ProvisioningType>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
    <MtouchLink>SdkOnly</MtouchLink>
    <CodesignKey>XXXX</CodesignKey>
    <CodesignProvision>XXXX</CodesignProvision>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <RuntimeIdentifier>ios-arm64</RuntimeIdentifier>
    <MtouchLink>SdkOnly</MtouchLink>
    <CodesignKey>XXXX</CodesignKey>
    <CodesignProvision>XXXX</CodesignProvision>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Maui.Essentials" Version="8.0.6" />
    <PackageReference Include="Microsoft.AppCenter.Analytics" Version="5.0.3" />
    <PackageReference Include="Microsoft.AppCenter.Crashes" Version="5.0.3" />
    <PackageReference Include="SQLitePCLRaw.bundle_green" Version="2.1.7" />
  </ItemGroup>
</Project>

Your config looks promising because the following code snippet is the one that must resolve the problem no matter what target platform is chosen.

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>

however, I tried it yesterday and when the target platform is Android it leads to another error: "Microsoft.Android.Sdk.Tooling.targets(58, 5): [XA0035] Unable to determine the Android ABI from the value 'iossimulator-x64'. Edit the project file in a text editor and set the 'RuntimeIdentifiers' MSBuild property to contain only valid identifiers for the Android platform."

It makes sense of course, from the build system's point of view. But from my point of view, it means I need to look for a workaround for a workaround of a workaround.

ryanalford-suzy commented 8 months ago

Your config looks promising because the following code snippet is the one that must resolve the problem no matter what target platform is chosen.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
however, I tried it yesterday and when the target platform is Android it leads to another error: "Microsoft.Android.Sdk.Tooling.targets(58, 5): [XA0035] Unable to determine the Android ABI from the value 'iossimulator-x64'. Edit the project file in a text editor and set the 'RuntimeIdentifiers' MSBuild property to contain only valid identifiers for the Android platform."

It makes sense of course, from the build system's point of view. But from my point of view, it means I need to look for a workaround for a workaround of a workaround.

If you want to do iOS specific project configurations, you can use this...

<PropertyGroup Condition="$(TargetFramework.StartsWith('net8.0-ios')) != true AND $(TargetFramework.StartsWith('net8.0-maccatalyst')) != true">

</PropertyGroup>

Anything inside would be for Debug or Release on iOS or MacCatalyst. If you aren't supporting mac, then you can take that part off.

However, since we are talking about the simulator workaround mainly, this would probably work for you...

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)'=='Debug|net8.0-ios'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>

AlexeyStarkov commented 8 months ago

Your config looks promising because the following code snippet is the one that must resolve the problem no matter what target platform is chosen.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
however, I tried it yesterday and when the target platform is Android it leads to another error: "Microsoft.Android.Sdk.Tooling.targets(58, 5): [XA0035] Unable to determine the Android ABI from the value 'iossimulator-x64'. Edit the project file in a text editor and set the 'RuntimeIdentifiers' MSBuild property to contain only valid identifiers for the Android platform." It makes sense of course, from the build system's point of view. But from my point of view, it means I need to look for a workaround for a workaround of a workaround.
If you want to do iOS specific project configurations, you can use this...
<PropertyGroup Condition="$(TargetFramework.StartsWith('net8.0-ios')) != true AND $(TargetFramework.StartsWith('net8.0-maccatalyst')) != true">

</PropertyGroup>
Anything inside would be for Debug or Release on iOS or MacCatalyst. If you aren't supporting mac, then you can take that part off.

However, since we are talking about the simulator workaround mainly, this would probably work for you...
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)'=='Debug|net8.0-ios'">
  <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>

no, as I told above, it doesn't work (at least to me) because both Android and iOS are built no matter the target platform is chosen and iOS simulator error appears even when you try to build an app for android.

ryanalford-suzy commented 8 months ago

Your config looks promising because the following code snippet is the one that must resolve the problem no matter what target platform is chosen.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
however, I tried it yesterday and when the target platform is Android it leads to another error: "Microsoft.Android.Sdk.Tooling.targets(58, 5): [XA0035] Unable to determine the Android ABI from the value 'iossimulator-x64'. Edit the project file in a text editor and set the 'RuntimeIdentifiers' MSBuild property to contain only valid identifiers for the Android platform." It makes sense of course, from the build system's point of view. But from my point of view, it means I need to look for a workaround for a workaround of a workaround.
If you want to do iOS specific project configurations, you can use this...
<PropertyGroup Condition="$(TargetFramework.StartsWith('net8.0-ios')) != true AND $(TargetFramework.StartsWith('net8.0-maccatalyst')) != true">

</PropertyGroup>
Anything inside would be for Debug or Release on iOS or MacCatalyst. If you aren't supporting mac, then you can take that part off. However, since we are talking about the simulator workaround mainly, this would probably work for you...
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)'=='Debug|net8.0-ios'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
no, as I told above, it doesn't work (at least to me) because both Android and iOS are built no matter the target platform is chosen and iOS simulator error appears even when you try to build an app for android.

Your project code from a couple posts above is putting the simulator runtime identifier for any DEBUG build...so it will be included for both iOS and Android. So yeah, I could see you getting your issue because you are telling the build system to include the simulator runtime identifier on android also.

AlexeyStarkov commented 8 months ago

Your config looks promising because the following code snippet is the one that must resolve the problem no matter what target platform is chosen.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
however, I tried it yesterday and when the target platform is Android it leads to another error: "Microsoft.Android.Sdk.Tooling.targets(58, 5): [XA0035] Unable to determine the Android ABI from the value 'iossimulator-x64'. Edit the project file in a text editor and set the 'RuntimeIdentifiers' MSBuild property to contain only valid identifiers for the Android platform." It makes sense of course, from the build system's point of view. But from my point of view, it means I need to look for a workaround for a workaround of a workaround.
If you want to do iOS specific project configurations, you can use this...
<PropertyGroup Condition="$(TargetFramework.StartsWith('net8.0-ios')) != true AND $(TargetFramework.StartsWith('net8.0-maccatalyst')) != true">

</PropertyGroup>
Anything inside would be for Debug or Release on iOS or MacCatalyst. If you aren't supporting mac, then you can take that part off. However, since we are talking about the simulator workaround mainly, this would probably work for you...
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)'=='Debug|net8.0-ios'">
  <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
no, as I told above, it doesn't work (at least to me) because both Android and iOS are built no matter the target platform is chosen and iOS simulator error appears even when you try to build an app for android.
Your project code from a couple posts above is putting the simulator runtime identifier for any DEBUG build...so it will be included for both iOS and Android. So yeah, I could see you getting your issue because you are telling the build system to include the simulator runtime identifier on android also.

Yes, I tried to do that because the builder throws the same clang++ iossimulator error no matter what platform I try to build and deploy to.

ryanalford-suzy commented 8 months ago

Yes, I tried to do that because the builder throws the same clang++ iossimulator error no matter what platform I try to build and deploy to.

Spent a little more time on it this morning and this now works for me on .Net 8 running on a Mac with Rider IDE. Built and deployed to iOS simulator, iPhone, and Android phone. Omit the other options if they aren't necessary for you.

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net8.0-ios|AnyCPU'">
  <CreatePackage>false</CreatePackage>
  <CodesignProvision>Automatic</CodesignProvision>
  <CodesignEntitlements>Platforms\iOS\Entitlements.development.plist</CodesignEntitlements>
  <!-- Fixes for AppCenter nuget package to build/run with simulators -->
  <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
  <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>

dmn-star commented 8 months ago

@AlexeyStarkov

Sorry. It was a rhetorical question caused by Xamarin -> MAUI migration frustration.

Np, I can understand your frustration quite well. Anyway, please upvote to save others the trouble in the future. :-) https://youtrack.jetbrains.com/issue/RIDER-91070/Running-iOS-Run-Configuration-also-Builds-other-TargetFrameworks

AlexeyStarkov commented 8 months ago

As a temporary solution, I recommend debugging on a physical device or excluding AppCenter during build for emulator debugging.

Here's what we're doing at the moment to achieve this (app .csproj file):

<ItemGroup>
  <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="8.0.0"/>
  <!-- other packages etc...-->
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)' != 'Debug' ">
  <PackageReference Include="Microsoft.AppCenter.Analytics" Version="5.0.3"/>
  <PackageReference Include="Microsoft.AppCenter.Crashes" Version="5.0.3"/>
</ItemGroup>

Something along these lines at app startup:

private void InitialiseAppCenter()
{
  #if !DEBUG
  var appCenterServices = new List<Type>();
  if (BuildConfig.AppCenterCrashesEnabled)
  {
      appCenterServices.Add(typeof(Microsoft.AppCenter.Crashes.Crashes));
  }
  if (BuildConfig.AppCenterAnalyticsEnabled)
  {
      appCenterServices.Add(typeof(Microsoft.AppCenter.Analytics.Analytics));
  }
  if (appCenterServices.Count > 0)
  {
      Microsoft.AppCenter.AppCenter.Start(BuildConfig.AppCenterSecret, appCenterServices.ToArray());
  }
  #endif
}

I've ended up with the workaround shown above eventually. It seems to be the only reliable solution :(

durandt commented 7 months ago

Oh well...

Visual Studio App Center is scheduled for retirement on March 31, 2025. Learn more about support timelines and recommended alternatives.

MitchBomcanhao commented 7 months ago

It doesn't look like any of the recommend alternatives are related to mobile app crash/error reporting and telemetry?

durandt commented 7 months ago

It doesn't look like any of the recommend alternatives are related to mobile app crash/error reporting and telemetry?

I would also like to hear about alternatives for crash/error reporting and telemetry. @jfversluis did a video on Sentry: https://www.youtube.com/watch?v=9-50zH8fqYA But it seems to be uploading waaaaaay too much data for my liking (sure, it's neat to debug, but you have to consider your users privacy too)

One Thread with a few suggestions: https://www.reddit.com/r/dotnetMAUI/comments/1beuv2i/visual_studio_app_center_retirement_visual_studio/

bruno-garcia commented 7 months ago

The goal is to automatically attach data that can be useful for debugging problems. Device model etc. What data do you find that affects user privacy?

Worth noting you have control of what’s sent. You get the whole object in a callback where you can delete data before it leaves the device. And you can also add filtering rules to run at ingestion time before the data hits disk.

Regarding crashes with messages with underlines or missing stack traces. Please raise a ticket so folks can dig into it, I’m unaware of issues matching that in the MAUI SDK for Sentry at the moment: https://github.com/getsentry/sentry-dotnet

Sentry invested heavily in MAUI and .NET in general. And adoption indicates folks recognize that https://nugettrends.com/packages?months=72&ids=Sentry&ids=Microsoft.AppCenter

Request for line numbers on C# exceptions have been open here for years. Sentry offers that for all platforms including iOS and Android release builds. Debug file upload is convenient with dotnet build (https://docs.sentry.io/platforms/dotnet/configuration/msbuild/) and it includes bindings to native sdks ootb

PS: I was the maintainer of the dotnet sdk at sentry

durandt commented 7 months ago

@bruno-garcia thank you for chipping in, really appreciate it!

One more question while you are here, how about one of my comments on Mastodon, that the .NET Sentry SDK seems to (from what I see in the video) be sending crash reports directly rather than saving on disk to be sent at next app startup? Docs for unhandled exceptions for iOS and Android both suggest the code handling exceptions should be quick about it, and in my mind it has always been excluded to do some network stuff there. So my question is: Does the .NET Sentry SDK attempt to do network operations in the unhandled exception code? If it fails, will it save it to the disk and retry at startup? Can this behavior be configured? Thanks!

durandt commented 7 months ago

Regarding the amount of data: The couple of minutes after 11:20 in this video: https://youtu.be/9-50zH8fqYA?feature=shared&t=680 Thats: . Stacktrace . List of rendering events . about 30-40 data points* . loaded assemblies

Sure that could be interesting but that seems like a huge footprint to add to every events (I like to add many events and usually just want to track a couple of values associated with the event)

data points

bruno-garcia commented 7 months ago

You ended up not pointing out what is concerning regarding user privacy there. I see that as technical detail potentially useful for debugging.

Regarding amount, data is compressed before leaving the device and it’s not a lot specially since it’s only in the event of an error.

Ultimately as I said you can control what’s sent, so you can keep only the stack trace if you feel that’s right for you.

bruno-garcia commented 7 months ago

the .NET Sentry SDK seems to (from what I see in the video) be sending crash reports directly rather than saving on disk to be sent at next app startup?

It stores it on disk first and deletes it after sending it. In the event of a native crash it can only work this way. It can’t make network calls out of a signal handler.

Docs for unhandled exceptions for iOS and Android both suggest the code handling exceptions should be quick about it, and in my mind it has always been excluded to do some network stuff there.

On Android it tries to send it, but only after writing to disk. In my tests if a network connection was already open, for Java exceptions it managed to send immediately. But NDK crashes always only after restart.

So my question is: Does the .NET Sentry SDK attempt to do network operations in the unhandled exception code? If it fails, will it save it to the disk and retry at startup? Can this behavior be configured?

C#, Java, Koltin, Swift, C++, Objective-C (any native) crashes will store crash data on disk first. In managed code, it will try to send it immediately (because it can work, not a real OS signal handler , it’s a managed code global error handler). On the native crashes only on app reload data is sent out

durandt commented 7 months ago

Thank you for your explanations!

You ended up not pointing out what is concerning regarding user privacy there. I see that as technical detail potentially useful for debugging.

There aren't really specific data-points that are directly affecting user privacy, but the combination of some of them may increase the risk of making it possible to identify some users. Battery level -> Could be ranges or "IsBatteryLevel10PercentOrLower" = true/false Storage/memory size -> Could be "HasAtLeast100MBFreeStorage" = true/false (100MB or another threshold)

Regarding footprint, there is also a (minor) concern that the more data you fetch using platform APIs, the bigger risk that these any of these APIs get deprecated and start creating issues (Keep it stupide simple)

I am not trying to be negative toward Sentry, I may very well use it in the end. But I have burnt myself in the past using 3:rd party crashlytics tools that made my apps crash and I am just being very cautious.

markuspalme commented 7 months ago

Would you mind taking your conversation regarding sentry somewhere private?

mhrastegari commented 7 months ago

Agreed @markuspalme

durandt commented 7 months ago

Apologies. I still think other developers may be interested by the discussion so I created #1772 for further discussions about how to move away from AppCenter since it is now announced as retiring in a year.

DmitriyKirakosyan commented 7 months ago

As we do not have plans to support net8 and fix this bug in the next year, I'm closing the issue.

thomasgalliker commented 6 months ago

What, wait? No support for .NET 8? Does this mean, AppCenter will never work on .NET MAUI with .NET 8? No TargetFramework net8.0-ios is ever supported? How can I migrate my Xamarin.Forms app to MAUI then? I know that AppCenter is about to retire by 2025, but that's 1 year of additional lifetime from now.

markuspalme commented 6 months ago

@thomasgalliker It works, just not in the simulator. You can conditionally disable it in the simulator.

thisisthekap commented 3 months ago

Just as note to help fellow developers stumbling uppon this issue: Modify your csproj file to force your ios simulator into x64 as given here: https://developercommunity.visualstudio.com/t/Unable-to-build--MAUI-app-for-iOS-with-x/10501186#TPIN-N10501850

jvondermarck commented 1 month ago

What solved the issue for me was to setup like this my `csproj` file

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFrameworks>net8.0-android;net8.0-ios</TargetFrameworks>
        <OutputType>Exe</OutputType>
        <SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">11.0</SupportedOSPlatformVersion>
        <SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">21.0</SupportedOSPlatformVersion>
                  ...
    </PropertyGroup>

    <!-- ⚠️ Workaround on mac to be able to run the project on Android and iOS -->
    <PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net8.0-ios|AnyCPU'">
        <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
        <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
    </PropertyGroup>

        <ItemGroup Condition="'$(TargetFramework)' == 'net8.0-android'">
        <ProjectReference Include="..\<Android lib>\<Android lib>.csproj" />
    </ItemGroup>

    <ItemGroup Condition="'$(TargetFramework)' == 'net8.0-ios'">
            <ProjectReference Include="..\<iOS lib>\<iOS lib>.csproj" />
    </ItemGroup>

         ...

</Project>

[!NOTE] The weird part is that I got the 0>Xamarin.Shared.Sdk.targets(1641,3): Error : clang++ exited with code 1: error when I was running my project on Android, while on iOS it worked amazingly, but anyway thanks for the workaround ! (This error only happened on my M1 Mac, while on Windows it was working great without this workaround. 🤓

microsoft / appcenter-sdk-dotnet