runtime: MAUI iOS App Store rejection: App references non-public symbols _FSEventStreamCreate
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: https://github.com/mono/mono/issues/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>
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 21 (18 by maintainers)
Commits related to this issue
- PhysicalFileProvider: Use active polling instead of FileSystemWatcher on iOS/tvOS In https://github.com/dotnet/runtime/issues/57931 we found out that the FSEventStream APIs which are used to implemen... — committed to akoeplinger/runtime by akoeplinger 3 years ago
- PhysicalFileProvider: Use active polling instead of FileSystemWatcher on iOS/tvOS In https://github.com/dotnet/runtime/issues/57931 we found out that the FSEventStream APIs which are used to implemen... — committed to akoeplinger/runtime by akoeplinger 3 years ago
- PhysicalFileProvider: Use active polling instead of FileSystemWatcher on iOS/tvOS (#58142) In https://github.com/dotnet/runtime/issues/57931 we found out that the FSEventStream APIs which are used to... — committed to dotnet/runtime by akoeplinger 3 years ago
- PhysicalFileProvider: Use active polling instead of FileSystemWatcher on iOS/tvOS In https://github.com/dotnet/runtime/issues/57931 we found out that the FSEventStream APIs which are used to implemen... — committed to dotnet/runtime by akoeplinger 3 years ago
- PhysicalFileProvider: Use active polling instead of FileSystemWatcher on iOS/tvOS (#58165) In https://github.com/dotnet/runtime/issues/57931 we found out that the FSEventStream APIs which are used to... — committed to dotnet/runtime by github-actions[bot] 3 years ago
I was able to resolve it for my personal case by removing the hardcoded reference to
PhysicalFileProviderand replacing it with theIFileProviderfrom 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.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.
Backported to 6.0-rc1.
Thanks again for the report @josephatkuvio !
I want to backport it to 6.0, just need to clarify whether it should be rc1 or rc2
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.