MAUI .NET 8 on iOS - Controls.UserControls.MAUI not working

[anitharajasri]

I have created a new MAUI .NET 8 project and migrated the Xamarin forms project code.

I used Controls.UserDialogs.Maui 1.5.4 version Nuget package. But the Loading and Alert not working without any exceptions,

Controls.UserDialogs.Maui.UserDialogs.Instance.Loading();

I just followed all their instructions, but the functionality is still not working.

I added the following code in the MauiProgram.cs file,

UseUserDialogs()

When tried to run the project with the iOS(17.4) simulator with Jetbrains Rider, does anyone have any idea how to resolve this issue?

[Alex-Dobrynin]

Have you tried sample project from this repo?

[NehpetsEtnam]

@anitharajasri Maybe you need to do dotnet workload update. I encountered same problem where actionsheet is not showing in iOS on our project after upgrading from version 1.5.4 to 1.6.2. It worked after doing dotnet workload update.

[jasells]

I have seen this as well, and there is another similar issue: No dialogs appear on iOS/MacCatalyst using v1.5.2

I think the issue is here:

https://github.com/Alex-Dobrynin/Controls.UserDialogs.Maui/blob/b0965bfff4fd9ba2e65803a67d0612f313bee756/Controls.UserDialogs.Maui/Controls.UserDialogs.Maui.csproj#L9

But some changes since then require > Maui v 8.0.3.

My app using this package was set to use Maui v 8.0.61 when I first updated from Userdialogs package v 1.5.4 to v1.6.0/1

The PR to fix the iOS empty title bars (v 1.6.2) was only a partial fix for us. We had to update the local Mac build env to Maui v 8.0.82. I think specifying this version in this lib's .csproj would at least generate a NuGet or build error in cases where the consuming application needs to also update the minimum Maui version, which is preferable to building but having a silent error (no UI shows when expected). Given the prior issue with MacCatalyst, this scenario seems to be repeating often when this package is updated.

I'm not sure what changed in this lib ~v1.6.0 that should require some Maui < v 8.0.82 but also > 8.0.61 nor what that minimum version is exactly, or I'd open a PR. I suppose, 8.0.82 is the safe version to specify at this point and push out a v1.6.3 update of this package?

Also, I'd suggest un-listing v1.6.0/1/2 after updating and pushing a new v1.6.3 package with Maui v8.0.82 min dependency.

[Alex-Dobrynin]

@jasells Look. I'm using this lib in my latest maui version 8.0.99-ci.* ios/mac apps, and everything works as expected. No crashes, no issues. Please check your configuration

[jasells]

I'm using this lib in my latest maui version 8.0.99-ci.* ios/mac apps, and everything works as expected. No crashes, no issues.

@Alex-Dobrynin

That is expected since Maui v 8.0.99 > this package's listed minimum required of v 8.0.3

Please check your configuration

I have, as I stated in previous post: "We had to update the local Mac build env to Maui v 8.0.82." We were building and running on iOS without any problems with Maui v 8.0.61 and the requisite workloads installed. Updating from this package v1.5.4 to v1.6.x passes all build steps, but then does not show any ActionSheets @ runtime, no errors.

We "updated our [build] configuration" by running dotnet workload restore on our Application project, which installed Maui v8.0.82 build dependencies. Our Application still specifies Maui v 8.0.61, however it really shouldn't pass NuGet restore or at least throw a build error if this package is included. If it did that, it would prevent many of these issue posts, since the app-dev's build system would tell them very early on that v 1.6.x of this package requires Maui v8.0.82 as of today (or whatever it is in the future) and prompt them to do the workload restore or workload update, update their application Maui version, and also allow the app- developer to decide if they want to do that now or later, since, on Mac, it may require updating XCode as well, which is not always a risk-free proposition. Maui v8.0.82 is not required for Android targets (from my team's testing), however this is a multi-target package, so it is limited by the highest platform target's dependencies, in this case, it appears to be iOS (v 8.0.82)? I haven't tested Mac-catalyst.

I'll try to make some time later this week to fork and roll an example package to illustrate. But this package, as listed, shows only Maui v 8.0.3 is required, and is the root cause of this issue thread and the previous one: No dialogs appear on iOS/MacCatalyst using v1.5.2 , only the actual required minimum Maui version as changed since this lib's .csproj was configured with 8.0.3.

[Alex-Dobrynin]

@jasells this package does not require 8.0.82, since in the project written 8.0.3 https://github.com/Alex-Dobrynin/Controls.UserDialogs.Maui/blob/b0965bfff4fd9ba2e65803a67d0612f313bee756/Controls.UserDialogs.Maui/Controls.UserDialogs.Maui.csproj#L9

but this is really strange, because it should take indicated version of maui when building packages, but obviusly it takes latest installed maui workload on machine

[jasells]

this package does not require 8.0.82, since in the project written 8.0.3

Right, but there were changes ~v1.6.0 that appear to have newer dependencies, at least for iOS, and the same for Mac-catalyst @ ~v1.5.2

I haven't dug into what exactly changed ~v1.6.0, to better understand what the dependencies are exactly...

[Alex-Dobrynin]

@jasells It does not have any new dependency. I just increased supported MacCatalyst version to 14.2 as iOS version to be the same, thats all. You just can browse commit history

[jasells]

@Alex-Dobrynin

It does not have any new dependency. I just increased supported MacCatalyst version to 14.2 as iOS version to be the same, thats all.

Right....

but obviously it takes latest installed maui workload on machine

I think this is actually increasing the minimum Maui version to whatever your dev environment is set to when doing new dev work. You may not have directly/intentionally targeted any x-plat Maui API's > 8.0.3 in the X-plat code, or platform specific code, but if your dev environment is now using workloads @ v 8.0.62 or 8.0.82 (latest release today) that means that the Maui-ios/Mac-catalyst/Android/WinUI etc targets are at that level and linking (at least) to that newer version. If you're building this repo on the same box as you are building your maui version 8.0.99-ci.* ios/mac apps on, it is linking to that nightly(?) build version. Also, I don't think multiple workload versions can be installed side-by-side? I've never tried, but when I did workload restore, it replaced the workload packages/SDK's, it didn't add another one.

I think Maui 8 is working ~like .NetStandard. The declared version in .csproj is just saying "this package/app only calls Maui API v 8.0.3" for example, but the actual libs getting linked are whatever is on the build system, >= 8.0.3. It is sort of like build-time dependency injection, so that application code doesn't have to update the target Maui version every time a Maui release is made, but bug fixes (in Maui libs) can get pushed to them still since most automated builds will require a workload restore step, unless running on a private agent(ADO) or runner (Github) that has the workloads pre-installed, or a dev box like mine where I only update when I intentionally update the workloads. But that does mean things for lib packages like this one are a little more complicated. At least, that's my speculative guess, given the results/behaviors I've seen, and my understanding of .NetStandard and Maui 8 workloads.

I dunno if there might be an issue on Xamarin-ios github about this specific issue topic that might shed more light on exactly what is going on?

I haven't tried this, but there is a way to install a specific workload version [--version flag] and also uninstall, and appears to have the same flags?

Experimentally, someone could probably determine what exact version is required to resolve this specific issue (the missing ActionSheet) on iOS for this lib... but not sure how valuable that would be, aside from opening a ticket on Xamarin-ios repo with a repro? But, whatever the root bug is, it is fixed in 8.0.82, for sure.

This probably is more useful when dev/testing this package to better know exactly what version of things is actually being used @ runtime during dev/testing, if you care to try to keep that version from creeping up to whatever is the latest installed on your dev environment via workload restore/update each time you update the code? This is probably not an issue in every version release of Maui, but there's no way to know besides experimentation (that I can think of) which workload update will cause an issue, and which won't, since each time up we update the Maui workload libs, there's always the risk of new bugs being introduced in specific platforms, but not others, as well as the known fixes.

If this were my repo, I'd just update the MauiVersion tag in .csproj to whatever is on my dev system (excluding nightly builds) whenever I update this code, or use workload uninstall + workload install to target official release versions.

Having said all of that, given that Maui 8.0.3 was the first official release of Maui 8, it isn't surprising that there have been bug fixes in later Maui 8.0.x releases, nor that one of them introduced this bug ~8.0.61? when combined with v1.6.x of this lib. And, this lib apparently does currently have a dependency (if only iOS) on some bug fix in Maui > 8.0.61, (released Jun 25, 2024), which isn't that old.

IMHO, it would be very helpful for everyone consuming this package if it would declare Maui v 8.0.82 as the required version for a 1.6.3 release at least. Whether you update that for every release of your package in the future is up to you.

[Alex-Dobrynin]

@jasells I should not fix MAUI or .NET bugs in my packages. version 8.0.3 is indicated specifically for using MAUI >= 8.0.3 if for some reason someone does not like 8.0.82 or whatever greater than 8.0.3. If for some reason dotnet publish (or by the way I'm doing packages just with GeneratePackageOnBuild tag in VS in .csproj) is not taking specified MAUI version for the basis of the package, then you should go there (MS github dotnet, xamarin ios, maui) and write ticket there.

[jasells]

or by the way I'm doing packages just with GeneratePackageOnBuild tag in VS in .csproj

This uses the <MauiVersion>8.0.3</MauiVersion> tag from .csproj when generating NuGet package dependencies, as shown in the listing:

I should not fix MAUI or .NET bugs in my packages.

I'm not asking you to fix a Maui bug, just confirming the OP of this issue that this lib @ v 1.6.x does indeed not show ActionSheets on iOS when using Maui v8.0.61. Using Maui v 8.0.82 resolves the issue for v 1.6.x of this package.

V 1.5.4 of this package does not show this behavior with Maui v 8.0.61, so there is some portion of the issue that is in this lib's domain @ version 1.6.x.

This suggests that v 1.6.x of this package requires a minimum of Maui 8.0.82, as of today.

Updating <MauiVersion>8.0.82</MauiVersion> tag in this project would resolve this issue, and likely help avoid similar issues in the future by moving the issue from runtime, to package resolution or build time.

have a good day, and good luck! 😁

[Alex-Dobrynin]

@jasells I have another idea. i can remove UseMaui tag, and just leave maui packagereference.it should not build it with latest maui workload, but may be im wrong

[jasells]

i can remove UseMaui tag, and just leave maui packagereference

Yes, you can do that, I have done it. You will have to include 2 packages, I think. Here is how my current app .csproj is configured to avoid <UseMaui> tag:

<PropertyGroup>
    <!--<Sdk Name="DotNet.ReproducibleBuilds.Isolated" Version="1.1.1" />-->
    <MauiVersion>8.0.61</MauiVersion>
    .
    .
    .

</PropertyGroup>
.
.
.
<!--maui verison can be updated here via the build var above-->
<ItemGroup>
    <PackageReference Include="Microsoft.Maui.Controls" Version="$(MauiVersion)" />
    <PackageReference Include="Microsoft.Maui.Controls.Compatibility" Version="$(MauiVersion)" />
</ItemGroup>

Maybe this lib doesn't need the Compatibility package, since it is not listed in NuGet, currently?

[Alex-Dobrynin]

it does not use compatibility

[jasells]

it should not build it with latest maui workload, but may be im wrong

It will still link against the workload installed on the build system, if >= min version declared in .csproj is found

I think there can be only one workload version installed at a time... like Highlander. 😁

https://tenor.com/view/rucoy-highlander-bees-knees-gif-13863171

but i might be wrong. I've never tried, but I see no indication from previous installs/updates etc that this can be done.

I think you'll have to use workload uninstall maui and then workload install maui --version x to install a specific version before building this lib, if that is your intent.

BUT it still will display this issue, if the consuming application's build/env uses 8.0.61 with v1.6.x unless this package specifies it needs Maui[.Controls] v8.0.82

It seems like the issue is only in the Maui-iOS libs @ v ~8.0.61, not the x-platform ones, but specifying Maui 8.0.82 is the root of that dependency tree and will pull in the platform libs too at that version.

[jasells]

The only alternative i can think of is splitting this single (multi-target) project into multiple projects:

• Portable project (the code from /Shared dir)
• iOS/Mac project
• Android project
• WinUI (add more supported platforms here)

Each platform project would have to have a project ref to the portable project to allow the packages to be built via <GeneratePackageOnBuild>True</>

This is possible, but more complicated to set up the packaging. I have done it, but there is a reason MS uses the multi-target/single project by default... it is simpler to set up and maintain, but the trade is less flexibility in dependency versions, like Maui. The build system is essentially doing this for you with the single project @ build-time.

BUT it would allow you to set Maui v 8.0.3 on that Portable project, but a higher one (8.0.82) on iOS/Mac project only.

[Alex-Dobrynin]

it does not need that, because it does not use maui's platfroms folder

[jasells]

Ohhh... I see this is using a legacy .csproj config to accomplish this the way we used to do it before Maui and multi-target projects... hmmm.

I think the result is the same: you're stuck with a single Maui dependency version. Short of some complicated .csproj configuration to set up conditionals for changing the Maui version only for iOS/Mac or creating platform-specific .csproj files for each platform.

I don't recommend trying to manage the Maui dependency version differently per platform in a single .csproj.

[NehpetsEtnam]

@jasells @Alex-Dobrynin Maybe part of the issue is the Target Framework changes on iOS.

If you check this bug https://github.com/Alex-Dobrynin/Controls.UserDialogs.Maui/issues/11. Problem occurs when upgrading from v1.5.1 to v1.5.2. v1.5.1 => net8.0-ios17.0 v1.5.2 => net8.0-ios17.2

Problem also occurs when upgrading from v1.5.4 to v1.6.0/1/2. v1.5.4 => net8.0-ios17.2 v1.6.0 => net8.0-ios17.5

[Alex-Dobrynin]

@NehpetsEtnam can be, but idk how to avoid that. I can just remove MauiVersion tag from .csproj and leave version used by maui workload installed on pc. But obviously this is not a good solution, because not everybody want use version that i dictate in my nuget

[NehpetsEtnam]

@Alex-Dobrynin maybe we can avoid by changing <TargetFrameworks>net8.0;net8.0-android;net8.0-ios;net8.0-maccatalyst</TargetFrameworks> to <TargetFrameworks>net8.0;net8.0-android34.0;net8.0-ios17.2;net8.0-maccatalyst</TargetFrameworks>

https://learn.microsoft.com/en-us/dotnet/standard/frameworks#os-version-in-tfms

[jasells]

@Alex-Dobrynin

I can just remove MauiVersion tag from .csproj and leave version used by maui workload installed on pc.

Only if you change this package to a source code package from the current compiled binary package. That is possible to do...

But obviously this is not a good solution, because not everybody want use version that i dictate in my nuget

I do appreciate your intent here. It is a good instinct as a lib publisher. However, you already are dictating a minimum Maui version: 8.0.3, it's just not correct anymore, at least for iOS, and the incorrectness only discovered @ runtime. Hence, this issue.

Requiring package consumers to run "dotnet workload restore/update" is simply an unclear/stealth way of dictating the version you tested with (or newer), but is not documented what that version is. It is only deduced that it must be > Maui 8.0.3 as listed in NuGet dependencies.

publishing a new 1.6.3 or 1.7 package with newer min Maui dependency (8.0.82) allows consumers the choice of which version of this package to use, and therefore the Maui version, and clearly outlines what the choices are, up front via NuGet. The one version it clearly is not : 8.0.3.

Some other info: iOS 17.5 support was not added to Maui until 8.0.82 PR.

And given the behaviors outlined in this issue thread for this package's v1.6.x, the 1.6.0 commit seems have some dependency on iOS 17.5 SDK, therefore Maui 8.0.82 from observations listed in this thread. I don't know what is requiring it. Would have to investigate more.

The v 1.6.0 commit is also suspiciously <= 1 week after the Maui 8.0.82 release.... implying that it was built/tested against the latest (8.0.82 or slightly newer) workloads on your dev env... Nothing at all wrong with that, but package consumers would find it extremely helpful to know what that version is before updating from 1.5.4 to 1.6.x or any future version.

To avoid Maui requirement increases in the future, my suggestion is to use dotnet workload maui uninstall and then dotnet workload maui install --version [YourDesiredPackageMauiTargetVersion] to ensure that new development is done in a manner compatible with the specified Maui version and does not force a version increase.

[NehpetsEtnam]

@jasells @Alex-Dobrynin I think it is not because of the Maui version. If we check the dependencies on nuget.org it is still >= 8.0.3. What changed from 1.5.4 to 1.6.0/1/2 is the target framework on iOS, you can check it on dependencies or frameworks tabs. It didn't give us problem on android because starting 1.5.0 it is using android 34.0 but for iOS it changes from 17.0 to 17.2 to 17.5. Maybe that's why we should do dotnet workload restore or dotnet worload update. You can check also the nuspec on the package cache of your local machine.

[Alex-Dobrynin]

@jasells @NehpetsEtnam Agree with you guys. I think I just remove MauiVersion tag and it will use just the latest installed workload on my machine, because i cannot install or uninstall workloads each time, because im also doing my daily job on the same machine. or install VM and do nuget stuff there, but maybe am so lazy to do that))

[jasells]

If we check the dependencies on nuget.org it is still >= 8.0.3.

This is based purely on the specified version in the .csproj. You must provide something there with this .csproj structure.

I think I just remove MauiVersion tag and it will use just the latest installed workload on my machine

The best case scenario is that the package will be built with no declared Maui dependency, if it even builds/packages. I expect it won't.

If this were converted to an "official" multi-target Maui project (with /Platforms directory, etc), the build system would understand the project structure and would use the declared Maui version to select the maui-ios version and make sure they match, or at least fail if Maui 8.0.3 is not compatible with any one of the platforms' code.

Because this is a "legacy" project structure, the build system doesn't realize that Maui v 8.0.3 is declared, but xamarin-iOS 17.5 SDK is being linked which requires Maui-ios 8.0.82, but it packages things with "Maui 8.0.3" dependency, which includes indirectly xamarin-ios < 17.5, and the v 8.0.3 maui-ios packages. This is where things are mis-aligned.

When consumers include this package, NuGet sees this 8.0.3 dependency, checks the local workload version installed and sees, in most cases at this point, > 8.0.3, so everything looks good. But this is only true if the local system has workload >= what ever the package-build system used (~8.0.82), which is not declared anywhere.

So the options are

1. manually increase the declared Maui dependency in this .csproj to help the build system package correctly
2. convert this to an official multi-target Maui project (allowing the build system to detect that either 8.0.3 does not work with the iOS code currently in this project, or correctly link to the correct Maui-iOS and xamarin-ios .dll's)
3. revert 1.6.0 changes or reconfigure this project to the actual minimum Maui version needed (8.0.82 >= some version > 8.0.3) for the correct maui-ios+xamarin-ios(17.2/17.5 whichever is correct). Setting global.json file can define a specific workload version to install and help keep pipelines and local environments in sync, from the docs. I've not tried this.
4. leave it as-is. Time will make this less of an issue as consumers update to 8.0.82+ workloads, but it will arise possibly again the next/any time this package is updated.

[Alex-Dobrynin]

If this were converted to an "official" multi-target Maui project (with /Platforms directory, etc), the build system would understand the project structure and would use the declared Maui version to select the maui-ios version and make sure they match, or at least fail if Maui 8.0.3 is not compatible with any one of the platforms' code.

You are not right, it does not care about project structure, since it has tag UseMaui. the main issue is in installed ios and mac workloads and specifying their target as net8.0-ios or same for mac. I have already investigated it. and if we want use ios 8.0.3, the workload with this version should be installed on the machine. and it does not have any relation to maui itself, since it just nuget package added to the project

[NehpetsEtnam]

@Alex-Dobrynin with this changes

I was able to generate a nupkg that is targeting iOS 17.0

This is the generated nuspec of the latest version 1.6.2

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>Controls.UserDialogs.Maui</id>
    <version>1.6.2</version>
    <title>Controls.UserDialogs.Maui</title>
    <authors>Alex Dobrynin</authors>
    ...
    <dependencies>
      <group targetFramework="net8.0">
        <dependency id="Microsoft.Maui.Controls" version="8.0.3" exclude="Build,Analyzers" />
      </group>
      <group targetFramework="net8.0-android34.0">
        <dependency id="AndHUD" version="2.0.1" exclude="Build,Analyzers" />
        <dependency id="Microsoft.Maui.Controls" version="8.0.3" exclude="Build,Analyzers" />
      </group>
      <group targetFramework="net8.0-ios17.5">
        <dependency id="BTProgressHUD" version="2.0.1" exclude="Build,Analyzers" />
        <dependency id="Microsoft.Maui.Controls" version="8.0.3" exclude="Build,Analyzers" />
      </group>
      <group targetFramework="net8.0-maccatalyst17.5">
        <dependency id="BTProgressHUD" version="2.0.1" exclude="Build,Analyzers" />
        <dependency id="Microsoft.Maui.Controls" version="8.0.3" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
</package>

and this is the generated nuspec of the one i built locally with my changes

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>Controls.UserDialogs.Maui</id>
    <version>1.6.3</version>
    <title>Controls.UserDialogs.Net.Maui</title>
    <authors>Alex Dobrynin</authors>
    ...
    <dependencies>
      <group targetFramework="net8.0">
        <dependency id="Microsoft.Maui.Controls" version="8.0.3" exclude="Build,Analyzers" />
      </group>
      <group targetFramework="net8.0-android34.0">
        <dependency id="AndHUD" version="2.0.1" exclude="Build,Analyzers" />
        <dependency id="Microsoft.Maui.Controls" version="8.0.3" exclude="Build,Analyzers" />
      </group>
      <group targetFramework="net8.0-ios17.0">
        <dependency id="BTProgressHUD" version="2.0.1" exclude="Build,Analyzers" />
        <dependency id="Microsoft.Maui.Controls" version="8.0.3" exclude="Build,Analyzers" />
      </group>
      <group targetFramework="net8.0-maccatalyst17.0">
        <dependency id="BTProgressHUD" version="2.0.1" exclude="Build,Analyzers" />
        <dependency id="Microsoft.Maui.Controls" version="8.0.3" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
</package>

compare the <group targetFramework="net8.0-iosXX.X"> on both. my locally generated is using 17.0 as i specified it on the csproj changes. I think with that, consumers will not need to do workload upgrade since the target framework on iOS is still 17.0. On my local machine i do have 17.0 and 17.5. Changes on csproj is dictating to use 17.0 even if i have 17.5.

[jasells]

@NehpetsEtnam Your target framework suggestion looks to be the simplest path to:

3. revert 1.6.0 changes >>or reconfigure this project<< to the actual minimum Maui version needed (8.0.82 >= some version > 8.0.3) for the correct maui-ios+xamarin-ios(17.2/17.5 whichever is correct). Setting global.json file can define a specific workload version to install and help keep pipelines and local environments in sync, from the docs. I've not tried this.

Does it work @ runtime for iOS and MacCatalyst? From the prior macCatalyst issue, it would seem like it should, if Xamarin-ios-17.0 is the minimum needed.

[NehpetsEtnam]

@jasells i think it will work on macCatalyst issue as 1.5.0/1 is using 17.0 and 1.5.2/3/4 is using 17.2 and 1.6.0/1/2 is using 17.5. So targeting 17.0 is best to use.

[NehpetsEtnam]

Created a pull request for my changes to specify android and iOS target frameworks https://github.com/Alex-Dobrynin/Controls.UserDialogs.Maui/pull/24/files

[Alex-Dobrynin]

@NehpetsEtnam I'm not sure it will help, since anyway i will do build on my machine, which already has latest workload. Im not sure if specifying ios version explicitly will not cause the same issue because of the lates ios workload

[NehpetsEtnam]

@jasells did you update your workload already and you have xcode 15.4? if not, maybe you can help on testing if my changes will help or not if you upgrade to the version with my changes?

@Alex-Dobrynin if it is fine for you to create a package version 1.6.3 with my changes and publish it, maybe @jasells can help testing. I do have workmates also that didn't update workload and xcode yet. so she can help on testing this too.

[jasells]

@NehpetsEtnam I do have a system with workloads @ 8.0.61 I can test with, can you attach your test build package here, so I can download/test with that? It should be a good test of building the package with workloads > min required.

[NehpetsEtnam]

@jasells TestPackage.zip

[jasells]

I do have a system with workloads @ 8.0.61 I can test with

The build/dev system for a consuming Maui iOS app:

Installed Workload Id      Manifest Version       Installation Source
---------------------------------------------------------------------
maui-tizen                 8.0.61/8.0.100         SDK 8.0.300        
ios                        17.2.8078/8.0.100      SDK 8.0.300        
android                    34.0.113/8.0.100       SDK 8.0.300    

And your 1.6.3 package you zipped builds/runs as expected, with the 16.2 changes visible. woot!

To recap: 1.6.2\1\0 published packages have the issue from this OP on the same dev/build environment.

v 1.5.4 of this package works in same Maui app/env.

Consuming Maui app targets Maui v 8.0.61.

[NehpetsEtnam]

I think specifying the target framework does matter. If you do dotnet workload list it will give you the latest only. But doing dotnet workload --info it will give you path of the workload. Opening it will show you all the workload you have.

Checking the latest WorkloadManifest.targets this is the content

<Project>
    <ImportGroup Condition=" '$(TargetPlatformIdentifier)' == 'iOS' And '$(UsingAppleNETSdk)' != 'true' And $([MSBuild]::VersionEquals($(TargetFrameworkVersion), '7.0'))">
        <Import Project="Sdk.props" Sdk="Microsoft.iOS.Sdk.net7" />
        <Import Project="Sdk.props" Sdk="Microsoft.iOS.Windows.Sdk.Aliased.net7" Condition=" $([MSBuild]::IsOSPlatform('windows'))" />
    </ImportGroup>

    <ImportGroup Condition=" '$(TargetPlatformIdentifier)' == 'iOS' And '$(UsingAppleNETSdk)' != 'true' And $([MSBuild]::VersionEquals($(TargetFrameworkVersion), '8.0')) And '$(TargetPlatformVersion)' == '17.0'">
        <Import Project="Sdk.props" Sdk="Microsoft.iOS.Sdk.net8.0_17.0" />
        <Import Project="Sdk.props" Sdk="Microsoft.iOS.Windows.Sdk.Aliased.net8.0_17.0" Condition=" $([MSBuild]::IsOSPlatform('windows'))" />
    </ImportGroup>

    <ImportGroup Condition=" '$(TargetPlatformIdentifier)' == 'iOS' And '$(UsingAppleNETSdk)' != 'true' And $([MSBuild]::VersionEquals($(TargetFrameworkVersion), '8.0'))">
        <Import Project="Sdk.props" Sdk="Microsoft.iOS.Sdk.net8.0_17.5" /> <!-- this SDK version will validate the TargetPlatformVersion and show an error (in .NET 9+) or a warning (.NET 8) if it's not valid -->
        <Import Project="Sdk.props" Sdk="Microsoft.iOS.Windows.Sdk.Aliased.net8.0_17.5" Condition=" $([MSBuild]::IsOSPlatform('windows'))" />
    </ImportGroup>

    <ImportGroup Condition=" '$(TargetPlatformIdentifier)' == 'iOS' And '$(UsingAppleNETSdk)' != 'true'">
        <Import Project="Sdk-eol.props" Sdk="Microsoft.iOS.Sdk.net8.0_17.5" Condition=" $([MSBuild]::VersionLessThan($(TargetFrameworkVersion), '7.0'))" />
        <Import Project="Sdk.props" Sdk="Microsoft.iOS.Sdk.net8.0_17.5" Condition=" $([MSBuild]::VersionGreaterThan($(TargetFrameworkVersion), '8.0'))" />
    </ImportGroup>

    <ItemGroup Condition=" '$(TargetFrameworkIdentifier)' == '.NETCoreApp' and $([MSBuild]::VersionGreaterThanOrEquals($(TargetFrameworkVersion), '6.0')) ">
        <SdkSupportedTargetPlatformIdentifier Include="ios" DisplayName="iOS" />
    </ItemGroup>
</Project>

Check the 2nd and 3rd ItemGroup.

[Alex-Dobrynin]

merged #24