Read on Twitter
Android rewrite was fine. We moved mountains too, but not out of any particular apocalyptic urgency that is "reliance on Apple dev tooling" https://twitter.com/tomwhoscontrary/status/1337013383539945473
JVM ecosystem is really good. Jetbrains, Google, Android/Java/Kotlin communities, and more.
Apple talks at developers for three days a year and shuts them out the other 362. The Android team at Google talks at I/O, goes out for dinner/drinks with people after, is involved in the conf circuit, sponsors the GDE program, GDG groups, and are active in community spaces
Back to Uber stuff
Burnout was real. No one really got to sit back and soak it in. Uber went headfirst into everything that happened in 2017 immediately after that. There were a couple happy hours, but happy hours are not a replacement for headspace and time. A lot of people left soon after
iirc ~300 engineers left between april and june of 2017, or 10% of the engineering force at the time.
Mobile stuff: almost everything Uber did in OSS originates from his Helix/Presidio project in 2016. OkBuck, RIBs, AutoDispose, Swift support in Buck, Artist, etc. Even later projects often had roots in it like Needle, Motif, RxDogTag, NullAway, NEAL, Cyborg, etc
Pressure sometimes creates diamonds
We greenfielded a bunch of new things all at once with the new apps, and built them with cross platform semantics (but not implementation). I.e. we used the same terminology but native implementations for each platform.
Platform UI - unified design system. On the android side, this put all eggs in the theme attributes bit. We were ahead of the curve on this, and modern MDC on android is a more polished version of this idea.
Libraries built against theme attributes like an interface and apps implemented them. This meant large shared libraries like RDS (customer support), Driver Onboarding, etc could build against these attrs but be styled natively in whichever app they were embedded in.
We built style guide apps for platform UI, and embedded them in the apps directly. Fun fact - if you have an activity intent explorer, you can launch the style guides in rider/driver/eats and play around with them. They ship in prod to this day :)
Style guides were great for reference implementations, samples, and ease for designers to look around at things.
We moved to generating all our models and API services. I don't have much else to say here other than that you should do this. No one needs to be handwriting these
Android specifics
We hit exactly one apocalyptic problem: LinearAlloc limit. TL;DR Android's OS has an upper limit to how many classes it can hold in memory. Facebook famously "patched" this way back in gingerbread days, and we were now hitting it too due to how many classes we had from code gen
We took steps to reduce classpath bloat in generated models, but ultimately Facebook shared their patch implementation (some native code) to basically steal memory from the heap and raise the LinearAlloc limit via the backdoor. Newer versions of android don't have this issue
(original FB post, for which they were pretty unfairly bashed for what was really an unfortunate OS edge case: https://engineering.fb.com/2013/03/04/android/under-the-hood-dalvik-patch-for-facebook-for-android/). Implementations of this exist on github somewhere, but I don't want to link because it's technically an exploit.
Another essential part was dual binary. Unlike iOS, we could bundle the entire new app in one APK and control rollout via server-side flag.
This is *incredibly* hard to do right though, and @jbarr21 was a fucking magician. Trying to manage all the various
This is *incredibly* hard to do right though, and @jbarr21 was a fucking magician. Trying to manage all the various
entry points to the app (intents, etc), gating them to route correctly in either of the two new apps, making sure both built against the same versions of dependencies across different repos, etc. There was a lot of heroic efforts in Helix, this was one of the undervalued ones
iOS rollout story lol https://twitter.com/can/status/1337086752872222722?s=20
James blogged about it after helping Driver app do the same here: https://eng.uber.com/carbon-dual-binary-mobile-app/
Buck was fine. I didn't love it, and contributing to it on the android side was hard if it wasn't something that Facebook themselves didn't have some immediate pressing need for. @kageiit and his team contributed a ton of its modern android support
We used intelliJ, not Android Studio. Early on in helix, at a few dozen modules, Studio+Gradle began to show incredible performance problems. Memory leaks in studio, 20min syncs, and more. This drove much of the BUCK impetus, but we still collaborated with Google too
(I'm still typing, just hit twitter's thread limit)
I can't speak toooo much about the Google stuff (NDAs), but in short they were super willing to work with us on trying to track down memory issues and a lot of the Studio and AGP perf improvements that came in 2017 were directly helped by generated sample projects we shared
@droidxav, @RalucaSauciuc, and everyone else on that team are super receptive. Again, one of those things that we really don't appreciate enough on Android and fundamentally not an option for iOS developers.
One favorite little fun story was @kageiit finding out that manifest merging used a List instead of a Set under the hood, so it grew polynomially as you added more projects with shared duplicate dependencies. Ours tried to merge 20k manifests, with only a few hundred unique.
Google accepted our patch on that one :). Pretty late in a studio release cycle too iirc
The LinearAlloc issue dovetailed with a larger effort around performance analysis after, leading to Nanoscope getting open sourced
A lot of this OSS work I think really helped uber's engineering reputation within the mobile community. While the rest of uber's reputation was largely in the gutter for justified reasons, mobile carried a degree of respect that I think wasn't fully appreciated until too late
(too late meaning: almost none of the people that open sourced the projects you've heard of are still at uber today)
There's a lot of other fun or nutty stories. Mobile platform had a visionary EM in the form of @lukestclair, and someone I owe a lot of my own career growth to.
CI infra is probably another thread's worth that @loyaltyarm should write. Turns out when you blow up your build system, you also blow up your CI.
There were a few emails throughout of "are we redlining?" or "are we missing a bigger picture?". Directors were... imo, not as receptive to these as they should have been.
I was a "no time for fools" type of asshole for much of this time. Working on a platform team in such a big project can get to your head, and I owe a lot to my teammates for mentoring me out of that at the time.
Turns out a really great way to get server-side validation of API responses is have the director's internal beta app break when he's trying to get a ride home one night. That resulted in an angry 7pm meeting with 3 teams
Feature teams were incredibly crunched. Some worse than others. One had a huge charter but also had their EM fired, were remote from HQ, & in general struggled through much of it.
Took a lot of flights between offices and pulling engineers onto it to finish, but those are also some of the most valuable relationships I gained from this time because they were great colleagues.
Android never had any of the politics that iOS had. I don't know what it is about Swift vs. Objective C, but that shit was insane to watch from our (safe) distance
We were going to launch in three cities at first in three different regions. I was going to Hefei, China. Then 3 weeks before and just as I was about to start the Visa process, we suddenly sold Uber's China business with no warning. So that was uh... canceled.
OH! That call was fun. @jbarr21, @kageiit, and I were on a zoom call that sunday night trying to find and fix memory leaks in Robolectric. We were just watching CI run with jstack attached and just taking heap dumps when we'd see spikes.
when suddenly Gautam says "uh we sold china?". Someone in uber's zoom archives this video exists 
The robolectric fixes were clutch too. We found a new API that was leaking app contexts across every test, and one dirty bit of reflection in our base test class reclaimed several gigabytes of memory on CI.
There's probably a ton of stuff I'm missing, I'm sure others will chime in. Entire backend services were also rewritten, design teams changed, ops orgs prepped for supporting an entirely new app.
