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