Appcenter: Dynamic frameworks for macOS

[alexrinass]

Description

The macOS framework bundles are not properly symlinked inside the bundle. All symlinks appear to have been resolved before or during the archiving process.

This leads to code signing errors when the AppCenter frameworks are copied into the app bundle and signed. The signing of the frameworks actually succeeds, but when the app bundle is signed, an error is raised that the AppCenter frameworks are “not signed at all”.

Manually restoring all symlinks resolves the problem.

Normally, the framework bundle only contains files under e.g. Versions/A and then there is a symlink Versions/Current to Versions/A. All files in the framework bundle's root directory are symlinked to files within Versions/Current.

Repro Steps

1. Download Release archive 2.4.0 and unzip in Finder
2. Inspect the framework bundles

Details

1. Which SDK version are you using?
   
   
   
   • 2.4.0
   
   
2. Which OS version did you experience the issue on?
   
   
   
   • macOS 10.15
   
   

[russelarms]

Hi there! Thank you for pointing this out, I'll consult with the team and get back to you soon.

[thyeggman]

Hi @alexrinass - we don't link the frameworks according to the typical specification because we use static frameworks. If you don't embed the frameworks, they don't need to be signed independently.
We have a note on this in our documentation (see purple note box).

Sorry for the confusion, it's an uncommon pattern for MacOS 😅

[ghost]

I can confirm - setting the App Center frameworks to "Do Not Embed" under the General tab of the target and removing them from my code signing scripts fixed the same issue.

May I ask the reason you're overriding MACH_O_TYPE = staticlib, and not providing both a dynamic library and a static library target eg. libAppCenter.a? Convenience / reduction of targets, or something else? Since Xcode will always assume it's a dynamic framework (due to CFBundlePackageType set to FMWK in addition to the .framework extension), I'd imagine more macOS devs might come across this problem, especially with more involved codesigning processes.

Just to add for others reading this, the code signing error you'll probably receive when running codesign on the framework is AppCenter.framework: bundle format is ambiguous (could be app or framework).

[thyeggman]

@rafifyalda We distribute static frameworks for performance reasons. When an app gets to about 6 dynamic frameworks it starts taking a big hit to startup times. Since our SDK is designed to be modular, when someone wants to use several modules, they need to include all the individual frameworks. We want to keep our SDK as lightweight as possible so end users won't notice any change when the App Center SDK is integrated. It's an unintuitive pattern in this case, but it does provide benefits.

[thyeggman]

I just talked to another co-worker, the performance consideration I mention is more important for iOS than it is for MacOS. It's possible that we could still release dynamic frameworks for MacOS, it's just a matter of getting around to doing the work 😅

[alexrinass]

@jwallra Thank you for clarification. I actually followed the instructions you mentioned when I started integrating AppCenter and did not embed the frameworks. I then resumed work a couple of days later and wondered why they weren't embedded and embedded them. So it can get confusing, yes.

[alexrinass]

I took a quick look at the Xcode project and the framework product that is created actually has the correct symlinks.

Is it really crucial to resolve the symlinks before release? I have currently only linked (not embedded ) the frameworks with the symlinks restored and it also works.

Resolving the symlinks before release triples the size of the ZIP as there is a double symlink that is resolved (e.g. AppCenter.framework/AppCenter -> AppCenter.framework/Versions/Current/AppCenter -> AppCenter.framework/Versions/A/AppCenter).

[alexrinass]

Are there any special obstacles to make the macOS framework a dynamic one? From briefly looking at the code I'd say it is “just” updating the build settings, but I could be missing something of course. I would volunteer to give it a shot.

[ghost]

@jwallra Thanks for the info. I'm coming from HockeySDK (which had both static and dynamic framework targets), though I was making use of the dynamic framework and didn't notice any launch delays. In fact I was delaying app launch to submit launch crash reports automatically (as per previous instructions at https://support.hockeyapp.net/kb/client-integration-ios-mac-os-x-tvos/how-to-handle-crashes-during-startup-on-ios-and-os-x).

It's not a huge deal to not have a static library at the moment as I don't link HockeyApp/AC with my non-app targets, though I would definitely appreciate a more consistent macOS integration process. For now I've just left a note in my codesigning shell-scripts to remind me of this workaround.

[thyeggman]

@alexrinass If you'd like to try creating the dynamic frameworks, you're welcome to. You'll also need to update the MacOS test app ("Sasquatch") with the new framework.

On our end, once the change looks good, we'll need to update our CI and documentation. It may be a while before we get around to it, but we'd love your contribution!

[ahdbilal]

I am transferring this issue to AppCenter Central Repository where all the new feature requests are being tracked and prioritized. Thanks

[schriftgestalt]

I just stumbled over that, too.
So either use a framework (those are supposed to be dynamic, that is the whole point of it) or static libraries. But don’t mix the two concepts. That is really confusing.

[msftbot[bot]]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[msftbot[bot]]

This issue will now be closed because it hasn't had any activity for 15 days after stale. Please feel free to open a new issue if you still have a question/issue or suggestion.