I have an example working end-to-end, with changes to the dotnet/sdk + an MSBuild target added to a dotnet new android sample project.

Requirements

A list of things needed:

• Pass the path to Microsoft.Extensions.DotNetDeltaApplier.dll during the build
  • On desktop, this works if you dotnet-watch a local process, $DOTNET_STARTUP_HOOKS is used and it can load the file on disk. For mobile we need to "deploy" the assembly. This can simply be added to the @(Reference) item group.

Example:

<PropertyGroup>
  <_DotNetWatchToolPath>$([MSBuild]::NormalizePath('$(MSBuildSDKsPath)', '..', 'DotnetTools', 'dotnet-watch', '$(NETCoreSdkVersion)', 'tools', 'net10.0', 'any'))</_DotNetWatchToolPath>  
  <!-- D:\src\dotnet\sdk\artifacts\bin\redist\Debug\dotnet-installer\sdk\10.0.200-dev\DotnetTools\dotnet-watch\10.0.200-dev\tools\net10.0\any\hotreload\net10.0\Microsoft.Extensions.DotNetDeltaApplier.dll -->
  <_HotReloadAgentPath>$(_DotNetWatchToolPath)\hotreload\net10.0\Microsoft.Extensions.DotNetDeltaApplier.dll</_HotReloadAgentPath>
</PropertyGroup>
<ItemGroup>
  <Reference Include="$(_HotReloadAgentPath)" />
</ItemGroup>

• Environment variables
  • Env vars like $DOTNET_STARTUP_HOOKS needs to be baked into mobile applications, as there isn't a way to set them outside of Android's sandbox.
  • We could change either the .NET SDK or Android/iOS workloads to apply these via existing MSBuild item groups.

Example:

<ItemGroup>
  <!-- either one of these two -->
  <RuntimeHostConfigurationOption Include="STARTUP_HOOKS" Value="Microsoft.Extensions.DotNetDeltaApplier" />
  <AndroidEnvironment Include="DOTNET_STARTUP_HOOKS" Value="Microsoft.Extensions.DotNetDeltaApplier" />
  <!-- other env vars -->
  <AndroidEnvironment Include="DOTNET_WATCH_HOTRELOAD_HTTP_ENDPOINT" Value="https://localhost:$(DotNetWatchHotReloadHttpPort)/hotreload/" />
  <AndroidEnvironment Include="HOTRELOAD_DELTA_CLIENT_LOG_MESSAGES" Value="[HotReload]" />
</ItemGroup>

• New transport
  • Named pipes are used on desktop, I had dotnet-watch open an HttpListener and the application connects back to dotnet-watch. Android uses the adb reverse command that allows both emulators/devices to talk to dotnet-watch.
  • We would need to pass a port number to MSBuild, to call adb reverse (mlaunch on iOS). This could be a standard property we add to Android/iOS workloads. I ran the command right after ComputeRunArguments MSBuild target in my sample.
  • We would need to pass a value to the build to set an env var like $DOTNET_WATCH_HOTRELOAD_HTTP_ENDPOINT, that allows Microsoft.Extensions.DotNetDeltaApplier.dll to connect to dotnet-watch.

iOS

So far, everything I've seen to get Android to work, also applies to iOS. We should be able to get both platforms working with these changes.