fix(ios): handle xcframework packages

[janvennemann]

JIRA: https://jira.appcelerator.org/browse/TIMOB-28154

This fixes a couple of issues with XCFramework packages introduced in 9.2.0:

• Hyperloop tried to parse the native module library when it should be ignored.
• The internal framework handling couldn't properly parse the nested content of .xcframework packages. This is kind of a hacky fix since i only read in the headers from the first architecture listed in the Info.plist. I assume there is a possibility of the individual architectures exposing different different headers/types? Do we need to handle that? Should we check and make sure to use an arch that target's the ios platform in case the XCFramework contain macos archs as well?
• The LD_RUNPATH_SEARCH_PATHS contains the correct values by default now so it doesn't need to be changed by Hyperloop.

[ssjsamir]

FR passed, Able to build the Hyperloop module while still using another module, In this case ti.Identity.

However When I tried using the artificats from https://jenkins.appcelerator.org/blue/organizations/jenkins/titanium-sdk%2Fhyperloop.next/detail/PR-345/2/artifacts/ to build my application I saw the following error. (Could just be related to Big Sur and I was unable to block by going to security settings and allowing 'metabase')

Test Environment

MacOS Big Sur: 11.0 Beta 7
Xcode: 12.0 
Java Version: 1.8.0_242
Android NDK: 21.3.6528147
Node.js: 12.18.1
""NPM":"5.0.0","CLI":"8.1.1""
Iphone 11 Sim (14.0)

[ewanharris]

@ssjsamir I think that's potentially just an artifact of downloading and using the zipped module from the Jenkins UI as opposed to being installed from the SDK zip itself. Although we probably need to be wary about the possibility of Apple requiring the binary to be signed in future I think @janvennemann @sgtcoolguy

[janvennemann]

@ewanharris @ssjsamir I've noticed similar notifications after downloading a Hyperloop release from our hyperloop-builds repo. However, after clicking "Cancel" i was able to manually allow it via System Preferences > Security & Privacy > General.

I'm not sure if just signing the binary is enough to get rid of this warning or if we even need to notarize it, which could be an issue because AFAIK only installer packages can be notarized and not the command line tool itself. We probably should file a ticket to double check this.

[ewanharris]

Eurgh yeah I forgot about the notarization process, I think this should be fine to merge then @ssjsamir

[lokeshchdhry]

I have seen the metabase error as well. After I did a cancel & allow it in the security settings it did not come up again.
@ewanharris , do we plan to notarize it or something ? or it should be ok ?

[ewanharris]

@lokeshchdhry, Jan is right the notarisation only applies to Mac apps, installer packages, and kernel extensions so the metabase parser can't be notarized, it's possible we could codesign it like this to maybe prevent that warning eventually

Did you also see this when downloading from Jenkins? I haven't heard of anyone complain about this issue in the community, and I myself only get blocked from running it when download via Jenkins/GitHub, not when hyperloop gets installed by the SDK so for now I think we're fine to punt down the road.

Edit: I took a quick look at what is causing browser downloads to fail, it's because the OS is marking them with a com.apple.quarantine attribute (see here) whereas when installed by the SDK it doesn't have that attribute

[lokeshchdhry]

@ewanharris , yes I agree I only see it when downloaded via jenkins & not via SDK. Merging it.