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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

cvasilak
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Corinne Krych
Thanks for this detailled explantion on the state of dynamic fwk in Swift!

#agree with you, things are changing rapidly. Specially OSS dev around it.
For now github submodule/Xcode project included with Readme instruction will do. With a better cocoapods support we will eventually get rid of gh submodules.

As per Apple dynamic fwk, quoting yout quote: “... stabilizes in a year or two” sounds like a longer run.

Let’s keep a close watch on how it evolves.
++
Corinne
On 22 Jul 2014, at 10:09, Christos Vasilakis <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Luke Holmquist
In reply to this post by cvasilak
very interesting


On Jul 22, 2014, at 4:09 AM, Christos Vasilakis <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Passos-2
In reply to this post by cvasilak
Another awesome explanation. Thanks for the heads-up and teach me a little more about the about the new swift world

-- Passos


On Tue, Jul 22, 2014 at 5:09 AM, Christos Vasilakis <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Summers Pittman
In reply to this post by cvasilak
On 07/22/2014 04:09 AM, Christos Vasilakis 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
Thanks for keeping us up to date. I'm having flashbacks of Eclipse and
ADT...

--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

cvasilak
In reply to this post by cvasilak
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/aerogear-ios-push


On Jul 22, 2014, at 11:09 AM, Christos Vasilakis <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Corinne Krych

On 21 Aug 2014, at 17:43, Christos Vasilakis <[hidden email]> 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/aerogear-ios-push
>
>
> On Jul 22, 2014, at 11:09 AM, Christos Vasilakis <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Corinne Krych
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] https://github.com/aerogear/aerogear-ios-cookbook/tree/swift/libs/AeroGearHttp
On 22 Aug 2014, at 09:40, Corinne Krych <[hidden email]> wrote:

>
> On 21 Aug 2014, at 17:43, Christos Vasilakis <[hidden email]> 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/aerogear-ios-push
>>
>>
>> On Jul 22, 2014, at 11:09 AM, Christos Vasilakis <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Loading...