[MUSIC]
My name's Keith Smiley and I am an iOS Engineer at Lyft.
I work on our iOS Platform Team so I work on a lot of the infrastructure and
architecture of the iOS app.
[MUSIC]
We decided to rewrite the Lyft app in Swift for a lot of reasons.
One of which was that as a team we were extremely excited about the future of
iOS development with Swift, and another big portion was
the code base that we were working in that existed from the beginning at Lyft
wasn't the best as we continued scaling the team.
It worked really well to get Lyft off the ground and
to where it was when I joined, but it became immediately apparent as our
team grew from three to ten people, that it wasn't going to be productive for
us to work day to day in the code base.
So that was a huge portion of it.
I think making the decision to do a Swift re-write is
definitely a big thing that you really have to consider a lot of
angles because it can be extremely risky for the company,
if your app is already 100,000 lines of code in Objective C or something,
just deciding to rewrite it isn't the easiest thing to do.
So, we were extremely lucky to get off the ground and
be successful with the rewrite whereas a lot of times when you hear about
all out rewrites you hear about them in more of a negative light and
I think it's just extremely lucky that ours worked out the way that it did.
I don't think there were too many specific features that they gave
us a lot of trouble.
Whenever we had to interrupt with some third party Objective-C library,
we ran into some issues there in the early days.
But we weren't really using the old implementation
as kind of a reference implementation for the rewrite.
So, we kind of leaned on our QA team a lot to be able to tell us how something
should work as opposed to just looking at the old code and
trying to reason about it, which I think helps a lot.
So we were kind of, instead of looking at how it was and
just redoing it in the same way,
we were totally rethinking how it was written the first time and how we could
rewrite it now to be better since we knew more about the problems today.
The benefits of rewriting our app in Swift were pretty massive.
Our app is 100% Swift, we have no first party Objective-C code.
Although of course we do rely on a lot of third party libraries
that are still written in Objective-C.
Some of the issues that we've ran into with the third party code has mostly
been because the third party libraries haven't been annotated for
whether a type is optional or not, when it's being imported into Swift.
And, because of that, if we guessed wrong about whether it was optional or
not the app could crash at run time.
So instead, when we run into those cases we kind of
treat everything as optional and just have to deal with that in Swift, but
at least we know we're not going to crash.
I think that the community is doing a great job of convincing the objective
seed developers to add null-ability limitations to their libraries.
Mainly because Swift has become so pervasive that people keep asking for it
on all of these popular libraries that were originally written in Objective-C.
[MUSIC]
I pretty rarely find myself reading and writing Objective-C,
definitely reading it more than writing it.
Of course lots of stuff like historical stack overflow questions and
stuff like that is still all written in Objective-C.
And like I said, we do depend on a lot of third party libraries
that are written in Objective-C and
often we need to dive into them to try to find the source of a bug.
I don't really miss anything Objective-C.
I didn't absolutely hate it before Swift came around, but
once you really work on an all Swift app like ours where you can use
all the Swift features as soon as they're released,
without having to worry about interop issues it's really freeing.
I think it's going to be a long time before Swift entirely replaces
Objective-C, mainly because there's so much Objective-C code out there already.
Not only third party apps, but also all of the first party, like the iOS STK
itself, or all of iOS presumably is written in Objective-C as well.
So I think that even if the third party developers all switched to only using
Swift, Apple's going to have to continue maintaining Objective-C for a long time,
just for their own use.
[MUSIC]
When we're hiring a developer for the Lyft iOS team I think one of the most
important things is your collaboration skills, whether or
not we think that we'd be able to work with you day to day on a feature.
Another big thing that I don't think always comes up
in the iOS community is a general acumen for software engineering.
Not particularly,
how do you write different sorting algorithms from scratch or something,
but at least being able to think about high level architecture of problems.
So that when you go to implement a new feature you can identify places that
need to be improved, or rewritten entirely depending on the case.
When we're hiring developers to work on our entirely Swift
app we kind of expect them to have some background in Objective-C
just because that's been the norm up to now.
But that's not a huge requirement for us anymore.
As long as you have a very good understanding of the iOS STK in general
and then some of the gotchus around the platform such as memory management which
was more painfully obvious in Objective-C than it is in Swift,
then you totally have the skills to be productive on our team.
I think for developers who are starting the iOS community having only
really written Swift, it is still important to at least
spend some time knowing that you can read Objective-C here if you need to,
become at least familiar with the syntax.
And once you've learned Swift and the iOS STK in general,
it should be pretty easy to pick up within some amount of time.
And hopefully you can find a position where you don't have to write
it full time.
But with many companies now, that's not entirely
the case because lots of companies have some Swift and some Objective-C.
So it might still be useful to be able to write it.
[MUSIC]