One thing that came out when starting working with cookbook recipes with Erik in ‘swift’
branch is that many recipes may shared the same libs. So it would make sense to share the
lib in a common folder.
We will have a libs folder containing latest version of aerogear-ios-htpp etc… See [1]
++
Corinne
[1]
On 21 Aug 2014, at 17:43, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
> 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.
>
+1
I’ll use the same approach for our swift cookbook demos coming soon
> 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> 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