[aerogear-dev] Swift - Frameworks/Static libs and Cocoapods
daniel at passos.me
Mon Aug 4 19:18:31 EDT 2014
Another awesome explanation. Thanks for the heads-up and teach me a little
more about the about the new swift world
On Tue, Jul 22, 2014 at 5:09 AM, Christos Vasilakis <cvasilak at gmail.com>
> 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, "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 , 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 
> ("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, 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 
> As for cocoapods, currently no support is provided for swift projects.
> There is an on-going discussion on the issues list found here  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.
>  https://developer.apple.com/swift/blog/?id=2
>  http://www.swifttoolbox.io
>  https://github.com/Quick/Quick
>  https://github.com/CocoaPods/CocoaPods/issues/2272
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aerogear-dev