<div dir="ltr">Thanks for the awesome heads up Christos <div><br></div><div>+1 on b<br></div><div><br></div><div>-- Passos</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 22, 2015 at 3:35 PM, Corinne Krych <span dir="ltr"><<a href="mailto:corinnekrych@gmail.com" target="_blank">corinnekrych@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oki for b, make sense and is easy to understand.<br>
<br>
We go for 2 podspecs on 2 different branches.<br>
In aerogear-io-push on 1.x_dev brnach we keep podspec unchanged.<br>
on master branch (Swift version) podspec get renamed to AeroGear-Push-Swift<br>
<br>
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]<br>
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...<br>
<br>
++<br>
Corinne<br>
[1] <a href="https://github.com/QueryKit/QueryKit/blob/master/QueryKit%2FObjectiveC%2FQKAttribute.swift#L10" target="_blank">https://github.com/QueryKit/QueryKit/blob/master/QueryKit%2FObjectiveC%2FQKAttribute.swift#L10</a><br>
<div class="HOEnZb"><div class="h5"><br>
> On 22 Jan 2015, at 15:40, Christos Vasilakis <<a href="mailto:cvasilak@gmail.com">cvasilak@gmail.com</a>> wrote:<br>
><br>
>><br>
>> On Jan 22, 2015, at 4:21 PM, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>> wrote:<br>
>><br>
>> Wow, thanks for all the details around here<br>
>><br>
>> On Thu, Jan 22, 2015 at 2:01 PM, Christos Vasilakis <<a href="mailto:cvasilak@gmail.com">cvasilak@gmail.com</a>> wrote:<br>
>> Hi team,<br>
>><br>
>> 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:<br>
>><br>
>> a) being a separate project, with a new name plus utilising Swift specific language propers.<br>
>> 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:<br>
>><br>
>> —<br>
>> pod “MyFooBarLibrary/Objc’ (objective-c)<br>
>> or<br>
>> pod “ MyFooBarLibrary/Swift’ (Swift)<br>
>> —<br>
>><br>
>> 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.<br>
>><br>
>> My realisations:<br>
>> 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.<br>
>> b) since ‘Swift first’, both produce frameworks where they can be integrated either in objective-c or swift language projects, no ‘static-library’ targets.<br>
>> c) both are designed for iOS >= 8.0<br>
>><br>
>> ouch - what do they do for iOS7 ?<br>
><br>
> no support for iOS 7, QueryKit and ReactiveCocoa(swift branch) are fairly new and designed to work on iOS 8 and later<br>
><br>
> Note: ReactiveCocoa has a ‘master' branch with support of iOS 7/8 but ‘objective-c’ only.<br>
><br>
><br>
>><br>
>><br>
>><br>
>> 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.<br>
>><br>
>> Regardless and to better understand, I did some testing with our push-sdk:<br>
>><br>
>> a) having a single Swift Project employing both the objective-c code and Swift code<br>
>> b) having a .workspace with a) Obj-c xcodeproj, b) Swift xcodeproj.<br>
>><br>
>> 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…<br>
>><br>
>> 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.<br>
>><br>
>> +1000 :-) When reading, I was actually wondering about these logistics :)<br>
>><br>
>><br>
>> But there is one issue if we go with separate approach: _cocoapods naming_, that is how to properly separate between the two.<br>
>><br>
>> Currently searching for AeroGear-Push in <a href="http://cocoapods.org" target="_blank">cocoapods.org</a> site we get the following:<br>
>><br>
>> <Screenshot 2015-01-22 13.56.36.png><br>
>><br>
>><br>
>> 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:<br>
>><br>
>> —<br>
>> AeroGear-Push<br>
>> AeroGear-Push-Swift<br>
>> —<br>
>><br>
>> 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:<br>
>><br>
>> —<br>
>> import AeroGear-Push-Swift<br>
>> —<br>
>><br>
>> Solving this, there are two approaches:<br>
>><br>
>> a) rename both library podspecs : Objective-C to -> AeroGearPush and Swift to -> AeroGearPushSwift<br>
>> 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]<br>
>><br>
>> +1 on b), using the module_name - nice addon to CocoaPods<br>
>><br>
>><br>
>><br>
>> If we go with (b) the entries will look like this:<br>
>><br>
>> ——<br>
>> Obj-c: (no changes needed)<br>
>><br>
>> Podfile: pod 'AeroGear-Push’<br>
>><br>
>> Class: #import <AeroGearPush/AeroGearPush.h><br>
>><br>
>><br>
>> Swift:<br>
>><br>
>> Podfile: pod 'AeroGear-Push-Swift’<br>
>><br>
>> Class: import “AeroGearPush” (notice _no_ ‘Swift’ postfix is needed cause of the ‘module_name’ override)<br>
>><br>
>> ——<br>
>><br>
>> 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.<br>
>><br>
>> Let me know your comments and suggestions<br>
>><br>
>> Thanks<br>
>> Christos<br>
>><br>
>> [1] <a href="https://github.com/CocoaPods/CocoaPods/issues/3016" target="_blank">https://github.com/CocoaPods/CocoaPods/issues/3016</a><br>
>> [2] <a href="https://github.com/QueryKit/QueryKit" target="_blank">https://github.com/QueryKit/QueryKit</a><br>
>> [3] <a href="https://github.com/ReactiveCocoa/ReactiveCocoa/tree/swift-development" target="_blank">https://github.com/ReactiveCocoa/ReactiveCocoa/tree/swift-development</a><br>
>> [4] <a href="https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69092100" target="_blank">https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69092100</a><br>
>> [5] <a href="https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69073109" target="_blank">https://github.com/CocoaPods/CocoaPods/issues/3016#issuecomment-69073109</a><br>
>> [6] <a href="https://github.com/aerogear/aerogear-ios-push/pull/41" target="_blank">https://github.com/aerogear/aerogear-ios-push/pull/41</a><br>
>> [7] <a href="http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/" target="_blank">http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/</a><br>
>><br>
>> _______________________________________________<br>
>> aerogear-dev mailing list<br>
>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Matthias Wessendorf<br>
>><br>
>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
>> _______________________________________________<br>
>> aerogear-dev mailing list<br>
>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></div></div></blockquote></div><br></div>