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

81–90 of 215 posts

Re: How Uber Deals with Large iOS App Size

#81

Post by reader_mode »

wdb wrote: post #77
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.

Personally, I would download whatever the dominating hailing app is in the country. Most of the time its cheaper than Uber like Grab in parts of Asia

If you're landing in Asia from the US you're probably not going to care about the price (there are exceptions), and Uber has been reliable for me travelling, if that costs a few % more than the local version I'd be happy to pay for convenience.

Re: How Uber Deals with Large iOS App Size

#82

Post by owenversteeg »

mkipper wrote: post #28
bhupy wrote: post #18

Earlier quoted context omitted.

> This is why some global apps have different apps for different countries Do you have some examples? Genuinely curious. To my knowledge, most of the major FAANG apps are single-binary.

Dedicated apps for fast food chains are one example. A quick search gave me "Burger King India", "PizzaHut Egypt" and "KFC UAE". Why? I have no idea.

Totally different requirements. Some countries' fast food apps are for mobile ordering and delivery, some are a giant collection of coupons, and some are only for nutritional information. And some are just for promotional activities (only used for various promotional calendars.) After seeing all the different APKs I tried out a few for different countries out of curiosity and at least for Burger King they were entirely different applications with completely different use cases. To cram them all into one global app would be an enormous mess.

Re: How Uber Deals with Large iOS App Size

#83

Post by rememberlenny »

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.

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

Re: How Uber Deals with Large iOS App Size

#85

Post by manigandham »

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.

It's much more complicated than just countries. If you read the linked comment then you'll learn that it's includes many regional customizations, even down to specific cities and airports.

An app for travel should absolutely prioritize UX and ease of use as you travel, however far away your destination is.

Re: How Uber Deals with Large iOS App Size

#86

Post by minhazm »

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.

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 libraries and API's in sync between them.

Re: How Uber Deals with Large iOS App Size

#88

Post by StreamBright »

MattGaiser wrote: post #42
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.

> 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. For Uber it would be a win too, reducing the size of the app significantly. Maybe it is only me.

Re: How Uber Deals with Large iOS App Size

#89

Post by ProAm »

reader_mode wrote: post #81
wdb wrote: post #77

Earlier quoted context omitted.

Personally, I would download whatever the dominating hailing app is in the country. Most of the time its cheaper than Uber like Grab in parts of Asia

If you're landing in Asia from the US you're probably not going to care about the price (there are exceptions), and Uber has been reliable for me travelling, if that costs a few % more than the local version I'd be happy to pay for convenience.

> Uber has been reliable for me travelling

Unless India? [1]

[1] https://www.theguardian.com/technology/2017/jun/08/uber-exec...

Re: How Uber Deals with Large iOS App Size

#90

Post by viktorcode »

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

Post reply on HN