Repository navigation
MAUI iOS App Store rejection: App references non-public symbols _FSEventStreamCreate #57931
Description
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>
Activity
Redth commentedon Aug 24, 2021
// CC @dalexsoto and @rolfbjarne
akoeplinger commentedon Aug 24, 2021
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
Redth commentedon Aug 24, 2021
@akoeplinger what's the action here?
akoeplinger commentedon Aug 24, 2021
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 commentedon Aug 24, 2021
@Eilon might need your input here too
josephatkuvio commentedon Aug 24, 2021
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.Eilon commentedon Aug 25, 2021
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?
7 remaining items
Eilon commentedon Aug 26, 2021
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
PhysicalFileProvider: Use active polling instead of FileSystemWatcher…
adamsitnik commentedon Aug 26, 2021
@akoeplinger #58142 got merged, can we close the issue now or some work still remains?
akoeplinger commentedon Aug 26, 2021
I want to backport it to 6.0, just need to clarify whether it should be rc1 or rc2
PhysicalFileProvider: Use active polling instead of FileSystemWatcher…
PhysicalFileProvider: Use active polling instead of FileSystemWatcher…
akoeplinger commentedon Aug 26, 2021
Backported to 6.0-rc1.
Thanks again for the report @josephatkuvio !
Eilon commentedon Aug 26, 2021
@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 commentedon Aug 26, 2021
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.