Add build target for dynamic framework to support

[mowens]

With the introduction of swift, and cocoapods lack of swift support, it would be nice (and likely needed once cocoapods does support swift - e.g dynamic frameworks) to support building typhoon as a dynamic framework. This is necessary for supported typhoon DI in swift libraries that themselves build dynamic frameworks and link into the main app project.

For example, say I have the following swift projects that build dynamic frameworks:

XXFoo-> XXFoo.framework
XXBar -> XXBar.framework

These libraries are then linked into my main app project, XXMyApp. In order for XXMyApp to leverage Typhoon DI, cocoapods can be used to create a libPods.a static library with the Typhoon source and a bridging header (XXMyApp-Bridging-header.h) can be created and #import "Tyhoon.h". Now this is al well and good if all of my Typhoon assemblies exist in XXMyApp, however, if I truly want to leverage the power of DI in XXFoo and XXBar I should be able to define my TyphoonAssembly factories in each library and import them for use in XXMyApp. This way each library would be responsible for setting up its own dependencies.

This is currently not possible with the pods approach as you cannot link a static library (e.g. libPods.a) into a dynamic swift framework. You can however link to dynamic frameworks, so if Typhoon was able to build a dynamic framework (e.g. Typhoon.framework) then XXFoo, XXBar and XXMyApp could link against it; XXFoo and XXBar could define their own assemblies and XXMyApp would be able to instantiate them.

Because dynamic frameworks are not yet supported by cocoapods, the approach that several swift-only libraries are taking are git modules, so swift libraries want to dynamic link against Typhoon could:

1. Create a git submodule
2. Add Typhoon.xcodeproj to their workspace
3. Add Typhoon.framework as a target dependencies in the build phases
4. Add a "Copy Frameworks" build phase and copy Typhoon.framwork to their Frameworks path

[jasperblues]

Hi @mowens

Our build server publishes some artifacts up to www.typhoonframework.org for each successful build, so we'd be able to include this as part of that.

If you'd like to do the build target? I'll do the build server part and put a link on GitHub and www.typhoonframework.org

[mowens]

For the time being, Apple has recommended not linking against pre-built binaries using the swift compiler as it is still young. So I believe the "ideal" integration would be a git submodule and link directly against the build artifact from the Typhoon xcodeproject.

I will start looking into/working on the dynamic framework build target.

[jasperblues]

Thanks @mowens, that is excellent. Have you seen this issue: #286 ?

Its second highest priority, but neither @alexgarbarev or I have been able to look at it yet.

[mowens]

@jasperblues PR: #290

[jasperblues]

Ready to close?

[jasperblues]

@mowens how about using Carthage package manager for Swift?

[jasperblues]

https://github.com/Carthage/Carthage

[mowens]

@jasperblues sorry it took so long to get back to you. I have taken a look at Carthage and I like the concept as it doesn't mock with project settings like Cocoapods does but the project is still pretty young. Currently, I couldn't get Carthage to build Typhoon out-of-the-box. I didn't look too much into the failure case, but seems to be schema related.

A downfall of Carthage is it is (more or less) a wrapper around git and xcodebuild, which means developing local pods would be a pain in the ass (not that it is much better with Cocoapods but it is better).

A beta has been released for Swift and framework support for Cocoapods which I am currently looking into. It doesn't build Typhoon as a framework out-of-the-box either, but with a few teaks i'm sure it can! IMO pods would support should take precedence to Carthage. Thoughts?

[mowens]

@jasperblues Typhoon does work with Cocoapods 0.3.6 beta out of the box! For swift libraries/apps that need to link against Typhoon they must specify in their pod file that it uses frameworks

# platform *must* be atleast 8.0
platform :ios, '8.0'

# flag makes all dependencies build as frameworks
use_frameworks!

# framework dependencies
pod 'Typhoon', '2.3.3'

[jasperblues]

great work@mowens. lets stick with cocoa pods for now. We may need to support carthage when it becomes popular

[mowens]

Agreed

[StyleOffDev]

Hey guys, we're currently using carthage and we would like to include Typhoon in it. Is it a good time to reconsider adding support for Carthage ?

According to the Carthage docs, it should just be a matter of marking your schemes as shared.

[jasperblues]

All schemes were shared except for the Typhoon Framework scheme. . . i shared it and pushed to master. Next step?

[jarod2d]

Hmm, I'm not seeing the push to master. I just tested it locally, and marking the Typhoon framework scheme as shared was sufficient to allow Typhoon to be compatible with Carthage. So once that commit is available in master, it doesn't look like any other changes need to be made, fortunately.

[jasperblues]

Oops. . . sorry! I did that early this morning in between a bunch of other tasks and didn't pay attention to console output. Its pushed now.

[jarod2d]

Awesome, thanks for the quick response!

One other thing I just realized is that Carthage tries to grab the latest version of a dependency based on tags, so if you include Typhoon using github "appsquickly/Typhoon", the 3.0.2 tag will be used, which doesn't include the shared scheme. It can still be used by explicitly depending on the master branch though, as in github "appsquickly/Typhoon" "master", so no need to rush bumping the version.

Thanks again!

[jasperblues]

OK, just pushed 3.0.3 tag, and also to CocoaPods mater repo.

[jasperblues]

Oh, one more thing to note: While pushing the podspec just now, linting failed as there was a function declared as public in TyphoonFactoryAutoInjectionPostProcessor that was not used publicly. . I fixed that then deleted and recreated the 3.0.3 tag. . . just mentioning in the unlikely event this confuses Carthage.

[jarod2d]

Cool -- I believe Carthage will just pull down whatever the tag is currently pointing to when retrieving dependencies, so it should be okay. Thanks!

[jasperblues]

@jarod2d Did it all work? I'm just adding the 'Carthage compatible" badge in the readme.

[jarod2d]

Yup -- Typhoon has been working great with Carthage.