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>

[dotnet-issue-labeler]

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.

[ghost]

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?

[rolfbjarne]

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?

We know that Apple just searches for strings in some cases, so if the code is in the app, Apple won't accept it, even though it'll never be called.

[akoeplinger]

I'm working on a PR that switches to active polling mode for PhysicalFileProvider like we use on Browser (#56189) and enable PNSE for FileSystemWatcher, that will remove the disallowed functions from the assemblies.

I agree that turning off file watching in Blazor Desktop is a good change too since then we won't have the overhead of active polling.

[Eilon]

I talked to @javiercn who is the expert on this, and we don't do any actual file watching for any Blazor Desktop scenarios, so we're not actually doing any file system watcher.

However, if you walk through code paths, there is "access" to the file system watcher APIs.

Can/should we add some kind of hints so that the linker can trim out these code paths so that they don't end up in the app bundle?

[josephatkuvio]

@Eilon @javiercn The offending code path that I found is in the constructor for WebViewManager itself: https://github.com/dotnet/aspnetcore/blob/fd9dfeccc1ab407a818d286128697b48149c384a/src/Components/WebView/WebView/src/WebViewManager.cs#L50

Which ends up calling this line, which is the primary issue (and I verified because I rebuilt aspnetcore using IFileProvider here instead and poof, the linker removed the DLL): https://github.com/dotnet/aspnetcore/blob/fd9dfeccc1ab407a818d286128697b48149c384a/src/Components/WebView/WebView/src/StaticWebAssetsLoader.cs#L166

[Eilon]

Got it. I think we can easily remove references to PhysicalFileProvider from WebViewManager and use that only in particular platforms where we care (some specific Windows-only scenarios).

I logged dotnet/aspnetcore#35707 to get this done in ASP.NET Core

Does this issue still need to remain open here for any purpose?

[akoeplinger]

Yeah let's keep this open until I land my change for making PhysicalFileProvider use polling on iOS, which will solve the issue too. Users will hit this as soon as they pull in System.IO.FileSystem.Watcher.dll for any reason right now.

[Eilon]

Here's the PR for ASP.NET Core to remove the reference to PhysicalFileProvider, which is where the file system watcher stuff is called (though not actually used in these scenarios): dotnet/aspnetcore#35750

[adamsitnik]

@akoeplinger #58142 got merged, can we close the issue now or some work still remains?

[akoeplinger]

I want to backport it to 6.0, just need to clarify whether it should be rc1 or rc2

[akoeplinger]

Backported to 6.0-rc1.

Thanks again for the report @josephatkuvio !

[Eilon]

@akoeplinger so with this change, it's safe for all iOS to use PhysicalFileProvider, because now on iOS there won't even be a reference to the File Watcher at all? As in, nothing in the set of assemblies that might conceivably be deployed in the app package (IPK) would contain apparent usage of File Watcher? (Obviously someone could manually write such code, but I'm talking only about using these "standard" types.)

[akoeplinger]

That's correct, the System.IO.FileSystem.Watcher.dll is basically empty on iOS and every method will just throw PlatformNotSupportedException now.

That means there's no reference to the disallowed native APIs anymore.