Add support for network extension on Mac Catalyst #17408
Comments
|
What kind of app extension are you trying to create? As far as I know Apple doesn't support any app extensions on Mac Catalyst (but it was a while I checked, so this may have changed). |
rolfbjarne
added
the
need-info
|
Hi @enclave-alistair. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time. |
|
We're creating a network extension; the apple docs indicate that Mac Catalyst is a supported platform for a PacketTunnelProvider: It's possible that not all app extensions are supported for Mac Catalyst, but certainly Network Extensions should be. |
ghost
added
need-attention
|
Yes, from that documentation it certainly looks like Network extensions are supposed on Mac Catalyst. This needs some work on our side, so it may unfortunately take some time to get it done (the earliest would likely be .NET 8 this fall). |
rolfbjarne
added
feature
|
Do you think it's worth my experimenting with creating functional
MacCatalyst versions of the targets files in the meantime? It is after all
intended to be pretty close to iOS...right? Or are you expecting there to
be way more to do than just setting up the build system for it?
|
Extensions have been somewhat of a mixed bag in the past, some of them have been really easy, some have required a lot more work. IIRC network extensions haven't been problematic on iOS, so it might be that just creating the missing targets files would work on Mac Catalyst (it's the right approach though, so even if you're not able to get all the way there, it's a step in the right direction). |
|
Thanks @rolfbjarne , will investigate and report back. |
|
Wanted to give an update; I've made some progress getting I've got a branch in my fork with my changes so far: https://github.com/enclave-alistair/xamarin-macios/tree/feature/maccatalyst-ext-7.0.1xx In short, a maccatalyst appex does now build successfully, and I get a built - MacCatalyst.Extension.appex
- Contents
- MacOS
- MacCatalyst.Extension (binary executable)
- MonoBundle
- .xamarin
- maccatalyst-arm64
- MacCatalyst.Extension.dll
- System.Private.CoreLib.dll
- System.Runtime.dll
- maccatalyst-x64
- MacCatalyst.Extension.dll
- System.Private.CoreLib.dll
- System.Runtime.dll
- MacCatalyst.Extension.aotdata.arm64
- System.Private.CoreLib.aotdata.arm64
- System.Runtime.aotdata.arm64
- icudt.dat
- libSystem.IO.Compression.Native.dylib
- libSystem.Native.dylib
- libSystem.Net.Security.Native.dylib
- libSystem.Security.Cryptography.Native.Apple.dylib
- libmonosgen-2.0.dylib
- libxamarin-dotnet.dylib
- Info.plistThe That all looks right. The problem I'm having now is when I try to reference an app extension in a regular UI project. I'm getting an error in the I think the problem is that the appex created in the extension project is already universal, but I can see that the Here is the latest binlog with the I'm continuing to investigate, but if anyone has some pointers on the app bundle merge problem, feel free to help out! |
|
@enclave-alistair as a first step (to see if there are other problems), you could try creating a non-universal app. You can do that by setting RuntimeIdentifier: <PropertyGroup>
<RuntimeIdentifier>maccatalyst-x64</RuntimeIdentifier>
</PropertyGroup> |
|
Ah, good tip @rolfbjarne; tried that, and the build fails later in I actually think that xamarin-macios/msbuild/Xamarin.Shared/Xamarin.Shared.targets Lines 2239 to 2242 in 316d371 I'll try fixing that Updated binlog: macbinlog.zip |
Yes, that sounds like the reason for this failure. |
|
Even more progress now, everything builds successfully, the appex is copied into the right folder, and codesigning appears to take place correctly. 🥳 However, when I try to launch the app locally on my Mac, it crashes instantly with: Full crash report: crashreport.txt I manually verified the signatures of both the Maui App, and the extension: I wondered if it might be an issue with the entitlements, but those all look OK. Something I did notice, but might be a red herring, is a difference between the codesigning outputs of iOS vs MacCatalyst; when the iOS UI app is signed, it's However for the maccatalyst build the signature looks like it's included "byref", using a This is most likely not a problem, and just a difference in how macOS and iOS signing works, but wanted to include it just in case. I'll try to do more digging into the signature problem, but now I'm outside msbuild my direction becomes less clear. Oh, and here's the latest binlog (of the successful build): macbinlog-successful-build.zip |
Sometimes the system Console will give more information about the crash. Since this is the main app crashing, and not the extension, one idea might be to try to narrow it down: does it still crash if you remove the extension from the main project? Another option is to modify the .app bundle directly, and then replay the codesigning commands (you can find the codesign command in the binlog) - for instance you could remove the |
|
Urgh, thanks for the tip re:Console, realised my local provisioning profile didn't have my device in it for some reason; fixed that and app launches correctly. App extension fails to start though with a "ASP: Security policy would not allow process" error which I'm digging in to now. |
|
Figured it out, all app extensions on MacCatalyst appear to need the Once I added that, and the network client + server entitlements needed in the sandbox (more info), everything started to work! 🎉
Perhaps .NET should automatically add the |
That's great news!
Yes, that's not a bad idea, but it can be done separately from adding support to Mac Catalyst extensions (note that unless it's documented by Apple, we'll have to assume that the requirements might differ between different types of extensions). |
|
Fair point. Can be solved with documentation anyway. What's the path to me raising a PR from my branch? I haven't merged a change in this repo before, are there tests and/or test projects that need creating? |
|
Oh, just remembered I need to figure out the universal bundle problem I skipped over, need to resolve that before this can be considered fixed. |
|
@enclave-alistair were you able to make this work? Would it be possible to get access to your source code to create a test project we can use? |
|
Hi @rolfbjarne; I was able to do everything except the universal bundling problem, I couldn't figure that out and ran out of time. My branch commits: Made the build work for the individual architectures. I just wasn't able to figure out the universal bundling for MacCatalyst. A full app project with network extension and UI example may be tricky, but I'll see what I can do. |
rolfbjarne
changed the title
|
Apologies for the delay on getting the example project to you, once I allocated some time for it it took a while to strip out all of our specific code down to the minimum, and then when I wanted to update it to net8-rc1 I ran into a few regressions I wasn't expecting. You can find a demo net8 iOS app with a network extension here: https://github.com/enclave-alistair/dotnet-ios-netextension. This runs OK (ish) on net8 iOS, but will not build on MacCatalyst. Now that the typo has been fixed, the remaining errors seem to be around missing targets file. There was also an unnerving regression seemingly related to dotnet/linker#3165 that means you can't build AppExtensions in MAUI at all without a workaround (as far as I can tell). @rolfbjarne, shall I raise that as a separate issue, since it's a regression not related to maccatalyst? |
That's wonderful!
Yes, please file an issue in this repo and I'll have a look. |
|
Wanted to update this issue as I've done some more investigation, thought I'd drop my findings here. The remaining issue when building for MacCatalyst comes from the I've got an otherwise working branch here. In more detail, here's what actually happens when I kick off a The app splits the build of itself for x64 and arm64 into separate runtime-specific builds ( Each runtime-specific build identifies a dependency of the app extension and builds the app extension for a specific architecture. Each runtime-specific build of the app identifies that there is an app extension build for that runtime, and correctly places it under the The runtime-specific builds complete and generates the app bundle; at this point the output file tree of the app build looks a bit like (some files/folders excluded): The architecture-specific-version of the app contains the architecture-specific version of the app extension. We then come to This process would work just fine if it wasn't for the However, the app extension The individual MachO files are merged correctly, and a multi-arch MachO file does end up in the merged bundle for the plugin. I see two options to solve this:
Any thoughts/suggestions @rolfbjarne would obviously be most welcome. |
|
Hi @rolfbjarne, apologies for a chasing comment, I just wondered if you'd seen my prior comment around the issue with merging bundles, now we're a fair way past the .NET 8 release? Happy to continue more work on this fix if you have some direction on how to resolve the merging problem. |
|
@enclave-alistair yes, I saw your comment, I've been a bit busy with other work for a while. To your two options: I think the first one sounds like the cleanest approach. In fact I might have done part of the work already, because we now (in the In any case my plan is to look at this in the .NET 9 timeframe. |
|
Appreciate the response, I know you've got a lot of other things going on. I'll take a look at the build again based off main. Also appreciate the planned .NET9 timeframe if I fail to make any progress! |
Steps to Reproduce
dotnet build /blExpected Behavior
That I can create an App Extension targeting net7.0-maccatalyst.
Actual Behavior
I cannot build the App Extension.
Additional Investigation
I've gone looking for why the
_CollectBundleResourcestask does not exist, and I've boiled it down to (partly) what appears to be a typo inXamarin.Shared.Sdk.targets, whereMacCatalystAppExtensionProjectis speltMacCatalystSAppExtensionProject:xamarin-macios/dotnet/targets/Xamarin.Shared.Sdk.targets
Line 1967 in 610deb1
However, fixing the typo isn't enough, because MacCatalyst is missing the
Xamarin.MacCatalyst.AppExtension.CSharp.targetsfile that the iOS build does have, so fails to import it. I suspect, although haven't tried it all the way through, that creating the correct AppExtension targets and props file for MacCatalyst that duplicate the iOS ones may do the job, but can't state that's definitely the right approach.Environment
Version information
Build Logs
msbuild.zip
Example Project
ReproProject.zip
The text was updated successfully, but these errors were encountered: