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

[Matthias Wessendorf]

Wow, thanks for all the details around here

On Thu, Jan 22, 2015 at 2:01 PM, Christos Vasilakis <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 ?



>
> 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:
>
>
>
> 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150122/89b6bf67/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2015-01-22 13.56.36.png
Type: image/png
Size: 61997 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150122/89b6bf67/attachment-0001.png