How to use with Mac Catalyst

[mattjohnsonpint]

trafficstars

Description

I see several mentions of Mac Catalyst in the repo, docs, and issues, so I believe it should be supported, but I don't see a folder with the maccatalyst platform variant in the xcframework.zip of the release.

Some background: I'm working on adding iOS bindings to the Sentry .NET SDK. .NET has a separate target for net6.0-ios and net6.0-maccatalyst. I have it working for iOS via a Xamarin bindings project, which correctly finds the ios-arm64_armv7 and ios-arm64_i386_x86_64-simulator folders under Carthage/Build/Sentry.xcframework. Everything appears to be working great for iOS.

But for Mac Catalyst, my build is failing with the following (.NET build error):

... error : No matching framework found inside '.../Sentry.xcframework'.
... error :          SupportedPlatform: 'ios', SupportedPlatformVariant: 'maccatalyst', SupportedArchitectures: 'x86_64'.

I've traced this back to the Xamarin SDK here, which appear that it's expecting maccatalyst to be a platform variant in the same way that simulator is, along with its own folder, build output, and entry in Info.plist.

If this is a correct assumption on the .NET/Xamarin team's part, how do I get that out of the Sentry Cocoa SDK? Basically, it's looking for ios-arm64_x86_64-maccatalyst. I'm also not sure if it also needs another one for Apple Silicon or if that would be included there.

I've stumbled upon https://github.com/Carthage/Carthage/pull/3235 which hasn't been merged yet with Carthage, so does that mean that I can't do this?

Additionally, I tried using the "fat" framework instead (Carthage/Build/iOS/Sentry.framework in Sentry.framework.zip). It too works on iOS, but for Mac Catalyst gives a different error:

  ld: building for Mac Catalyst, but linking in dylib built for iOS Simulator, file '.../Sentry.framework/Sentry' for architecture x86_64
  clang: error: linker command failed with exit code 1 (use -v to see invocation)

I do have control over linker flags and a few other options, but couldn't seem to figure out what to pass.

Any help is appreciated. Thanks.

(note, ... in above errors is where I removed paths and things that aren't relevant to this question.)

[brustolin]

AFAIK maccatalist is an iOS build with support to run on Mac. So, still building for iOS, but different settings.

[mattjohnsonpint]

Agreed, but if I just use the iOS versions that are currently built then I get that linker error ("ld: building for Mac Catalyst, but linking in dylib built for iOS Simulator") - so I believe there's something that has to be done at build time to support this variant.

[brustolin]

@bruno-garcia Any idea about this?

[mattjohnsonpint]

FYI - the code in https://github.com/Carthage/Carthage/pull/3235 gives me what I need when I ask it to package just the macCatalyst platform. However, it errors if I try to run it against all platforms we need. I guess it's not quite ready to merge into Carthage.

However, I can still use it as a workaround for now, by updating the makefile (locally) to use both versions

  build-xcframework:
    @echo "--> Carthage: creating Sentry xcframework"
      carthage build --use-xcframeworks --no-skip-current
+ # add macCatalyst using custom build of Carthage from https://github.com/Carthage/Carthage/pull/3235	
+     /usr/local/bin/carthage build --use-xcframeworks --no-skip-current --platform macCatalyst 
  # use ditto here to avoid clobbering symlinks which exist in macOS frameworks
      ditto -c -k -X --rsrc --keepParent Carthage Sentry.xcframework.zip

The resulting zip has everything I need, and it looks like Carthage is smart enough to update the plist and not step on output from other platforms.

I'll use this approach as a workaround until Carthage supports it natively.

BTW - I tried figuring out what xcodebuild commands would mimic exactly what Carthage is doing in that PR, but never quite got it working. I got build output, but it was labeled wrong and wouldn't link to a test app.

[mattjohnsonpint]

The resulting output folder after the workaround looks like this:

The Info.plist contains all the usual stuff, plus now this:

<dict>
    <key>DebugSymbolsPath</key>
    <string>dSYMs</string>
    <key>LibraryIdentifier</key>
    <string>ios-arm64_x86_64-maccatalyst</string>
    <key>LibraryPath</key>
    <string>Sentry.framework</string>
    <key>SupportedArchitectures</key>
    <array>
        <string>arm64</string>
        <string>x86_64</string>
    </array>
    <key>SupportedPlatform</key>
    <string>ios</string>
    <key>SupportedPlatformVariant</key>
    <string>maccatalyst</string>
</dict>

[mattjohnsonpint]

FYI, I found the cause of the error I mentioned earlier. https://github.com/Carthage/Carthage/pull/3235#pullrequestreview-1069986893

[mattjohnsonpint]

So at this point, all we need is for the Carthage PR to be merged and released, then we need to update to that version of Carthage for the following version of Sentry Cocoa.

If anyone has the time & skills to help @NachoSoto finish that up, that would be much appreciated. Thanks!

[NachoSoto]

It's just a matter of spare time. But if there's motivation and the need to wrap that up, and I can get help with testing, I could get it done. The main blocker is that I believe that branch breaks non-xcframeworks.

[philipphofmann]

I'm not an expert on .NET MAUI, but could you include the Cocoa SDK via Swift Package Manager or CocoaPods, @mattjohnsonpint? Maybe that solves your issue?

[philipphofmann]

@NachoSoto, thanks for offering your help. We would be happy to help with testing it out, but I don't have the resources right now to resolve your main blocker.

[mattjohnsonpint]

@philipphofmann - I tried that, but unfortunately without success.

• .NET's support for CocoaPods is via the Xamarin sharpie pod command, which is broken. Currently there isn't a workaround, and Microsoft appears to have no interest in fixing it.

• Using Swift packages in .NET requires building a proxy library, which is just a layer of indirection to get back to the native code that we already have. While this might be possible, it seemed like too much work for too little outcome.

Also, since we currently have a workaround - I'm ok using that until Carthage supports this directly. Alternatively, we could change Sentry-Cocoa's build process to use a custom build of Carthage that includes the pull request (with my one suggested change) to make the xcframework zip.

[philipphofmann]

I think that MacCatalyst, anyways, is not widely adopted. I'm pretty sure not many people will use it in combination with .NET MAUI. Therefore, I think it's OK to wait until Carthage supports this directly and not use a custom build of Carthage.

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[mattjohnsonpint]

Just to respond on this point:

I think that MacCatalyst, anyways, is not widely adopted. I'm pretty sure not many people will use it in combination with .NET MAUI.

Because it's the primary way that Microsoft is promoting MAUI as being able to build macOS desktop apps, and it's targeted by default, I believe MAUI will only increase the adoption of Mac Catalyst.

[mattjohnsonpint]

Quick update - I've changed the sentry-dotnet build process to take in sentry-cocoa as a submodule, and also take Carthage as a submodule from their xcframework-catalyst branch. At build time (both locally and in CI), I build the custom Carthage and cache it, then use it to build sentry-cocoa and cache that as well (rebuilding it only when sha of the submodule changes).

Our build command for sentry-cocoa is:

carthage build --use-xcframeworks --no-skip-current --platform ios,macCatalyst

... which works because the xcframework-catalyst version of Carthage supports macCatalyst as a platform for xcframeworks.

Since this is all automated now, there's nothing to track except to watch for those changes to merge into an official release of Carthage. 😃