Convert iOS SDK into dynamic framework

[1ec5]

make iproj now produces a target that pulls together static libraries like core and platform-ios into a true dynamic framework (as opposed to a static library executable stuffed inside a framework bundle). iosapp is pretty much just a regular iOS application that links Mapbox.framework (except for the inclusion of default_styles.hpp).

For now, I’ve patched support for code signing files in Copy Files build phases into the ancient checked-in copy of gyp, pending #3178.

Dynamic framework distribution relies on a shell script copied from realm/realm-swift#2759. This script works around an App Store bug.

Fixes #828, fixes #3161, paving the way for #1623. Based on #3135 for OS X.

/cc @incanus @friedbunny

[1ec5]

Current progress on make ipackage:

Code Sign error: No code signing identities found: No valid signing identities (i.e. certificate and private key pair) were found.

[1ec5]

Um, OK, so apparently the fix is to pass -showBuildSettings to xcodebuild. Huh? Edit: Never mind, that prevented the xcodebuild invocation from doing anything with the framework target.

[1ec5]

One downside to shipping a true dynamic framework (as opposed to a framework bundle containing a static library, as we do now) is that App Store submissions aren’t allowed to contain simulator content, as reported in Carthage/Carthage#188. If we ship a fat framework containing both device and simulator content, developers will need to strip the irrelevant content before code-signing. (Currently I’m relying on the “code sign on copy” build phase option that gets enabled when you use the Embedded Binaries section in the project editor.)

[1ec5]

Currently, make ipackage produces a fat framework (with both device and simulator content) that weighs in at 62 MB, and make ipackage-strip reduces it to 42 MB. We’ll have to add instructions for stripping simulator content before submitting to the App Store, like Realm’s, to get around this Xcode bug.

[tkrajacic]

Making the framework compatible with Carthage should now be possible which is awesome!

• The Xcode scheme that builds the framework needs to be shared for that purpose
• Better yet, the framework can be prebuilt

See https://github.com/Carthage/Carthage#supporting-carthage-for-your-framework

[1ec5]

package.sh now produces a pkg/ folder containing:

• a dynamically-linked, Bitcode-enabled framework in dynamic/
• a statically-linked, Bitcode-disabled framework in static/
• an example Settings.bundle
• API documentation in documentation/

To minimize our build and test matrix, I’ve omitted options for building a Bitcode-enabled static framework (for deploying back to iOS 7 in Xcode 7) or a Bitcode-disabled dynamic framework (for deploying to iOS 8.x only in Xcode 6.x).

[1ec5]

@friedbunny @incanus @bsudekum (and anyone else interested), I’d like your help with this test plan, in order of priority:

• CocoaPods (latest version only)
  • Dynamic framework
  • Static library with use_frameworks! (for iOS 7 or Bitcode-less application)
• Fabric – dynamic framework only
• Manual drag-and-drop into Xcode
  • Dynamic framework
  • Verify that the framework-stripping script plays nicely with Carthage-installed frameworks (which use a similar stripping mechanism) when exporting
  • Static library (for iOS 7 or Bitcode-less application)
• react-native-mapbox-gl
  • @bsudekum, this would be a good time for RNMBGL to drop support for iOS 7 so that you only have to distribute a dynamic framework via npm. You’ll need to update the Xcode project to refer to the .framework and remove references to the .a, .bundle, and headers from the project and this script.

Testing one of the workflows above generally involves answering the following questions:

• Do each of the following scenarios build without warnings or errors:
  • …in both Xcode 6.4 and Xcode 7.2?
  • …whether the application is written in Objective-C or Swift?
  • …whether the MGLMapView is initialized in a storyboard or programmatically (note that -ObjC is no longer required)?
  • …whether the access token is set in the Info.plist or programmatically via -[MGLAccountManager setAccessToken:]?
• If the MGLMapView is initialized in a storyboard, do inspectables and designables show up? (Xcode 6.4 doesn’t support designables in every case, so it’s fine if it doesn’t work there.)
• Does the application run without crashing on launch:
  • …in the oldest and newest iOS Simulator versions supported by the Xcode version you’re running?
  • …on at least one device? (For this PR, it probably isn’t particularly important to test on a wide array of devices.)
• Do assets like the Mapbox logo and default marker image appear?
• Does also linking CoreTelephony.framework work without crashing (Re-enable CoreTelephony.framework telemetry #3295)?

Let me know if you have any questions about how to test one of these cases. Thanks for your time; hopefully such drastic changes will be a rare occurrence going forward.

[friedbunny]

Going to start running through this list today, beginning with CocoaPods.

[friedbunny]

Ran in to #3300, but the post_install fix there works.

[friedbunny]

With CocoaPods and direct install, IBDesignables dies with:

No target found containing the source files defining MGLMapView. The class was found in MGLMapView+IBAdditions.h, MGLMapView.+MGLCustomStyleLayerAdditions.h, and MGLMapView.h. Make sure at least one of these files are in the target.

... the map itself loads as expected in app.

[chriszhang4213]

@1ec5 "The SDK is now distributed as a dynamic framework instead of a static library, resulting in a simpler installation workflow and significantly reduced download size. The framework contains both simulator and device content; due to an Xcode bug, you’ll need to strip out the simulator content before submitting your application to the App Store."

are you guys fix this? or we have to strip out the simulator content for 3.10 framework when submit to app store?

any guide for this?

[1ec5]

@chriszhang4213, if you follow the installation instructions in the README.md that’s in the ZIP file you download, you’ll be just fine. The last step automatically strips the simulator content for you. Sorry for not making that clear.

[chriszhang4213]

@1ec5, you mean
"1. In the Build Phases tab, click the + button at the top and select “New Run Script please�. Enter the following code into the script text field:

bash "${BUILT_PRODUCTS_DIR}/${FRAMEWORKS_FOLDER_PATH}/Mapbox.framework/strip-frameworks.sh"

"

this step right?

[1ec5]

Yes, that step will strip out any framework content that doesn’t match the architecture you’re building for. So when you export for the App Store, the script will strip out any simulator content.

[1ec5]

By the way, if you install using CocoaPods and the use_frameworks! flag, you don’t have to worry about this step at all.