Live data from Hacker News

How Uber Deals with Large iOS App Size

eng.uber.com

141–150 of 215 posts

Re: How Uber Deals with Large iOS App Size

#141
post #123

Earlier quoted context omitted.

Connectivity at airports is not the best - if you’re on an expensive data plan those extra MBs cost a pretty penny which might put off the customer. You need to think about the larger picture.

Give the streaming of location data for cars in the area, I don't think they care much about those extra MBs. If they did, you'd get a "N cars within X km of you", not a live-ish map. A quick summary like "extra fee for airport pickup: X, pickup location restricted to: Y, etc." should be pretty comparable.

A live map of cars near you takes an incredibly small amount of data. Once you have the map data that'd be easily doable over a dialup connection.

Re: How Uber Deals with Large iOS App Size

#144
post #39
post #4

Complementary: This thread on Uber's transition to Swift that almost broke them https://twitter.com/StanTwinB/status/1336890442768547845 Includes, among other things: forcing Apple to increase cellular download limits, 45 seconds for letters to appear in XCode, 12 seconds to call main, rewriting the linker and so on.

Good read. Good to know that Uber engineering culture was as much of a dumpster fire (despite the brilliant moves) as their product.

Brilliant is a big word for a company that still hasn't earned a profit

Re: How Uber Deals with Large iOS App Size

#145
post #121
post #104

Earlier quoted context omitted.

People have even chuckled when I reached to put a seatbelt on in India. :)

Not sure what to make of this. I’m Indian and the last time I was in India, there was strict execution of the seatbelt law and offenders were made to wait and fined heavily. Most drivers were wearing seatbelts. Maybe because it was in Chennai, a southern state and not in Mumbai or Delhi.

Sounds plausible. I was in Delhi a couple of years ago, using mostly Ola (Uber didn't seem to like my non-Indian card, strangely enough) and most of them did not have seat belts at all.

Re: How Uber Deals with Large iOS App Size

#147

Earlier quoted context omitted.

My biggest complaint with iOS development is how confusing Xcode's build system is. Extracting code out to shared frameworks is a confusing process and I can understand how so many of the top apps get it wrong. Also, it's clearly not a priority for Apple because they don't provide easy inspection tools. Best case for them is the user buys a new phone with more storage.

I’m curious - does React Native/Expo do any better job at this, with tree-shaking and package building?

Expo produces ridiculously huge bundle sizes. I Would steer clear of it.

Re: How Uber Deals with Large iOS App Size

#148

This is certainly an great read, and working on it must have very interesting. That being said, in my experience things like these are invariably technical band-aids over social problems. Whenever I see things like this, often paired with statements like “there’s so many screens and feature flags”, usually the problem is not there but actually in many other processes: for example, the design team adds assets in a way…

> usually the problem is Usually, sure. But sometimes there is a lot to do, and if I may, Uber is not your usual app. At the point where you're being very choosy about the access modifiers on your classes, you probably thought about icon assets already. Someone elsewhere in thread linked to a partial list of concerns the app needs to cover, many of which are location-specific. You might say "well split the app by geo…

> At the point where you're being very choosy about the access modifiers on your classes, you probably thought about icon assets already.

You'd think, but many of the most popular apps accidentally ship these all the time. I think another comment mentioned that much of the code size seems to be coming from a code generation framework.

Re: How Uber Deals with Large iOS App Size

#149

> The app has a couple of millions of lines of code I wonder if Uber is planning to do anything about that? The technique described in the article (whole program instructions outlining optimisation) is a band aid style solution, merely delaying the inevitable: the code produced by numerous teams independent of each other will inevitably cross first the download size limit threshold, and later maintainability threshol…

> later maintainability threshold

I mean I imagine no one person or team completely understands the entire app. Different people/teams are responsible for different portions of the app. Each team only needs to understand their modules and the few other modules they interact with.

Re: How Uber Deals with Large iOS App Size

#150

Earlier quoted context omitted.

It strikes me that this would be the perfect use case for loadable modules. The Uber app could download the payment module you need on the first use and leave the dozens of other APIs off your device. This could also significantly cut down on the number of updates (300MB downloads each time!) that the app needs, since NA or European users won't have to re-download the app because some Indian payment API changed. Unfo…

Another person who think the internet is available everywhere.

Do you understand why we are assuming internet availability when ordering an Uber.
Post reply on HN