[aerogear-dev] Swift - Frameworks/Static libs and Cocoapods

[Lucas Holmquist]

very interesting


On Jul 22, 2014, at 4:09 AM, Christos Vasilakis <cvasilak at gmail.com> wrote:

> Hi all,
> 
> want to give a heads up on the current status of Swift frameworks/static libs generation and cocoapods support.  This is based on the current state of affairs, as in Xcode beta 4 (released yesterday).
> 
> Note: "Since rapid developments are taking place, will update this thread as more information becomes available and with any breaking changes"
> 
> First, let me start by making three observations:
> 
> a) quoting Apple release notes[1], "Xcode does not support building static libraries that include Swift code”. You can notice that in Xcode 6 when choosing “Cocoa Touch Static Library” there is no option to select “Swift” as the preferred language.
> 
> b) new in Xcode 6 is the generation of ‘dynamic’ frameworks for library targets. The reason for ‘dynamic’ linking, as explained by apple in [2], is to enable the new functionality in iOS 8 called ‘extensions’. Per apple quote "Frameworks work perfectly with extensions, sharing logic that can be used by both the main application, and the bundled extensions”
> 
> c) Dynamic framework for a swift library (the only option offered by Xcode) , in the current state requires the source code of the library to be build together with the app that uses it. This is due to the binary interface, which has not being finalised yet.  Quoting apple blog [3] ("Binary Compatibility and Frameworks” section):
> 
> —
> "While your app’s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together.
> 
> This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift — especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.”
> —
> 
> What does all that gives us?
> In plain form, "Distribution of the push-sdk (swift port) should be done in source form with polished documentation on how the user can add it to their own project.”
> 
> Already, looking at the various swift-libs currently in existence[4], that is the current approach, a well-written README.md on how the user can add the library dependency into their own projects. For example, something like the section “How to Install Library”  found here [5] 
> 
> As for cocoapods, currently no support is provided for swift projects. There is an on-going discussion on the issues list found here [6] on how to effectively support ‘dynamic framework’ for swift projects, and still keep backwards compatibility, but things are not yet finalised.
> 
> Let me know your thoughts / comments.
> 
> Thanks,
> Christos
> 
> [1] http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_4_o2p8fz/xcode_6_beta_4_release_notes.pdf
> [2] https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW14
> [3] https://developer.apple.com/swift/blog/?id=2
> [4] http://www.swifttoolbox.io
> [5] https://github.com/Quick/Quick
> [6] https://github.com/CocoaPods/CocoaPods/issues/2272
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev