Swift Port
fjcaetano opened this issue · comments
Hey guys,
First of all, thank you very much for this framework. It saves us so much time I can't thank you enough.
I know this is a delicate subject, there are those that are forward and against this, but do you guys plan on doing a Swift port of the framework?
Hey @fjcaetano -- thanks for the note.
By a port do you mean:
- Translating the current implementation to Swift (not a goal)
- Creating a better interface for Swift usage of the project (A goal for v2.0 #28 )
C
I meant by translating it to Swift. I understand how that may not be interesting considering that there are still lots of projects in Objective-C.
If you're not interesting in translating it into Swift, would you mind if I did? I'd naturally explicit that it is a port and would give due credits for the original code.
Ofcourse -- you're more than welcome to.
I'd love to hear what you see as the benefits of a Swift implementation vs. interface @fjcaetano ?
The biggest issue is actually with Swift-only vs hybrid projects (Swift & ObjC). Swift-only projects compile much faster than bridged ones. In my case, Xcode have reached an unbearable 4~5min compile time in my project. And that's with incremental builds! If I do a clean build, that's over 15min of my day... (yes, it's a large app)
That's the main reason I'm doing an effort to remove (or convert) all Objective-C dependencies from my project, and, as my project was built around DeepLinkKit, and I have no intention of removing it, I thought of translating it into Swift.
@wessmith any thoughts on approach here?
I've never seen an OSS project with two implementations in the same repo, but it would be cool to keep them in-sync.. and using the same tests if possible?
@fjcaetano would you be open to contributing a Swift implementation in this repo & separating out the pods, so there's DeepLinkKit and DeepLinkKit-Swift or something?
Ugh, Apple... you really messed this whole thing up! 😛
As a person developing a large Swift based application that has to bridge across Objective-C, I wouldn't suggest doing this! Our build time could definitely be faster, but the time it takes to build even just this framework pales in comparison to other optimizations that can (and should) be made. We've seen huge gains using this: https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode . We're also really excited to upgrade to Swift 3.0 as there are substantial compile time improvements to be made going from 2.3. Obviously everyone's application is different - just our take on it.
I'd argue for a rewrite in 2.0 or 3.0 that overhauls it to Swift instead of maintaining the same codebase in two languages IF it really came to that.
Including Swift projects in ObjC codebases is arguably worse though -- you get all the downsides of swift (version compatibility etc..) as well as a nice double-digit MB bump in binary to include the bloody standard libs. 😢
Any thing that can help mitigate that?
I believe that in order for a complete rewrite, it would be wiser to have a different repo, instead of a branch, and a separate pod. Of course, improvements and new features would have to be implement on both, which is a downside.
@platedbay I will check that tool as I haven't heard of it and I'll try to improve our build time.
I'm not sure of what you meant by "upgrading to Swift 3.0". Are you talking about DeepLinkKit or your project? If it's DPL, how would you upgrade an ObjC framework? If it's your project, we have already upgraded ours, but we haven't noticed any changes in compile time, partly because Xcode is an idiot. I've seen people saying that the new Beta 2 has significant changes to build time (also by fixing the bug that compiles the whole project even if you change a single file), but we weren't able to test it yet.
Nevertheless, I think that any improvements achieved by using the BuildTimeAnalyzer would be heightened on a Swift-only project. The issue with hybrid projects is bridging, and, this is just a guess, but I don't think any optimization on compiler settings configuration could lower the bridging impact.
@chrismaddern not that I'm aware of! Hence my big IF on that point (I don't think it's worth the rewrite or the change)
@fjcaetano no, not this project, your own. Using the tool above, this post has been really helpful for us: https://medium.com/swift-programming/swift-build-time-optimizations-part-2-37b0a7514cbe#.ro7uq549y
No, this won't address the bridging slowness. My "argument" (a very loose one at that) is to attempt to optimize the places you know you can optimize first (your own Swift code). I'd be curious to hear what % of build time is associated with compiling third party libraries (that require a bridging header) versus everything else.
Also, to get around the long rebuilds, we've found unchecking the "Find Implicit Dependencies" checkbox in the scheme's Build build options works really well! We keep it checked for an initial build (like after doing a clean) and then uncheck it for every subsequent build. Have you tried that yet?
@platedbay wow, unchecking "Find Implicit Dependencies" really helped! Can't our project is compiling so fast now! Do you have any ideas what causes this time increase when that option is available?
Btw, we were already implementing lots of the suggestions in the post. Most of our closures have explicit parameters and return types. In fact, running BuildTimeAnalyzer shows that there are no behemoths eating our time, it's just that we do have a lot of files to compile
Nevertheless, although unchecking "Find Implicit Dependencies" helped, my offer to port the repo to Swift still stands, considering that there are no independent deep link frameworks available exclusively in Swift (as far as I know).