Hacker News new | ask | show | jobs
by jandrese 1944 days ago
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.

Unfortunately the way Apple and Google set up their walled gardens makes this impossible. I guess Apple would prefer if the Uber app dropped all of that and just made everybody use ApplePay instead.

4 comments

>>> 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
Uber doesn't work without decent internet access though. Maybe you can make he argument for $$/Mb, but there's no point in uber creating the app so that you can get to the pay screen without internet when you need the internet to use uber.
Decent can still be pretty bad and still work. And of course it's worth it because a phone can find/lose it's connection all the time for a bunch of reasons even if the network is high quality and high bandwidth.
The whole point is the seamless transition. Would you want to sit there twiddling your thumbs in a potentially unfamiliar area, while the region's version of the app loads? Or would you rather just have it work?
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.

It's like 5MB and you have to be connected to the Internet to use Uber in the first place.
This is anecdotal but...

I recently was traveling. I landed at a new destination and checked the internet speed. Mobile via my tablet just outside the airport was theoretically as 50KB/second via Google speed check. However actually downloading a file from US servers was 5-15KB/second because of the latency (3000ms+) being so high that packets were constantly being dropped.

That's at best, 75 seconds waiting for a download. At worst it's 16 minutes.

On the other hand, I was able to get Uber on my phone and though it was painfully slow, it found a driver in under 30 seconds.

Google encourages this with feature modules and app bundles. Apple doesn't allow it because they've always been against downloading executable code that doesn't go through app review. Same reason they don't like game streaming or downloading react native at runtime.

I'd like to see them open up this possibility in a controlled way one day. Something like a review process for feature modules that could be updated in a similar process to full apps.

Google is also serving a different market (average of lower-end phones on lower-end networks); however, I worry that every day Google's stance on apps and app review starts to look more and more like Apple's.

WRT to Apple enabling this: I imagine developers could get into a bit of a versioning hell-scape there if they were decouple updates of different modules in their app (do you know if your app is working with FeatureA v1, v2, v3, or not at all? How about FeatureB?) If Apple were to do this it would look something like app extensions do today (separate binary stored within the IPA - that's possibly thinned out and rehydrated on device); probably with very little control over what's loaded (similar to how they did rollouts: this percent on this date and nothing else)

Interesting idea, I assume Apple would solve the versioning problem the same way Google is currently handling it. Apple is doing something like this already but there isn't too much detail other than the mention of update packages here: https://developer.apple.com/documentation/xcode/reducing_you...
Actually google has recently added that feature with android app bundles. Apple has something similar with on demand resources, but specifically prohibits binary code in them. Hopefully with android having the feature, it would induce apple to allow binary dynamic libraries in on demand resources too.
Another person who think the internet is available everywhere.
Do you understand why we are assuming internet availability when ordering an Uber.
Sure, but not why you are assuming it is fast or cheap.
How are all you people without internet access ordering Ubers?