How and why Lyft rewrote its app in Swift | Hacker News Reader

How and why Lyft rewrote its app in Swift

fastcompany.com

42 pointstechnologizer21 comments

My latest project is written in Swift. It was honestly a no-brainer to switch.

ObjC seems a bit cobbled together, and a lot of things look a bit more verbose that they need to be. And there's some type safety issues lurking in various places, too. And then there's the whole having .h and .m files, an inconvenient way to organise things in this day and age. Sure, I was used to it from c++, but that isn't the fastest language to code in, either.

One needs to get over the trepidation of a new language. I was talking to another CTO about this, a guy who's been coding for 30 years. Once you understand the domain and you can solve the problem, language is not a big deal. Of course you need a language that contains the abstractions of the solution, but generally any OO language will be able to do it. What's left then is whether the language lends itself to coding tools, terseness, library availability, and the level of granularity you need.

As a language that's focused on building nice apps, Swift strikes a good balance. If I'm going to be doing UI stuff, I can assume I won't need the fine-tuning that something like c++ gives me. I generally don't want to be bothered by the memory management, and I don't expect performance to be a big deal (people can wait dozens of ms for something, they won't notice). If anything takes a long time, I can use GCD just like in ObjC. I care that things are easy to find in the code, and there aren't many contortions (eg pull out something as an id and cast it. Concat a string by using a ludicrously long function with an unobvious name). There's library compatibility, so I can pretty quickly glue together an app from the same pieces as ObjC, with less glue.

> ObjC seems a bit cobbled together

Of course it is, the original ObjC stapled smalltalk features to C with a preprocessor (Cox's original project was called OOPC "Object-Oriented Pre-Compiler"). It later grew a genuine frontend and its own runtime, but the core idea remained: a thin dynamically typed language layer over raw C.

I've been able to convert a few key modules over to Swift without any major issues. I can see that the 2-3 week estimate for getting comfortable in it versus Objective-C is probably about right.

One more reason: to get featured inside the App Store.

Apple loves to feature apps showcasing their latest technologies.

They show such apps as a good example for other developers to follow.

> Over the years, the original version of Lyft had ballooned to 75,000 lines of code. By the time the company was done recreating it in Swift, they had something that performed the same tasks in less than a third of that.

I recently read a tutorial on how to make an Uber app on Swift that was fairly short (although not complete yet) [0]. 75k lines of code seems like a lot, even if it's down to a third of that. From personal experience, I know that code grows very fast when you start adding features but I can't point to any one reason why it should have to.

[0] http://shrikar.com/build-your-own-uber-app-in-swift/

Since when is 75K SLOC considered large? Around 100K is pretty standard for a medium-sized app, let alone a billion dollar company.

Meanwhile, on the cover of Fast Company: http://www.fastcompany.com/3050250/what-makes-uber-run

Lyft just can't beat Uber at PR.

>Lyft just can't beat Uber at PR.

I'd say Uber has far superior execution and product distribution, but worse PR/Perception.

They have an order of magnitude less money.

Yes, I see your point. If Lyft wasn't the second most popular story today they would be better off.

I guess having a developer brain makes you think that being overshadowed by your competition is bad. In fact, the real problem is when you get zero press.

Has anyone analyzed hacker news datasets for vote/comment manipulation? I am specifically referring to uber. It seems HN will go days without any uber-related content, but every now and then, 15-20% of the articles on the front couple pages will be uber related, with comment sections filled with aggressively pro-uber rhetoric. I highly doubt it's organic.

HN has a very manipulable hive mind. It doesn't take much to convince the audience here of an agenda. Uber certainly has the resources to operate a "grassroots propaganda" campaign. I'll bet it's a central tenant of their PR strategy. I'll also bet that a subset of that strategy is convincing the tech community to agree with the uber agenda. Two plus two equals four and uber is definitely manipulating HN.

Someone should crunch the numbers. I doubt uber would be the only anomaly to show up in an analysis, either.

I began to port a small project to Swift and at a certain point Xcode crashed because of a copy-paste on a swift file. Postponed it until Xcode 7...

Xcode 7 GM is available, that close enough?

TL;DR: to gain maintainability at a cost to performance.

No where in the article does it mention that they had performance issues. Some developers write in JavaScript and it's fast enough. Swift performance is more than acceptable for most apps.

Sure, but it is slower and more maintainable. So "gain maintainability at a cost to performance" is correct. Which is generally what you want in most domains, but in areas where performance is more critical than maintainability you would rather use C still.

I don't know how Javascript plays into that - I assume Javascript is slower than Swift, but I don't think it is more maintainable.

We're not choosing religions here. Language is a technical decision (with business impact due to hiring availability). You choose the language that fits your goals best, not which one has a better saint.

"You choose the language that fits your goals best."

That's often an abused statement with no actual significance. If you are writing native iOS apps, you basically get two, maybe three, choices.

There is always a group of developers who will rush ahead and there's a group that will lag behind. It has more to do with human nature than the technical features of a language. That's why a year ago I started collecting a bunch of Swift resources in one place. Ive got almost 1500 urls.

http://www.h4labs.com/dev/ios/swift.html

Most blogs/articles on iOS development are now in Swift. If you are learning iOS 9, for example, it's easier to go with Swift. Swift is now the path of least resistance.

I seriously doubt most apps have more than a few performance critical areas that need to be in C -- and Swift in no way prevents you from jumping out to an Objective-C wrapper class for these exceptions.

TL;DRs are supposed to be a summary of the article, not of your own opinions.

TL;DR: we had nothing better to do than to rewrite our entire app in Swift while the competition continues to destroy us.

They have a third of the code after the rewrite:

"Over the years, the original version of Lyft had ballooned to 75,000 lines of code. By the time the company was done recreating it in Swift, they had something that performed the same tasks in less than a third of that."

I'd say that it's a bit unfair to rip on a couple software developers as distracting the entire company.

Reply on news.ycombinator.com