71–80 of 215 posts
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
https://mobile.twitter.com/stantwinb/status/1336890442768547...
I can’t seem to find the old link, but I’m pretty sure it was on hacker news and somebody posted a nice collation of the posts.
Earlier quoted context omitted.
>>> 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.
Or when you just landed on the other side of the planet and don't have a good internet access (or it costs $$/Mb): the app is still expected to work, because you need your ride right now
I’m the founder of a YC company in the current batch focused on solving this exact problem! https://www.emergetools.com We parse Obj-C and Swift runtime metadata to determine size contributions of individual types and functions in your app. We use this analysis to post PR comments with granular size diffs to help devs write smaller, better code. I tried it out on the Uber app and immediately noticed a disproportionat…
Launch HN: Emerge (YC W21) – Monitor and reduce iOS app size - https://news.ycombinator.com/item?id=26014180 - Feb 2021 (44 comments)
Earlier quoted context omitted.
Let's say there are a hundred screens in the app and the app is 300mb. Does it really take 3mb of source code, about 3/4 of a bible, to render one screen? (I do understand that source code isn't what ships in the binary, but for the sake argument let's say they're 1:1 in size.)
Considering that Uber's binary size (330MB) is comparable to similar apps such as Google Maps (224MB), Lyft (435MB), and Didi (332MB), it might just be par for the course for iOS apps. Yelp, for example, is what you might call a "straightforward CRUD app" (to Yelp engineers, I know it's probably legit complicated and hard), and that is 292MB on the App Store. It's probably to do with how the framework handles lifecyc…
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.
I would agree with this. At home I walk, ride my bike, get on transit, rent a carshare etc. When I'm travelling, I'm walking or calling an Uber/Lyft. I'll take a train or bus only if it's super easy to navigate.
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.
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?
> 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.
Worked on iOS app size at a FAANG for a couple of years -- this is untrue. At the very least there are different binaries for watch vs iPhone architectures.
I’m the founder of a YC company in the current batch focused on solving this exact problem! https://www.emergetools.com We parse Obj-C and Swift runtime metadata to determine size contributions of individual types and functions in your app. We use this analysis to post PR comments with granular size diffs to help devs write smaller, better code. I tried it out on the Uber app and immediately noticed a disproportionat…
"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…
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.
Not all customers are equal. And if you build your app or site without knowing that you may well chase the wrong features.