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

91–100 of 215 posts

Re: How Uber Deals with Large iOS App Size

#91

Post by bobbylarrybobby »

StreamBright wrote: post #88
MattGaiser wrote: post #42

Earlier quoted context omitted.

> This is such a non-feature for 99% of users. I would imagine that travellers are an outsized percentage of high spenders, even if they are a small portion of users.

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.…

Don’t app updates only push deltas anyway? It’s only the initial install that’s large.

Re: How Uber Deals with Large iOS App Size

#92

Post by Cederfjard »

ForHackernews wrote: post #34
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.

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.

Why are you assuming that splitting it into multiple apps would require less engineering resources than keeping just one?

Re: How Uber Deals with Large iOS App Size

#93

Post by gcbirzan »

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.

> 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?!

Re: How Uber Deals with Large iOS App Size

#94

Post by piannucci »

Farbklex wrote: post #25
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?

The Google Play Store solved this problem with dynamic feature modules. Either at install time or later on, you can let users download only certain parts of the app. All with a single app store entry and app bundle. We use this for devices which don't have NFC. If the device doesn't support it, then there is no reason to download the module for identification via passport NFC scans.

Interesting. I have had bad cell connectivity in unfamiliar airports, though, where I could barely keep a connection to e.g. the Lyft servers. What if I can’t download the module when I need it? I don’t think requiring the user to download it in advance of their flight is viable, either. If we lived in a world of universal, homogeneous, inexpensive connectivity, I’d be satisfied with the solution you mention. I guess if they had location/policy micro-modules small enough to fit in a single MTU, then anybody who could connect to Uber at all could be served.

It still boggles my mind that there could be ~100M meaningful instructions in a program.

Re: How Uber Deals with Large iOS App Size

#95

Post by sond813 »

trevor-e wrote: post #79
rememberlenny wrote: post #70

Earlier quoted context omitted.

"The Lyft app has hundreds of duplicate files, the largest consumer of space is a single asset catalog copied 73 times in separate bundles. Another asset catalog that is virtually identical except for the timestamp at which it was created is copied 67 times. Each of these contain nothing but 482 colors (colors can be stored in asset catalogs to simplify management of dark mode). With each one taking ~250kb these quic…

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.

Re: How Uber Deals with Large iOS App Size

#96

Post by jakub_g »

jbverschoor wrote: post #50
jakub_g wrote: post #22

Earlier quoted context omitted.

If you click the link OP posted and read the previous thread you will see they can "easily" do ass . They already spent millions in engineering time to cut the app size as the company existence literally depended on it when Apple's bundle size limit was 150 MB. If your app is serving hundreds of cities with specific per-city customizations and all code and assets are in a single binary, life gets tough.

If you open up the IPA, you'll see that basically they've recreated some anroid-xml compatible rendering engine. The localization files (50MB) -> All the strings files are double the size (unpacked), because of useless comments. There's 25MB already. In the assets catalog -> half an MB for an upscaled (!) visa card. Other images where jpgs of heif are a better choice. probably in total 10-20 mb. Strip all ICC/Gamma f…

Nice check. I guess they relaxed a bit since Apple raised the app size limits :) (sorry for the snark in the previous post)

Re: How Uber Deals with Large iOS App Size

#97

Post by etaioinshrdlu »

Machine-code outlining sounds kind of like the opposite of function inlining. Right down to the name! I am amazed I've never heard of this optimization technique being used in compilers before -- it sounds like it could improve performance in many cases by making code smaller (or hurt performance for the same reason that inlining can help performance)...

Re: How Uber Deals with Large iOS App Size

#98

Post by viscanti »

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?

Re: How Uber Deals with Large iOS App Size

#99

Post by [deleted] »

edoceo wrote: post #20
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.

Cannot fathom why LOC is a metric? Me neither. Lots of stuff has millions of lines of code in various languages with wide ranging feature-sets and functionality. LOC has near zero meaning across the language/project boundary.

[deleted]

Re: How Uber Deals with Large iOS App Size

#100

Post by Borlands »

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.

Exactly same experience, from San Fran to Singapore and in between. Never really realised how good we have it, such a good point
Post reply on HN