Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable AppleAppBuilder to bundle applications compiled with NativeAOT #80910

Closed
Tracked by #80905
ivanpovazan opened this issue Jan 20, 2023 · 3 comments · Fixed by #81711
Closed
Tracked by #80905

Enable AppleAppBuilder to bundle applications compiled with NativeAOT #80910

ivanpovazan opened this issue Jan 20, 2023 · 3 comments · Fixed by #81711

Comments

@ivanpovazan
Copy link
Member

Description

AppleAppBuilder build task currently only supports Mono as the default AOT compiler and runtime when creating application bundles.

Proposal

Extend AppleAppBuilder to support NativeAOT, as a second AOT compiler and runtime, when creating iOS application bundles.
This would enable building and running sample applications built with NativeAOT on iOS platforms, but also size and performance monitoring.

@ghost
Copy link

ghost commented Jan 20, 2023

Tagging subscribers to 'os-ios': @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

Issue Details

Description

AppleAppBuilder build task currently only supports Mono as the default AOT compiler and runtime when creating application bundles.

Proposal

Extend AppleAppBuilder to support NativeAOT, as a second AOT compiler and runtime, when creating iOS application bundles.
This would enable building and running sample applications built with NativeAOT on iOS platforms, but also size and performance monitoring.

Author: ivanpovazan
Assignees: ivanpovazan
Labels:

feature-request, os-ios, area-NativeAOT-coreclr

Milestone: 8.0.0

@am11
Copy link
Member

am11 commented Jan 20, 2023

It gets enabled when TargetPlatformIdentifier is set (not to be confused with TargetFrameworkIdentifier / TFI).

e.g. <TargetFramework>net7.0-macos</TargetFramework> is same as:

    <TargetFramework>net7.0</TargetFramework>
    <TargetPlatformIdentifier>macos</TargetPlatformIdentifier>

By setting TPI, .NET SDK imports WorkloadManifestTargetsLocator, which resolves Microsoft.macos.Sdk.net7 SDK, which further resolves Microsoft.NET.Runtime.MonoTargets.Sdk.net7 and then Xamarin.Shared.Sdk etc. Somewhere there in the SDK, we can check if '$(PublishAot)' == 'true' then e.g. skip importing WorkloadManifestTargetsLocator or something down the chain. There maybe some more changes required but that would be the starting point to ninja in the NativeAOT bits. 🥷

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Feb 6, 2023
@ivanpovazan
Copy link
Member Author

It gets enabled when TargetPlatformIdentifier is set (not to be confused with TargetFrameworkIdentifier / TFI).

e.g. <TargetFramework>net7.0-macos</TargetFramework> is same as:

    <TargetFramework>net7.0</TargetFramework>
    <TargetPlatformIdentifier>macos</TargetPlatformIdentifier>

By setting TPI, .NET SDK imports WorkloadManifestTargetsLocator, which resolves Microsoft.macos.Sdk.net7 SDK, which further resolves Microsoft.NET.Runtime.MonoTargets.Sdk.net7 and then Xamarin.Shared.Sdk etc. Somewhere there in the SDK, we can check if '$(PublishAot)' == 'true' then e.g. skip importing WorkloadManifestTargetsLocator or something down the chain. There maybe some more changes required but that would be the starting point to ninja in the NativeAOT bits. 🥷

^ @kotlarmilos I believe this would contribute to your SDK integration work

@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Feb 7, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Mar 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants