Dynamic framework #412
Merged
Dynamic framework #412
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
• For historical reasons, OneSignal's iOS framework was a static framework, not a dynamic framework. • However, for some wrapper SDK's like Flutter, this causes issues with cocoapods. Any cocoapod in a project that uses use_frameworks! must not have any static dependencies • To fix this, we are considering adding a subspec to fix the problem, but will allow some of our users to test this branch in the mean time TODO: • We want this dynamic framework to run on iOS devices as well as run in the iOS simulator (x86_64 and i386 architectures) • To do this, we've made this a fat framework that contains slices for: arm64, armv7, x86_64, and i386 • However, Apple will not allow app submissions that contain fat frameworks • So we will soon need to create a build script developers can add to their apps that strips the simulator architecture slices from the framework, so developers don't run into this issue. • We will want to investigate if we can make this buildscript a part of our cocoapod target, or if it will require developers to add the script to their xcode projects.
• It appears iOS framework codesigning fails if the framework uses symlinks and versions • Changed the build script so that the SDK will put all relevant directories in the root of the framework, instead of using symlinks at the root and a Versions/A folder • Created a new aggregate target that uses a buildscript to create a universal dynamic framework. • The new aggregate target uses a buildscript to generate two static libraries, one for simulator (x86_64 and i386) and one for real devices (arm64 and armv7), it then uses lipo to combine these into a single dynamic fat framework NOTE: The framework produced by the new dynamic target does not actually create its own product, it simply generates a new framework in the repo's /iOS_SDK/OneSignalSDK/Framework folder.
• We do not want to immediately switch all users to use our new fat dynamic framework • However we do want it to be available on Cocoapods, so we've created an additional podspec & framework path • When the project was started years back, the OneSignal-Dynamic target was actually creating a static framework, so I've renamed this target to OneSignal-Static-Framework • The new OneSignal-Dynamic-Framework is just an aggregate framework. It does not directly produce its own product. Instead it uses a build script to produce a dynamic framework at repo/iOS_SDK/OneSignalSDK/Framework/Dynamic/OneSignal.framework
• Fix merge conflict (static framework)
|
Josh (@jkasten2) is on vacation for a while. Since this PR does not modify our existing release/functionality I can without review for the time being. |
Nightsd01
added a commit
that referenced
this pull request
Sep 25, 2018
This reverts commit ad7ce9f.
Nightsd01
added a commit
that referenced
this pull request
Sep 25, 2018
This reverts commit ad7ce9f.
Nightsd01
added a commit
that referenced
this pull request
Sep 25, 2018
* revert-412-dynamic_framework: Revert "Dynamic framework (#412)" Revert "2.8.8 Release" Revert "Request reattempt fix (#418)" # Conflicts: # OneSignal.podspec # OneSignalDynamic.podspec # iOS_SDK/OneSignalSDK/Framework/Dynamic/OneSignal.framework/OneSignal # iOS_SDK/OneSignalSDK/Source/OneSignal.m # iOS_SDK/OneSignalSDK/UnitTests/UnitTests.m NOTE: Mistakes during a merge from branch `dynamic_framework` to `master` led to some previous bug fixes being reverted. • Using a partial revert merge to undo these reversions
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
• Adds a
OneSignal-Dynamic-Frameworktarget to the project. This target is an aggregate target (does not directly output a product), it uses a buildscript to merge several Frameworks for different architectures (ie. x86_64 for simulator, arm64 for device) and produces a single fat dynamic framework• The motivation for this change is that some wrapper SDK's use our iOS SDK as a cocoapod dependency. But in Swift projects that use
use_frameworks!, no cocoapod dependency can depend on a static framework. Since our Flutter SDK (for example) uses our iOS SDK (which is a static framework), this caused a lot of issues for Swift/Flutter/React-Native/etc. developers• To fix this, we've added a dynamic framework cocoapod in addition to our traditional cocoapod called
OneSignalDynamic• The dynamic framework is located at
{repo}/iOS_SDK/OneSignalSDK/Framework/Dynamic/OneSignal.framework• Also, when the project was initially created, the original developer/s named the framework target
OneSignal-Dynamicbut it actually outputs a static framework, for this reason I have renamed the target toOneSignal-Static-Framework.• Another point of confusion to be aware of is that historically it's actually the
OneSignaltarget that produces our static framework that gets used by cocoapods, it uses a buildscript to do this as well.This change is