[aerogear-dev] Parallel support for a Cocoapods Swift/Obj-c library

Thu Jan 22 09:40:59 EST 2015

> On Jan 22, 2015, at 4:21 PM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
> Wow, thanks for all the details around here
> 
> On Thu, Jan 22, 2015 at 2:01 PM, Christos Vasilakis <cvasilak at gmail.com <mailto:cvasilak at 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 ? 

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 <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 at lists.jboss.org <mailto:aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150122/97f66b4f/attachment-0001.html 