Open issues: Support targeting iOS and Android with the .NET SDK

[richlander]

This issue tracks open design topics for targeting iOS and Android and contributes to #11165. They are split into themes.

Note: Apologies in advance -- there are likely some already made design decisions hidden (not intentionally) under some of these questions. Where appropriate, assumptions are provided. If you have a question about these, feel free to ask.

Missing documents

• We have a workloads overview doc, but not a "Supporting Xamarin scenarios on .NET 5 Overview". There are a set of scenarios and policy questions that apply there that are worth elevating from the design docs. There are a lot of people who might want a summary of our plans, but don't care about the details. This doc would satisfy that.

Installation

Assumption: For .NET 5.0, we will distribute iOS and Android support exclusively via VS [for Windows | for Mac]. We will support more distribute vehicles in .NET 6.0. This is purely a scoping (cost-related) decision.

• Which installer technology should we use for .NET 5.0?
  • Our long-term plan is .nupkg files. It would be advantageous if we could make this change once, as opposed to two-step.
  • Open question is whether we can design a model for NuGet packages to fit within the VS installation (install, uninstall, repair) and side-by-side (preview vs stable; version n vs n-1; community vs Pro) models.

Composition

• Can we create multiple workloads for iOS and Android?
  • The answer needs to be "yes".
  • We need to validate that we have a good model in place for components that are shared across workloads. This is mostly a function of a manifest design that enables the scenario, and manifest validation tools to ensure that manifests that represent more advanced scenarios are formed correctly.
• How will users opt into new iOS and Android versions?
  • We expect them to update their Target Framework, as described @ https://github.com/dotnet/designs/blob/master/accepted/2020/minimum-os-version/minimum-os-version.md.
  • We plan to use the same model for previews and stable versions, at least initially. This means that we will ship stable and preview together in stable software.
  • They will be made available as opt-in software, possibly within an existing SDK feature band (like between 5.0.100 and 5.0.200). No existing projects or builds should change.
  • When a new stable version is made available, the templates will be updated to use the new version (updated TFM).
  • It is unclear what we'll do for templates with preview versions.
• When would we drop support for an older version of the iOS or Android toolchain?
  • For iOS, we need to decide when we'd drop support for iOS14 (in the latest SDK) after adding support for iOS15.
  • We'd need a similar policy for Android.

Build

• Which operations are supported in build vs publish?
  • Do we expose a set of publish only properties to enable publish behavior that does not affect regular builds?
  • Are all those publish options available as opt-in for build?
• What is the model for resources in multi-targeted libraries? We need to define a convention for projects so that they can store their resources (for iOS, Android and Windows) in separate directories, so that the build just works (picks up and processes each of the resource separately, per multi-targeted build).
• How do users specify that they want to use Mono for build or publish?
  • This is presumably not needed to target iOS and Android, but would be useful for console apps (at least for testing)?
  • Do we want to expose a way to use CoreCLR instead of Mono, in some scenarios, like to target macOS?
  • There are a few options: CLI argument, msbuild property, extend RID graph for Mono.

Run

• What is the behavior for dotnet run for Xamarin workloads? We'll need to define the same thing for wasm.

[KathleenDollard]

@richlander Can you edit the issue to clarify a couple of things

• Can we create multiple workloads for iOS and Android? Differing by what? Version? Contained parts?
• When a new stable version is made available, the templates will be updated to use the new version (updated TFM). Can you add "in the next feature band release"

[richlander]

My plan was to update the templates immediately, for iOS and Android. At that point, new projects should target the new OS version. Scenario-wise, that would seem to be what users would expect.

There was some discussion at one point about having iOS and Android as a single workload, in part because they have some duplicate assets. We decided that we would not do that. It isn't good for users (or really anyone). I recorded this to ensure that we are locking in the idea that iOS and Android workloads will be separate, and that any duplicates dependent assets are handled as an implementation detail.

[mhutch]

Yes, I would also expect that we would update templates within an SDK feature band. The goal of opt-in mid-band platform feature updates is to avoid unexpected changes in the way an existing project builds/runs. That doesn't apply to new projects - there's no reason not to put them on the new version right away, and they can easily be downgraded if needed.

[wli3]

Yes, I would also expect that we would update templates within an SDK feature band.

How workload work with template itself is an unsolved hard problem. Templates today are selected by runtime band. -- the highest template within a runtime band will be selected and move to "hive". And then another complicated logic will pick what to use when user type dotnet new. -- This is very different than what we want. And I don't feel positive we can get this done within 5.0 timeframe considering we don't have someone understanding template engine through and through. And this is a very fundamental change.

The fallback might be

1. ask the user install Xamarin template from the internet
2. SDK carry all templates from all workload. They use may be able to create a project from the template, but they may not be able to run
3. [mostly hack] CLI take over/create several dotnet new command and use a different code path instead of template engine.

cc @donJoseLuis @grinrag @phenning

[rolfbjarne]

• For iOS, we need to decide when we'd drop support for iOS14 (in the latest SDK) after adding support for iOS15

This is unclear to me: exactly what do you mean by dropping support for a particular version of iOS? When Xamarin.iOS ships support for iOS 15, it will work for older iOS versions as well (currently we support iOS 7+).

[phenning]

We should be able to add another location for the template engine to scan for templates when it initializes the hive for picking up the unbanned templates.

The difficult thing here is the rescan mechanism for when workloads change. We need to make sure that this location gets rescanned and any new templates packs are installed, as well as removing any that are no longer present. Most of the data needed for this should be available via API.

We also must be careful to not simply reinitialize the hive here as we don't want to remove any templates that the customer had installed via dotnet -i.

[wli3]

split separate issue for template #11326

[wli3]

What is the model for resources in multi-targeted libraries? We need to define a convention for projects so that they can store their resources (for iOS, Android and Windows) in separate directories, so that the build just works (picks up and processes each of the resource separately, per multi-targeted build).

Today, if you have a project targeting "netcoreapp2.1;netcoreapp3.1", and run dotnet pack. The result nupkg will have netcoreapp2.1 and netcoreapp3.1 folders under lib. Is there any extra support we need for ios and android tfms?

[wli3]

What is the behavior for dotnet run for Xamarin workloads? We'll need to define the same thing for wasm.

The workload owner could override RunCommand msbuild property to specific what the action of dotnet run should be. It should be whatever Xamarin VS do today -- open simulator and run the app.