
How and why Lyft rewrote its app in Swift - technologizer
http://www.fastcompany.com/3050266/tech-forecast/lyft-goes-swift-how-and-why-it-rewrote-its-app-from-scratch-in-apples-new-lang
======
lordnacho
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.

~~~
masklinn
> 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.

------
jafitc
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.

------
bko
> 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/](http://shrikar.com/build-your-own-uber-app-in-swift/)

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

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

Lyft just can't beat Uber at PR.

~~~
dylanjermiah
>Lyft just can't beat Uber at PR.

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

------
chatmasta
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.

------
epx
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...

~~~
wlesieutre
Xcode 7 GM is available, that close enough?

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

~~~
melling
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.

~~~
RyanZAG
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.

~~~
melling
"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](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.

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

~~~
melling
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.

