MAUI iOS App Store rejection: App references non-public symbols _FSEventStreamCreate

[josephatkuvio]

Description

I'm running into an App Store rejection issue with .NET 6.0 Preview 7 + MAUI + iOS + WebView.Maui:

The app references non-public symbols in XXX.XXX: _FSEventStreamCreate, _FSEventStreamInvalidate, _FSEventStreamRelease, _FSEventStreamScheduleWithRunLoop, _FSEventStreamStart, _FSEventStreamStop, _FSEventStreamUnscheduleFromRunLoop

I believe that the offending package is System.IO.FileSystem.Watcher, which I'm guessing is referenced (and so ILLink won't remove, no matter what) because of this line: https://github.com/dotnet/aspnetcore/blob/fd9dfeccc1ab407a818d286128697b48149c384a/src/Components/WebView/WebView/src/StaticWebAssetsLoader.cs#L166.

Repro: Build the base MAUI Blazor template in Release+iOS+ARM64 and publish to App Store TestFlight, using the following in csproj:

<RuntimeIdentifier Condition="$(TargetFramework.Contains('-ios')) AND '$(Configuration)' == 'Release'">ios-arm64</RuntimeIdentifier>

Configuration

.NET 6 Preview 7
MAUI Single Project
Blazor + MAUI.WebView
iOS ARM64 Build

Regression?

Exact issue occurred w/ mtouch in 2019: mono/mono#14290

Other information

Tried many combinations of the following properties. MtouchLink=Full successfully removes System.IO.FileSystem.Watcher, but only because it also removes the default constructors for BlazorWebView. The following combo got me the closest to a resolution, but no dice, my best guess being because WebView.Maui.IOSWebViewManager inherits from WebView.WebViewManager, which instantiates PhysicalFileProvider during its static assets load.

<TrimMode>link</TrimMode>
<MtouchLink>SdkOnly</MtouchLink>
<_ExtraTrimmerArgs>-x linker.xml --action link "Microsoft.AspNetCore.Components.WebView" --action link "Microsoft.AspNetCore.Components.WebView.MauiSparc"</_ExtraTrimmerArgs>

linker.xml:

<linker>
	<assembly fullname="Microsoft.AspNetCore.Components.WebView.Maui">
		<type fullname="Microsoft.AspNetCore.Components.WebView.Maui.BlazorWebViewHandler">
		    <method signature="System.Void .ctor()" />
		</type>
	</assembly>
</linker>

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[Redth]

// CC @dalexsoto and @rolfbjarne

[akoeplinger]

This happens because we're using FSEventStream APIs which are only supported on macOS/Catalyst: https://developer.apple.com/documentation/coreservices/1443980-fseventstreamcreate

runtime/src/libraries/System.IO.FileSystem.Watcher/src/System/IO/FileSystemWatcher.OSX.cs

Lines 316 to 317 in bc7081e

	// Create the event stream for the path and tell the stream to watch for file system events.
	SafeEventStreamHandle eventStream = Interop.EventStream.FSEventStreamCreate(

[Redth]

@akoeplinger what's the action here?

[akoeplinger]

In mono/mono we "solved" this by using a FileSystemWatcher implementation which throws PlatformNotSupportedException. We can easily do the same here but not sure if that will solve the MAUI Blazor issue with PhysicalFileProvider.

[Redth]

@Eilon might need your input here too

[josephatkuvio]

I was able to resolve it for my personal case by removing the hardcoded reference to PhysicalFileProvider and replacing it with the IFileProvider from the parent class, and rebuilding aspnetcore. This was enough to get the linker to remove System.IO.FileSystem.Watcher. This doesn't solve the underlying issue of course, but may be a viable strategy to get MAUI projects app-store-releaseable.

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I'm running into an App Store rejection issue with .NET 6.0 Preview 7 + MAUI + iOS + WebView.Maui:

The app references non-public symbols in XXX.XXX: _FSEventStreamCreate, _FSEventStreamInvalidate, _FSEventStreamRelease, _FSEventStreamScheduleWithRunLoop, _FSEventStreamStart, _FSEventStreamStop, _FSEventStreamUnscheduleFromRunLoop

I believe that the offending package is System.IO.FileSystem.Watcher, which I'm guessing is referenced (and so ILLink won't remove, no matter what) because of this line: https://github.com/dotnet/aspnetcore/blob/fd9dfeccc1ab407a818d286128697b48149c384a/src/Components/WebView/WebView/src/StaticWebAssetsLoader.cs#L166.

Repro: Build the base MAUI Blazor template in Release+iOS+ARM64 and publish to App Store TestFlight, using the following in csproj:

<RuntimeIdentifier Condition="$(TargetFramework.Contains('-ios')) AND '$(Configuration)' == 'Release'">ios-arm64</RuntimeIdentifier>

Configuration

.NET 6 Preview 7
MAUI Single Project
Blazor + MAUI.WebView
iOS ARM64 Build

Regression?

Exact issue occurred w/ mtouch in 2019: mono/mono#14290

Other information

Tried many combinations of the following properties. MtouchLink=Full successfully removes System.IO.FileSystem.Watcher, but only because it also removes the default constructors for BlazorWebView. The following combo got me the closest to a resolution, but no dice, my best guess being because WebView.Maui.IOSWebViewManager inherits from WebView.WebViewManager, which instantiates PhysicalFileProvider during its static assets load.

<TrimMode>link</TrimMode>
<MtouchLink>SdkOnly</MtouchLink>
<_ExtraTrimmerArgs>-x linker.xml --action link "Microsoft.AspNetCore.Components.WebView" --action link "Microsoft.AspNetCore.Components.WebView.MauiSparc"</_ExtraTrimmerArgs>

linker.xml:

<linker>
	<assembly fullname="Microsoft.AspNetCore.Components.WebView.Maui">
		<type fullname="Microsoft.AspNetCore.Components.WebView.Maui.BlazorWebViewHandler">
		    <method signature="System.Void .ctor()" />
		</type>
	</assembly>
</linker>

Author:	josephatkuvio
Assignees:	-
Labels:	area-System.IO, untriaged, os-ios
Milestone:	6.0.0

[Eilon]

Interesting. If we simply disable usage of the file watcher in .NET MAUI Blazor Desktop apps, would that be enough? We should probably do that anyway because there's no need to watch for changes in a native app (it's useful in ASP.NET Core apps, though).

If we disable file watching entirely in Blazor Desktop, would it pass scrutiny in App Store testing? Or is even the existence of a potential code path that could call it enough to warrant rejection?