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

Hi all, just some heads up on this to be a little more clear on how we approach the framework issues mentioned in this thread with our demos/quickstarts written in Swift. Because of the issue mentioned in the mail, we opted for our demos that use ‘Swift’ frameworks (as in the case with our push-sdk swift port[1 ), to have the library embedded in [2], instead of using the ‘github submodule’ process. At least for demos, we believe it’s better for the user experience to just fire it and run the project instead of manual fetching the dependent library with git.

Eventually, when the framework issues is resolved by Swift, the source code of the folder containing the library will be removed and replaced with a binary framework build. Just to clear this up in case you come wondering what is this extra 'aerogear-ios-push’ folder doing inside the project ;) if you have any question/comments let us know Thanks! - Christos [1] https://github.com/aerogear/aerogear-ios-push/tree/swift [2] https://github.com/cvasilak/aerogear-push-helloworld/tree/swift/ios-swift... On Jul 22, 2014, at 11:09 AM, Christos Vasilakis <cvasilak(a)gmail.com&gt; 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... > [2] https://developer.apple.com/library/prerelease/ios/documentation/Develope... > [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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev