Swift With a Hundred Engineers
Tuomas Artman (via Quinn):
Basically both of these problems; the architectural problems in the current application and the full redesign on the UX, lead us to the decision that Ben told us yesterday (in his talk) we shouldn’t do - which is just; change everything. Start from scratch. Not try to look at the architecture and fix it going forward, but start from scratch.
[…]
So we call it “Riblets”, that means; Router, Interaction and Builder and possibly a Presenter and a View. Those are the core components of one piece of the application. It’s sort of a take on VIPER. We looked at MVVM, we looked at VIPER, we looked at MVC and we came up with our own innovation on top of VIPER. The big thing that we wanted to do is obviously compartmentalize everything and make everything testable.
[…]
All of this created a lot of code. We had protocols between everything. We had components that compromised a Riblit, that compromised five different files. So in our codebase we have over five thousand files and over half a million lines of Swift code.
[…]
Our crash-free rate target is 99.99% and we are very close. I’ve never seen anything like this. First launch of an application and it’s almost crash free.
[…]
We named everything the same, everything worked in the same manner and Swift basically was the language that enabled us to do that. If we had done it in Objective-C, I don’t think we could have come to such a close relationship with the Android engineers or even have the architecture be the same across both sides.
[…]
The first thing that we found out is that, testing is pretty hard. Swift is a static language and as such you can’t really rely on your mocking frameworks that you had used in Objective-C.
[…]
On the other bad side, tooling issues.
[…]
So we built all these frameworks and then we have a post-build step that takes all the symbols out of these frameworks and links them together in your static binary and that’s how we get away with the startup speed that we had.
[…]
But if you add a user-defined custom flag; SWIFT_WHOLE_MODULE_OPTIMIZATION and set it to yes, as well as set the optimization level to none. It will do whole module optimization without optimizing. And it’ll be super fast.
