Hi team, a little heads up on an issue that I‘ve been looking the last days, on how to proper support both an Obj-C and a Swift library (in-parallel) on Cocoapods. There was a discussion on the cocoapods issues tracker[1] basically around two ideas: a) being a separate project, with a new name plus utilising Swift specific language propers. b) having one project, utilising cocoapods subspec mechanism to include specific files per spec requested. In a nutshell users will employ in their Podfile something of a form: — pod “MyFooBarLibrary/Objc’ (objective-c) or pod “ MyFooBarLibrary/Swift’ (Swift) — Solution (b) was intrigued and went on to discover more, since I haven’t used before the subspec mechanism and was a good opportunity to learn. The issue mentioned two projects, QueryKit[2] and ReactiveCocoa[3] (their Swift branch) that utilise this mechanism, so I dive in trying to see how it works. My realisations: a) both projects are designed with ‘Swift first’ approach, employing _some_ 'Objective-C code’ to ease the interaction in a mixed project e.g Objective-C code calling the ‘Swift’ library, see [4] where the author describes more details on this. b) since ‘Swift first’, both produce frameworks where they can be integrated either in objective-c or swift language projects, no ‘static-library’ targets. c) both are designed for iOS >= 8.0 To make it short and from my understanding, the projects are _not_ designed around the idea of: take either the Objective-C or the Swift port in you project, but instead employ an Objective-C subspec to “ease” the interaction in a mixed environment, aka Objective-C code calling the Swift library. Regardless and to better understand, I did some testing with our push-sdk: a) having a single Swift Project employing both the objective-c code and Swift code b) having a .workspace with a) Obj-c xcodeproj, b) Swift xcodeproj. In both cases, this mixed approaches, at the end caused issues and wasn’t able to generate a proper solution. Issues around a) cocoapods 'pod install’ steps, b) tests on the library are done with two different dependencies c) various other integration issues… It’s my sense, the most clean way is to go with separate libraries, that is solution (a) described above (a solution proposed also from @orta [5]) This has the added benefit of cleaner 'logistics’ that is: commit history, releases, static/framework library generations etc etc. But there is one issue if we go with separate approach: _cocoapods naming_, that is how to properly separate between the two. Currently searching for AeroGear-Push in cocoapods.org site we get the following: In my cocoapods PR [6] I went with the approach to name the ‘Swift’ equivalent library as 'AeroGear-Push-Swift’, so the same searching above will reveal: — AeroGear-Push AeroGear-Push-Swift — Some of you have already noticed, that the ‘hyphen’ character as a podspec name doesn’t work well with a Swift Project, cause the podspec name is used as the name of the final #import statement the user does. That is the following import statement doesn’t work: — import AeroGear-Push-Swift — Solving this, there are two approaches: a) rename both library podspecs : Objective-C to -> AeroGearPush and Swift to -> AeroGearPushSwift b) continue the same naming, but use the new ‘module_name’ podspec directive in the Swift project(added in cocoapods [6]) to specify the final module name the user will use on the import. That is the approach I have taken in my PR[6] If we go with (b) the entries will look like this: —— Obj-c: (no changes needed) Podfile: pod 'AeroGear-Push’ Class: #import <AeroGearPush/AeroGearPush.h> Swift: Podfile: pod 'AeroGear-Push-Swift’ Class: import “AeroGearPush” (notice _no_ ‘Swift’ postfix is needed cause of the ‘module_name’ override) —— I am fine with both albeit more towards (b) mostly not to break existing ‘pod installs’ the users may use and since support with the ‘module_name’ directive is provided from cocoapods. Current PR[6] goes with this approach. Let me know your comments and suggestions Thanks Christos [1] https://github.com/CocoaPods/CocoaPods/issues/3016 [2] https://github.com/QueryKit/QueryKit [3] https://github.com/ReactiveCocoa/ReactiveCocoa/tree/swift-development [4] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69092100 [5] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69073109 [6] https://github.com/aerogear/aerogear-ios-push/pull/41 [7] http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/ _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi team, a little heads up on an issue that I‘ve been looking the last days, on how to proper support both an Obj-C and a Swift library (in-parallel) on Cocoapods. There was a discussion on the cocoapods issues tracker[1] basically around two ideas: a) being a separate project, with a new name plus utilising Swift specific language propers. b) having one project, utilising cocoapods subspec mechanism to include specific files per spec requested. In a nutshell users will employ in their Podfile something of a form: — pod “MyFooBarLibrary/Objc’ (objective-c) or pod “ MyFooBarLibrary/Swift’ (Swift) — Solution (b) was intrigued and went on to discover more, since I haven’t used before the subspec mechanism and was a good opportunity to learn. The issue mentioned two projects, QueryKit[2] and ReactiveCocoa[3] (their Swift branch) that utilise this mechanism, so I dive in trying to see how it works. My realisations: a) both projects are designed with ‘Swift first’ approach, employing _some_ 'Objective-C code’ to ease the interaction in a mixed project e.g Objective-C code calling the ‘Swift’ library, see [4] where the author describes more details on this. b) since ‘Swift first’, both produce frameworks where they can be integrated either in objective-c or swift language projects, no ‘static-library’ targets. c) both are designed for iOS >= 8.0

To make it short and from my understanding, the projects are _not_ designed around the idea of: take either the Objective-C or the Swift port in you project, but instead employ an Objective-C subspec to “ease” the interaction in a mixed environment, aka Objective-C code calling the Swift library. Regardless and to better understand, I did some testing with our push-sdk: a) having a single Swift Project employing both the objective-c code and Swift code b) having a .workspace with a) Obj-c xcodeproj, b) Swift xcodeproj. In both cases, this mixed approaches, at the end caused issues and wasn’t able to generate a proper solution. Issues around a) cocoapods 'pod install’ steps, b) tests on the library are done with two different dependencies c) various other integration issues… It’s my sense, the most clean way is to go with separate libraries, that is solution (a) described above (a solution proposed also from @orta [5]) This has the added benefit of cleaner 'logistics’ that is: commit history, releases, static/framework library generations etc etc.

But there is one issue if we go with separate approach: _cocoapods naming_, that is how to properly separate between the two. Currently searching for AeroGear-Push in cocoapods.org site we get the following: In my cocoapods PR [6] I went with the approach to name the ‘Swift’ equivalent library as 'AeroGear-Push-Swift’, so the same searching above will reveal: — AeroGear-Push AeroGear-Push-Swift — Some of you have already noticed, that the ‘hyphen’ character as a podspec name doesn’t work well with a Swift Project, cause the podspec name is used as the name of the final #import statement the user does. That is the following import statement doesn’t work: — import AeroGear-Push-Swift — Solving this, there are two approaches: a) rename both library podspecs : Objective-C to -> AeroGearPush and Swift to -> AeroGearPushSwift b) continue the same naming, but use the new ‘module_name’ podspec directive in the Swift project(added in cocoapods [6]) to specify the final module name the user will use on the import. That is the approach I have taken in my PR[6]

If we go with (b) the entries will look like this: —— Obj-c: (no changes needed) Podfile: pod 'AeroGear-Push’ Class: #import <AeroGearPush/AeroGearPush.h> Swift: Podfile: pod 'AeroGear-Push-Swift’ Class: import “AeroGearPush” (notice _no_ ‘Swift’ postfix is needed cause of the ‘module_name’ override) —— I am fine with both albeit more towards (b) mostly not to break existing ‘pod installs’ the users may use and since support with the ‘module_name’ directive is provided from cocoapods. Current PR[6] goes with this approach. Let me know your comments and suggestions Thanks Christos [1] https://github.com/CocoaPods/CocoaPods/issues/3016 [2] https://github.com/QueryKit/QueryKit [3] https://github.com/ReactiveCocoa/ReactiveCocoa/tree/swift-development [4] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69092100 [5] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69073109 [6] https://github.com/aerogear/aerogear-ios-push/pull/41 [7] http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/ _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jan 22, 2015, at 4:21 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Wow, thanks for all the details around here On Thu, Jan 22, 2015 at 2:01 PM, Christos Vasilakis <cvasilak(a)gmail.com <mailto:cvasilak@gmail.com>> wrote: Hi team, a little heads up on an issue that I‘ve been looking the last days, on how to proper support both an Obj-C and a Swift library (in-parallel) on Cocoapods. There was a discussion on the cocoapods issues tracker[1] basically around two ideas: a) being a separate project, with a new name plus utilising Swift specific language propers. b) having one project, utilising cocoapods subspec mechanism to include specific files per spec requested. In a nutshell users will employ in their Podfile something of a form: — pod “MyFooBarLibrary/Objc’ (objective-c) or pod “ MyFooBarLibrary/Swift’ (Swift) — Solution (b) was intrigued and went on to discover more, since I haven’t used before the subspec mechanism and was a good opportunity to learn. The issue mentioned two projects, QueryKit[2] and ReactiveCocoa[3] (their Swift branch) that utilise this mechanism, so I dive in trying to see how it works. My realisations: a) both projects are designed with ‘Swift first’ approach, employing _some_ 'Objective-C code’ to ease the interaction in a mixed project e.g Objective-C code calling the ‘Swift’ library, see [4] where the author describes more details on this. b) since ‘Swift first’, both produce frameworks where they can be integrated either in objective-c or swift language projects, no ‘static-library’ targets. c) both are designed for iOS >= 8.0 ouch - what do they do for iOS7 ?

To make it short and from my understanding, the projects are _not_ designed around the idea of: take either the Objective-C or the Swift port in you project, but instead employ an Objective-C subspec to “ease” the interaction in a mixed environment, aka Objective-C code calling the Swift library. Regardless and to better understand, I did some testing with our push-sdk: a) having a single Swift Project employing both the objective-c code and Swift code b) having a .workspace with a) Obj-c xcodeproj, b) Swift xcodeproj. In both cases, this mixed approaches, at the end caused issues and wasn’t able to generate a proper solution. Issues around a) cocoapods 'pod install’ steps, b) tests on the library are done with two different dependencies c) various other integration issues… It’s my sense, the most clean way is to go with separate libraries, that is solution (a) described above (a solution proposed also from @orta [5]) This has the added benefit of cleaner 'logistics’ that is: commit history, releases, static/framework library generations etc etc. +1000 :-) When reading, I was actually wondering about these logistics :) But there is one issue if we go with separate approach: _cocoapods naming_, that is how to properly separate between the two. Currently searching for AeroGear-Push in cocoapods.org <http://cocoapods.org/> site we get the following: <Screenshot 2015-01-22 13.56.36.png> In my cocoapods PR [6] I went with the approach to name the ‘Swift’ equivalent library as 'AeroGear-Push-Swift’, so the same searching above will reveal: — AeroGear-Push AeroGear-Push-Swift — Some of you have already noticed, that the ‘hyphen’ character as a podspec name doesn’t work well with a Swift Project, cause the podspec name is used as the name of the final #import statement the user does. That is the following import statement doesn’t work: — import AeroGear-Push-Swift — Solving this, there are two approaches: a) rename both library podspecs : Objective-C to -> AeroGearPush and Swift to -> AeroGearPushSwift b) continue the same naming, but use the new ‘module_name’ podspec directive in the Swift project(added in cocoapods [6]) to specify the final module name the user will use on the import. That is the approach I have taken in my PR[6] +1 on b), using the module_name - nice addon to CocoaPods If we go with (b) the entries will look like this: —— Obj-c: (no changes needed) Podfile: pod 'AeroGear-Push’ Class: #import <AeroGearPush/AeroGearPush.h> Swift: Podfile: pod 'AeroGear-Push-Swift’ Class: import “AeroGearPush” (notice _no_ ‘Swift’ postfix is needed cause of the ‘module_name’ override) —— I am fine with both albeit more towards (b) mostly not to break existing ‘pod installs’ the users may use and since support with the ‘module_name’ directive is provided from cocoapods. Current PR[6] goes with this approach. Let me know your comments and suggestions Thanks Christos [1] https://github.com/CocoaPods/CocoaPods/issues/3016 <https://github.com/CocoaPods/CocoaPods/issues/3016> [2] https://github.com/QueryKit/QueryKit <https://github.com/QueryKit/QueryKit> [3] https://github.com/ReactiveCocoa/ReactiveCocoa/tree/swift-development <https://github.com/ReactiveCocoa/ReactiveCocoa/tree/swift-development> [4] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69092100 <https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69092100> [5] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69073109 <https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69073109> [6] https://github.com/aerogear/aerogear-ios-push/pull/41 <https://github.com/aerogear/aerogear-ios-push/pull/41> [7] http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/ <http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/> _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/aerogear-dev <https://lists.jboss.org/mailman/listinfo/aerogear-dev> -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ <http://matthiaswessendorf.wordpress.com/> sessions: http://www.slideshare.net/mwessendorf <http://www.slideshare.net/mwessendorf> twitter: http://twitter.com/mwessendorf <http://twitter.com/mwessendorf>_______________________________________... aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Oki for b, make sense and is easy to understand. We go for 2 podspecs on 2 different branches. In aerogear-io-push on 1.x_dev brnach we keep podspec unchanged. on master branch (Swift version) podspec get renamed to AeroGear-Push-Swift On side note, interesting use case of QueryKit Swift-first lib, bridging from Swift to obj-c. How you turn strongly typed designed library to dynamic lg. Generics -> AnyObject like shown in [1] it could be the case for ex if you want ot use ou jsonsz lib in obj-c but i’d simply go: use obj-c fwk like mantle... ++ Corinne [1] https://github.com/QueryKit/QueryKit/blob/master/QueryKit%2FObjectiveC%2F... > On 22 Jan 2015, at 15:40, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: > >> >> On Jan 22, 2015, at 4:21 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >> Wow, thanks for all the details around here >> >> On Thu, Jan 22, 2015 at 2:01 PM, Christos Vasilakis <cvasilak(a)gmail.com&gt; wrote: >> Hi team, >> >> a little heads up on an issue that I‘ve been looking the last days, on how to proper support both an Obj-C and a Swift library (in-parallel) on Cocoapods. There was a discussion on the cocoapods issues tracker[1] basically around two ideas: >> >> a) being a separate project, with a new name plus utilising Swift specific language propers. >> b) having one project, utilising cocoapods subspec mechanism to include specific files per spec requested. In a nutshell users will employ in their Podfile something of a form: >> >> — >> pod “MyFooBarLibrary/Objc’ (objective-c) >> or >> pod “ MyFooBarLibrary/Swift’ (Swift) >> — >> >> Solution (b) was intrigued and went on to discover more, since I haven’t used before the subspec mechanism and was a good opportunity to learn. The issue mentioned two projects, QueryKit[2] and ReactiveCocoa[3] (their Swift branch) that utilise this mechanism, so I dive in trying to see how it works. >> >> My realisations: >> a) both projects are designed with ‘Swift first’ approach, employing _some_ 'Objective-C code’ to ease the interaction in a mixed project e.g Objective-C code calling the ‘Swift’ library, see [4] where the author describes more details on this. >> b) since ‘Swift first’, both produce frameworks where they can be integrated either in objective-c or swift language projects, no ‘static-library’ targets. >> c) both are designed for iOS >= 8.0 >> >> ouch - what do they do for iOS7 ? > > no support for iOS 7, QueryKit and ReactiveCocoa(swift branch) are fairly new and designed to work on iOS 8 and later > > Note: ReactiveCocoa has a ‘master' branch with support of iOS 7/8 but ‘objective-c’ only. > > >> >> >> >> To make it short and from my understanding, the projects are _not_ designed around the idea of: take either the Objective-C or the Swift port in you project, but instead employ an Objective-C subspec to “ease” the interaction in a mixed environment, aka Objective-C code calling the Swift library. >> >> Regardless and to better understand, I did some testing with our push-sdk: >> >> a) having a single Swift Project employing both the objective-c code and Swift code >> b) having a .workspace with a) Obj-c xcodeproj, b) Swift xcodeproj. >> >> In both cases, this mixed approaches, at the end caused issues and wasn’t able to generate a proper solution. Issues around a) cocoapods 'pod install’ steps, b) tests on the library are done with two different dependencies c) various other integration issues… >> >> It’s my sense, the most clean way is to go with separate libraries, that is solution (a) described above (a solution proposed also from @orta [5]) This has the added benefit of cleaner 'logistics’ that is: commit history, releases, static/framework library generations etc etc. >> >> +1000 :-) When reading, I was actually wondering about these logistics :) >> >> >> But there is one issue if we go with separate approach: _cocoapods naming_, that is how to properly separate between the two. >> >> Currently searching for AeroGear-Push in cocoapods.org site we get the following: >> >> <Screenshot 2015-01-22 13.56.36.png> >> >> >> In my cocoapods PR [6] I went with the approach to name the ‘Swift’ equivalent library as 'AeroGear-Push-Swift’, so the same searching above will reveal: >> >> — >> AeroGear-Push >> AeroGear-Push-Swift >> — >> >> Some of you have already noticed, that the ‘hyphen’ character as a podspec name doesn’t work well with a Swift Project, cause the podspec name is used as the name of the final #import statement the user does. That is the following import statement doesn’t work: >> >> — >> import AeroGear-Push-Swift >> — >> >> Solving this, there are two approaches: >> >> a) rename both library podspecs : Objective-C to -> AeroGearPush and Swift to -> AeroGearPushSwift >> b) continue the same naming, but use the new ‘module_name’ podspec directive in the Swift project(added in cocoapods [6]) to specify the final module name the user will use on the import. That is the approach I have taken in my PR[6] >> >> +1 on b), using the module_name - nice addon to CocoaPods >> >> >> >> If we go with (b) the entries will look like this: >> >> —— >> Obj-c: (no changes needed) >> >> Podfile: pod 'AeroGear-Push’ >> >> Class: #import <AeroGearPush/AeroGearPush.h> >> >> >> Swift: >> >> Podfile: pod 'AeroGear-Push-Swift’ >> >> Class: import “AeroGearPush” (notice _no_ ‘Swift’ postfix is needed cause of the ‘module_name’ override) >> >> —— >> >> I am fine with both albeit more towards (b) mostly not to break existing ‘pod installs’ the users may use and since support with the ‘module_name’ directive is provided from cocoapods. Current PR[6] goes with this approach. >> >> Let me know your comments and suggestions >> >> Thanks >> Christos >> >> [1] https://github.com/CocoaPods/CocoaPods/issues/3016 >> [2] https://github.com/QueryKit/QueryKit >> [3] https://github.com/ReactiveCocoa/ReactiveCocoa/tree/swift-development >> [4] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69092100 >> [5] https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69073109 >> [6] https://github.com/aerogear/aerogear-ios-push/pull/41 >> [7] http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/ >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev