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

171–180 of 215 posts

Re: How Uber Deals with Large iOS App Size

#171

Post by bhupy »

corin_ wrote: post #126
ameen wrote: 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.

Wouldn't it be significantly less than a MB for all the info about "how does Uber work at this airport" info to come in json or whatever? It could surely survive without downloading special airport-specific media like logos, do the airport rules require complicated heavy code on the phone? Thinking of my experience with Uber at airports, it's generally stuff like "pickups from this terminal are only available at the…

It’s also the airport layout information, including doors. From most US airports, you specify your pickup point by door (Arrival E6, for example), and I think some of that information lives in the app, along with the snap points that are rendered on the map (or even just the logic). There’s usually also a specific UX when requesting the ride where it asks you to select your airline to guess which terminal and egress to set as the pick up point.

Re: How Uber Deals with Large iOS App Size

#172

Post by spoonjim »

jawzz wrote: post #160
spoonjim wrote: post #153

Earlier quoted context omitted.

Uber India isn’t like Uber New York but it’s a million times more reliable and predictable than almost any other commercial service you can get in India.

Really? Seems like it’d be more reliable and a lot faster to just hop in one of the hundred rickshaws on every street. Besides the fact that they’ll overcharge you if you’re a tourist.

Have you seen those things in an accident? I can easily afford the Uber with seatbelts and I am not going to trust my life to a three wheeler.

Re: How Uber Deals with Large iOS App Size

#173

Post by wdr1 »

jedberg wrote: post #17
bhupy wrote: post #7

An old (but fantastic) comment from the previous discussion about Uber's app size that addresses why the Uber app is so big: https://news.ycombinator.com/item?id=25376346

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?

Easy. One app.

When I traveled to India (pre-COVID), it was great that I could just open the app & get where I needed -- even if I wanted to travel via tuk tuk.

It was more annoying when I got to Ireland, had to figure out the app to use was MyTaxi and get it all working (including payments), particularly as a foreigner.

Re: How Uber Deals with Large iOS App Size

#174

Post by satya71 »

satya71 wrote: post #39
dmitriid wrote: 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.

Hmm, looks like this comment didn't go over well. I think they had brilliant engineers (far beyond what I can even imagine) that pulled-off incredible feats to avoid disaster. But the disaster need not have loomed. Rewrite-the-world development smacks of what I call "cowboy engineering". Why didn't they migrate the existing code-base one layer at a time?

Re: How Uber Deals with Large iOS App Size

#175

Post by Marsymars »

ryanlol wrote: post #152
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.

There’s me, a frequent traveller who uses UberLUX 4+ times a day, spending more than 5000GBP/mo. Then there are 100 guys with outdated devices who use UberX once or twice a month to get back home from the pub, probably splitting the ride with their friends. I bring in more money than the latter group of people.

I’m a bit surprised you have the time for UberLUX. When I find myself with an expense account for Uber I always go for the lowest ETA, which is rarely Uber Premium. You must be hanging out in richer places than me.

Re: How Uber Deals with Large iOS App Size

#176

Post by ohiovr »

dntrkv wrote: post #117
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 functionali…

The app is the size of a Debian installer with dozens of executables made over the course of 50 years.

Re: How Uber Deals with Large iOS App Size

#177

Post by Marsymars »

Scoundreller wrote: post #21
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?

Personally? A single fat app. Less fumbling around when I land somewhere to get their localized app, which will presumably only be available from that country’s App Store that’s inaccessible before I land there. If I have to deal with the airport’s wifi... I don’t want to depend on downloading a 100mb binary over it. Maybe they could have a local and global version available, but that’s already making it more complic…

Not that it affects your overall point, but countries’ app stores are gated based on region you’ve configured your phone to, not where the phone’s physical location is.

Re: How Uber Deals with Large iOS App Size

#178

Post by ohiovr »

dmitriid wrote: 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.

I'm sure swift's shifting sand castle language changes didn't help.

Re: How Uber Deals with Large iOS App Size

#179

Post by ohiovr »

pid_0 wrote: post #144
satya71 wrote: post #39

Earlier quoted context omitted.

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

They took a lot of investor's money.. So in a sense it was a success.

Re: How Uber Deals with Large iOS App Size

#180

Post by tomasreimers »

sond813 wrote: post #95
trevor-e wrote: post #79

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.

Yep this is exactly the problem I'm trying to solve! A lot of large app companies have switched from Xcode to third party build systems like Buck or Bazel. This can make things faster but even more confusing. I've found analyzing the actual build products to be the best solution to make sure nothing unintended is happening.

Interesting! Are you interested in going back into the build process to try and thin the app directly? Or just in helping developers identify the sources of app size?
Post reply on HN