Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Uber Deals with Large iOS App Size

eng.uber.com

Post reply on HN
Print view View original

111–120 of 215 posts

Re: How Uber Deals with Large iOS App Size

#111

Post by vlovich123 »

user5994461 wrote: post #43
jandrese wrote: post #35

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…

>>> The Uber app could download the payment module you need on the first use When I'm opening Uber at 1am in the cold to get a ride home, this is not the time to download a payment SDK update.

This keeps getting repeated in this thread & I keep not understanding it. If I downloaded Uber & set it up with the payment method that I need, why would that payment method suddenly change at 1am in India?

The way this should work is when you set up payment option X, it downloads the relevant payment info & then you're set from then on without any other modules unless you add a new payment option. Likely pre-bundle the generally "global" options (Apple Pay/Android Pay since those are platform-native & credit cards since those are likely small implementations).

The real reason is that you will always have drop-off because the download phase is split in two (on the other hand you'll have increase in installs because the app size is smaller). That would need App Store integration with the loadable modules so that you could say "Install these payment features of the app". This may not be a win because again, it requires the user to do more work. Simple for everyday users will often win the day even if inefficient vs more optimal options that achieve that optimality by pushing complication to the user.

Re: How Uber Deals with Large iOS App Size

#112

Post by corin_ »

minhazm wrote: post #86
ForHackernews wrote: post #34

Earlier quoted context omitted.

This is such a non-feature for 99% of users. The fact that Uber devotes engineering resources to serving the tiny 1% slice of users who care about having an app that works seamlessly across dozens of countries, at the expense of the much larger number of users with limited space on their outdated devices, is really emblematic of the Valley's out-of-whack priorities.

It's not even just per country. If you fly to certain airports in certain states they have different rules that affect what the Uber app can do. Do they maintain a separate app for Washington and for New York? It gets pretty messy pretty quickly. Not only do you have to maintain these different edge cases, but you also need to maintain separate applications and all of the problems associated with that like keeping li…

I'm probably missing something obvious as I'm tired, but why does the Uber app need stuff like specific airport rules stored in it rather than pulled from their servers when needed?

Map apps let you look at any city in the world without needing all of that data inside the core app, and if you have enough data to use the Uber app wouldn't you almost certainly also be fine to have it download in the background the required info (coordinates of where pickup is or isn't allowed, specific instructions message to display, etc.) the same as it receives information about local pricing, location of available cars nearby and so on?

Re: How Uber Deals with Large iOS App Size

#113

Post by onemiketwelve »

gcbirzan wrote: post #93
spoonjim wrote: post #27

Earlier quoted context omitted.

I love that it’s one app. I remember landing in Delhi from San Francisco and the Uber app worked perfectly and I was so astonished. Effectively nothing else translates seamlessly like that. Combined with the incredible quality control on the vehicles side (every car I got in India had a seatbelt, where close to 0 taxis you’d get on the street would), I knew it was a very high functioning company to execute like this.

> every car I got in India had a seatbelt That sounds so weird to me... What do you mean cars don't have seat belts?!

75% of Ubers in Egypt didn't have seat belts. It's just tucked away and not culturally the norm

Re: How Uber Deals with Large iOS App Size

#114

Post by superkuh »

viscanti wrote: post #98
superkuh wrote: post #26

Uber is just a scam to launder saudi blood money through softbank. There is zero chance that human driven cars will go away. And self-driving cars cannot drive on roads with human drivers. Uber is in the later stages of the scam now and have "sold" (actually, they gave 400 million USD to the company they "sold" the division too) their self driving setup. They've admitted the only business model that would make them p…

According to their public investor reports, they've been EBIDTA profitable on Rides for years. They're also profitable in more rationalized Eats markets (markets where there aren't other VC funded companies burning hundreds of millions of dollars on subsidies). What do they need self driving for?

To still be profitable after they stop breaking local laws and regulation catches up with them. https://horanaviation.com/publications-uber

Re: How Uber Deals with Large iOS App Size

#115

Post by dliff »

spoonjim wrote: post #27
jedberg wrote: post #17

Earlier quoted context omitted.

The summary of that comment is "we have to include a ton of stuff that will never be relevant to most users like payments APIs that only work in India." This is why some global apps have different apps for different countries. It's a trade off. Would you rather have a single fat Uber app, or have to download Uber India when you arrive there?

I love that it’s one app. I remember landing in Delhi from San Francisco and the Uber app worked perfectly and I was so astonished. Effectively nothing else translates seamlessly like that. Combined with the incredible quality control on the vehicles side (every car I got in India had a seatbelt, where close to 0 taxis you’d get on the street would), I knew it was a very high functioning company to execute like this.

While I had a positive experience with the Uber app software-wise (app functioned seamlessly landing in Mumbai from U.S.A.), Uber as a service was not really comparable to what it is like in the U.S. and developed W. European countries. I got the sense that it was more of a strictly ride hailing / request service, not much accountability required from the driver. Often had > 3 drivers cancel after 10-15 minutes waiting before actually getting a ride. That being said, it was still a hugely valuable service to have in India as a foreigner.

Re: How Uber Deals with Large iOS App Size

#117

Post by dntrkv »

thegeomaster wrote: post #6

It has... a few million ... lines of code? What? Linux has 30 million of C! I'm speechless. I cannot fathom how & why.

How? 1000 engineers x 1000 LoC/each = 1M LoC

Why? If you have 100+ engineers at any given time, shipping features over a period of a few years, you'll hit 1M in no time.

It sounds like a lot, but it really isn't when you consider the amount of people working on it.

Now whether or not you can build the same thing with less LoC, probably. But it's not like it was built from the ground up with every piece of functionality planned out from day 1, so there will be inefficiencies.

Comparing it to Linux is pointless. Platforms should be relatively stable, products are ever changing and the shelf-life of the code is sometimes measured in weeks/months.

Re: How Uber Deals with Large iOS App Size

#118

Post by saagarjha »

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 that is not enforced by the usual tooling that checks binary size, or the build process adds duplicate files into the bundle that nobody notices. Sometimes the underlying issue is hard to fix, like if it’s code size explosion due to a custom templating engine, but they really should get addressed at some point. Changes like these don’t actually solve the underlying issues, which can be a benefit for a while, but eventually they become so complex that it is hard to maintain them and they start impacting productivity in harder to measure ways by doing things like increasing build times and reducing the quality of debugging information.

Re: How Uber Deals with Large iOS App Size

#119

Post by Spivak »

tomaskafka wrote: post #63

This seems like a case of sloppy product management saved (or rather having its consequences delayed) by person-years of ingenious engineering. Build times in tens of minutes seem terrible.

Oh I would kill for a sub half hour build time at $dayjob.

Re: How Uber Deals with Large iOS App Size

#120

Post by MattGaiser »

Bjartr wrote: post #110
StreamBright wrote: post #88

Earlier quoted context omitted.

As a frequent traveller, I would be much more inclined to either pick the airports that are going to be relevant to me ever or pick the destination airport when I am at the source airport which Uber can easily detect. I am visiting ~10-15 airports most of the time. I would be happy to spend some time to set this up on my phone so i not need to waste a huge amount of space and bandwidth every time that I update Uber.…

A willingness to put in some time up front to tailor a technology experience to yourself is one thing that separates the average HN user from the population at large. For a significant majority of users, if it doesn't work well out of the gate, it's broken.

Even as an avid Hacker News user, I wouldn't tailor an app download to save bandwidth/space. Both of those are abundant.
Post reply on HN