A complete rewrite of a large project is risky anyway. Doing so in a language in which literally no other project of that size exists yet strikes me as insane.

I love Swift. But I've been adopting it in bits and pieces over the years. It's not just that the language has changed significantly, you also have to get used to the idioms. E.g. my early Swift code often featured Pyramid of Doom patterns, and both language innovations and better familiarity with the idioms have helped a lot with this.

One thing I was surprised not to see was a mention of their Swift 2 to 3 migration, which was terrible in my experience working on apps that were nowhere near the complexity of Uber.

Apple should have never pushed Swift as hard as it did at the time. Between the constant API changes and issues like requiring dynamic framework linkage and copying the whole runtime into every app, it was absolutely not production ready.

It was a lot of work, but we had enough staff to make it someones job for half a year or a quarter, depending on how bad the migration is. With big codebases there are other issues that pop up with every new major Xcode release that we have to migrate, mitigate or fix. For example we are still at xcode 11 because of various bugs in xcode 12. Doing the migration was annoying, but it was not much compared to all the other issues, because the fixes were tractable.

That's why I call idioms idiots. If you have to learn idioms, it's an idiotic thing.

There is no language where full expression is possible without use of idioms that don't have direct translations in every other language.

What do you propose as an alternative?

As someone who was there, a rewrite was necessary, and with hindsight we should of done it with objective-c. The original obj-c app was built with under 10 iOS engineers in mind, and now Uber had 100s of mobile engineers work on one app in some form or another.

We didn't do a simple build scalability test until we were well into the project. If we did it would of revealed swift's build problems to us. Our swift experience is what slowed down our kotlin migration significantly. Today Uber android is still a majority Java app.

Even very recently the experience of working in swift compared to the old obj-c code base isn't as good. To this day there are debugger issues, xcode responsiveness issues and a slower build time.

Hiring on the other hand would be harder now, because it's getting hard to find people who know Objective-C and it's surface ugliness scares new people away. Swift is a decent language if you don't have to have a very large code base, so most people rightfully so don't have that much Objective-C, and if you were to work in Obj-C, you might as well go work at Facebook then.

I was not part of the initial analysis team so cannot really comment if objc was more suitable as it would require to look at objc at that time and do tests etc but I suspect we would have had a more smoother experience. Though the the code at the time was bad and indeed something needed to happen to ensure future scalability of the teams and product/code, but I think there were more sane paths we could have taken. It would have cost the company more time/money and at that time the company was battling Grab, GoJek, didi, Lyft etc so we did not have time to lose. Lots of factors to take in to consideration. No real easy answer

I havent dabbled in mobile developer platform tooling for the last few years now so I cannot comment on the iOS side, all i remember is that back then it was a shitshow :) Mobile is still playing catch up to how backend infra and tooling operates, I suspect its better but probably still got a long way to go.

We could of made it work. I think the one big benefit of the rewrite was how the architecture and nullable types basically gave us one more 9 of crash free rate, which we saw after the release with swift. With ObjC I could forsee how it would of crashed a bit more, because nullables aren't hard enforced in ObjC, but I could also see how we could of stepped around that by strong guarantees in the model & network service generation code.

If by OP you mean me, then let’s be clear. I didn’t think the rewrite was necessary.

The Mac CI situation has gotten much worse this year, but Swift has gotten much better. Writing a large app in Swift is still a major undertaking, but there are people doing it these days.