There are 153 payment methods? That's crazy! We need one standard for all of them... now we have 154 payment methods.

@vibhorrawal

3 жыл бұрын

The Indian govt solved just this issue for the country with UPI aka Unified Payment Interface

@MOOMOO22MOO

3 жыл бұрын

Xkcd is always relevant

@AlbertoRodriguez-oe6jo

3 жыл бұрын

PURE GENIUS!

@mauricewalshe8339

3 жыл бұрын

Amen - 20 years ago I worked on doing a simple cheap paperless direct product product for charity regular donations - every dam bank wanted a different form *sigh* and that was Just the UK

@brucebatmanwayne8514

Жыл бұрын

@@vibhorrawal how exactly did it solve if you have paytm, Indian specific credit cards, Amazon pay? Granted some high % of Indians use it but it didn't "solve" anything. Uber and rest of the apps still have to put equal efforts in supporting other methods of payment in India

short answer: there aren't regional versions of the app, so there's lots of special cases for other countries all contained within your phone in addition to the already decent size for your specific region.

@CocoaPimper

3 жыл бұрын

I think having multiple region-specific versions of the app is not the way to go because what if you travel e.g from the US to India? You would have to download the "Uber India" app… I think this could be anything from confusing to not possible.

@danielanderson5806

3 жыл бұрын

@@CocoaPimper I think it would be a convenience issue for their customers, and realistically with all of the streaming options for everyone's personal files the app size isn't really an issue for most

@CocoaPimper

3 жыл бұрын

@@danielanderson5806 It is not only a convenience issue. If you have a German Apple ID you can only download apps that are available in the German App store. So Uber would be required to have an app for every region: "Uber USA", "Uber DE", … and make them available globally without any regional restriction. This is what I meant by saying that it goes from inconvenient to not really possible - depending on the business requirements.

@ms-9

3 жыл бұрын

they could always do as Citymapper: when you move out to a new city just download the city pack within the app and delete the old one

@CocoaPimper

3 жыл бұрын

@Lab Monkey The video is worth watching. Maybe not because of the size issue but because it shows that something seemingly simple can be extremely complex.

Then you have the geniuses that approach you like: "I have this amazing business idea: It's like Uber, but better. Don't worry we have it all figured out, we just need you to do the coding."

@dw4525

3 жыл бұрын

We just need somebody to type it all up.

@Rikenm14

3 жыл бұрын

literally all devs have been hit with this. Maybe it's the same guy who has a brilliant idea who we all have ignored messaging all the devs.

@dinkleberg794

3 жыл бұрын

@@llVIU And then on top of that they have expectations that you can finish the app within a month

@hrgwea

3 жыл бұрын

Yeah but remember that many of these software giants were initially developed by a single guy. Google search engine made by Larry Page. Linux Kernel made by Linus Torvalds. eBay made by Pierre Omidyar. The Facebook website made by Mark Zuckerberg. It's only when you put a lot of people behind a product that the thing becomes a monstrosity. So we must not discourage people from trying to compete. They will have to start simple at first. And if they do well, they will grow and one day will become a 300MB gorilla too.

@Swanicorn

3 жыл бұрын

@@dinkleberg794 Most of these things have been already implemented and implemented a million times. If it were modular indeed one month is way too much. There is absolutely nothing ground breaking happening in this app.

That state of the art user fingerprinting and tracking technology takes up a lot of space!

@Koj4

3 жыл бұрын

True.

@antonliakhovitch8306

3 жыл бұрын

I mean, in order to use the app you willingly give it your location and a bunch of personal info. No need for fingerprinting and tracking tech (which doesn't take much space anyway)

Answering the most common questions: 0. Disclaimer: as of late 2020, I no longer work at Uber. The best source of information on how Uber is going about building the app is their excellent eng blog: eng.uber.com/. E.g. see this post on advanced binary size reduction approaches: eng.uber.com/how-uber-deals-with-large-ios-app-size 1. "Why does Uber need an app? It could work with a lot less data on the web." - There IS Uber on the web, and has been for many years at m.uber.com The web app is less than 50kB and is optimized to work very well on 2G as well. Here's an in-depth article from 2017: eng.uber.com/m-uber/ . So why does no one use it or know about it? Because people want an app, and only search on the app stores! 2. "Could you have not created different, and smaller Uber apps for each country?" - Every new app takes more engineers to maintain. Every new app also creates confusion - and revenue loss - for travelers - some of the most valuable segments for apps like Uber, and a major part of Uber. So this would mean hire more engineers, for less overall revenue. 3. "Could you not just download parts of the app as components?" - Uber is built to operate in low bandwidth environments: such as when landing in a new country, in an airport. So while it is possible to do, it adds complexity (need to hire more engineers) and can reduce revenue and add to customer frustration (the case of someone landing at the airport and trying to request a local Uber, while having to download country-specific details") 4. "Why are you using SDKs?" - often down to payment providers. Their SDKs usually do a better job over e.g. fraud detection. It can also be part of a business deal. 5. "Can you not just use Stripe?" - almost all payment methods I shared are not supported by Stripe. We used a competitor to Stripe when I worked there for credit card processing. One thing to keep in mind: I cannot share all the (internal) constraints and data that we saw at Uber, when we decided to proceed with the approach we did. There are very smart people working on the app, doing extraordinary things - read this article on binary size optimization eng.uber.com/how-uber-deals-with-large-ios-app-size . If it seems like a company like Uber is doing something silly, there are two possible explanations: 1. The people working there make worse decisions that you would, given the same information & constraints. (In this case: you should totally apply to work there & make better decisions!) 2. The people working there have data and constraints that you don't know about. In my experience working at large companies, #2 is almost always the case.

@asnaeb2

3 жыл бұрын

>If it seems like a company like Uber is doing something silly, there are two possible explanations: In my experience with large companies, #1 is almost always the case.

@ritwik5774

3 жыл бұрын

@@asnaeb2 well then you've worked with some pretty shitty large companies, haven't you.

@lohitakshtrehan6379

3 жыл бұрын

There is one more scenario like airports. So there are Metro's in India. Uber started a different way to get cabs from a metro station and it was an offline way to book the cab. So one more thing you can add in New video :D

@lohitakshtrehan6379

3 жыл бұрын

Also there is an app: Uber lite

@Merctoonz

3 жыл бұрын

So the reality is Uber didn't properly plan to scale or didn't research all potential markets.

TLDR : lots of pieces, lots of code regarding other regions of the world so the app doesn't need to download that if you travel. the bigger tldr that he didn't really mention; is that 90% of this is offloaded onto the app (the logic and all of that could be serverside) so the app doesn't have to download it from a website (if it were a web app) so that the performance of the app is faster. it's about shaving fractions of seconds on load times, and working in situations where internet connectivity might kinda suck.

@feedbackzaloop

3 жыл бұрын

This, Sir, is how one truly answers "why" but not "how". Thank you very much!

Basically India is what makes uber app and the world large😂😂

I am from India and never thought about the complexity Uber has to deal with just because of Indian payment methods.

@mrgergelyorosz

3 жыл бұрын

Haha! India is a massive Uber market and payments work different to many other countries. I happened to work on a team where we spent a good chunk of our time building these payment methods for some time. Now there's a payments team in India who have taken over and are doing great work on these. And I didn't talk about Airtel Money (no longer supported, but worked on it) or Jio.

@varunr3943

3 жыл бұрын

@@mrgergelyorosz In India, the wallets and payment methods have become so integrated in the life style that people can live couple of weeks without ever needing their wallet. Not every age but but definitely the Millennials.

@varunr3943

3 жыл бұрын

@@mrgergelyorosz I know now why Uber Hyderabad always hires engineers for the payment features.

@mrgergelyorosz

3 жыл бұрын

@@varunr3943 yep - I know a lot of engineers there! We worked closely with them from Amsterdam, I once almost visited as well (other people on my team went). They are starting to own not just India, but all global payment methods as well last I heard.

@sadhlife

3 жыл бұрын

@@mrgergelyorosz yeah, UPI is taking off. The internals of the integration I've heard are still a pain to work with, but it's getting better, and the public facing APIs are just so nice that I can only be impressed with it coming from India.

The answer "because the app is really complex" makes no sense to me. A typical Linux kernel is 70MB and there are probably 10-100x more moving parts and special cases than in the Uber app. It really comes down to a decision of favoring easier development, growing as fast as possible, ...

@overloader7900

3 жыл бұрын

And then there is nvidia graphics driver, which are 500 megs... Apparently making it work on few hundred CPUs is easier than fixing other people's mistakes

@son_guhun

3 жыл бұрын

Where did you get this number of "10x to 100x" more moving parts/special cases? Is it just an estimate, and if so, what did you use to estimate it? Also, have you considered that the fact that they use a much higher level language than C might account for a few MB's (though I would wager that the difference would be less than 10 MB)?

@BullCheatFR

3 жыл бұрын

@@son_guhun the 10-100x figure is a complete guesstimate. Who cares what it really is. The Linux kernel is a 30 year old project with 15,000+ contributors all over the world and working in different industries. It supports 10-100 architectures. You can check for the actual number but it is somewhere in there. It has (constantly updating) rules for wireless stuff for every regulatory region. It works with almost every peripheral device (by sales volume). Thousands of printers out of the box. It runs on anything ranging from SD Cards (those with wireless capabilities) to supercomputers. You can honestly browse the source code and just read the comments there. You will get a feel for the insane complexity of a modern operating system kernel. It's nothing like any app. I'm not saying the app *should* be lightweight. I'm saying that, speaking from experience, the app is not heavy because of business logic. It's heavy because they can get away with it. Here's another example: on my phone, the Bose Connect app weighs 70MB. It let's me change a few settings on my headphones and upgrade their firmware. That's it. Meanwhile the Google Earth app is 32MB. The SMS app is 1.3MB (it has special rules for every region in the world too). The Quora app is 60MB. Whatsapp is 60MB. I fail to see how Bose Connect would even come close in complexity to any one of those. Yet it is heavier. Text, small PNGs and business logic never weigh 300MB. Heavy frameworks, tracking tools, feature management, ... do

@unitrader403

3 жыл бұрын

@@BullCheatFR got an even better example: last time i installed a Printer Driver on Windows the Download for that was 150MB. Also wanted to use the same Printer on a Linux Machine, for which i had to get the driver seperately. it had 70kB. Both esentially doing the same work.

I still imagine a backend developer crying somewhere

Still doesn't explain why it's so large. It's not big art assets, most sounds like just code which shouldn't take this much space

@flobbie87

3 жыл бұрын

Exactly. He didn't explain crap.

@SimonBuchanNz

3 жыл бұрын

"Just code" can be quite large, actually: TLS is about 3MB IIRC, to give a scale. But generally you're looking at error message tables in multiple languages, certificate root lists, API endpoint metadata, unicode support, exception tables, async state tracking machinery etc, even before you start looking at written source code. And there would likely be at least some art associated with each of these, for logos if nothing else.

On freelancer i saw an announcement 📢 saying: i need something simple, like uber for less than 100 dollars! 🤣🤣🤣 There you are! Good i knew that it wasnt that easy! 😁😁😁 Good explanations! 👋👋👋

New Subscriber here. Fantastic video. Thank you for taking the time to explain all these aspects we tend to oversee as users.

@mrgergelyorosz

3 жыл бұрын

Thanks for the feedback!

Thats a lot of logic to be included, for sure - but given that a full install of Microsoft Office 2003 - with all the logic required for Word, Excel, Access, Publisher, ... - was only 400mb, 311mb still sounds excessive.

Incredible video, hope to see more content like this, question, how would stripe simplify this things?

@mrgergelyorosz

3 жыл бұрын

Hey José. Stripe would only replace the current credit card SDK with the Stripe SDK. It wouldn't simplify much. Stripe doesn't allow you to use PayPal, PayTM, UPI, and many other payment methods present in the Uber app. Also, at Uber's and similar company size, Stripe's fees are typically too expensive. No large provider would use Stripe - when you have millions of daily transactions, it's rarely worth doing so, over skipping middlemen. It's why you'll be unlikely to see Stripe checkout on Amazon, eBay, and other large merchants. When you're a small business, this might be different.

As a software engineer myself, I don't think needing "regional specific code" would constitute a binary of 131mb. The code to do this would easily compile to a few kilobytes. I haven't looked at the binary of Uber, but usually app that are multiplatform use a lot of libraries. Which are not optimised. They would contain code that is never used, but is still in there. say, for instance, why include a Math library, when all you need it for is pow()? it would cause a lot of extra code that is never used, when you can just multiply a number by itself a couple of time. (simple example, but gets the point across). If you build a native app from scratch and write the code yourself, instead of relying on external libraries, you can cut down the size with at least 80%. You list a lot of Credit card and payment options. Chances are, those SDK's have a lot of code that basically does the same thing! So just implementing the API's from scratch can prevent duplicate code from just simply using their SDK. This is also why Windows takes tens of GB's to install, because it has thousands of dll's that contain a lot of features and are rarely used. Drivers for devices you don't even have etc. And to compare it to a decent Linux distribution, which can fit in a few Mb's up to maybe 2gb if you want a desktop interface. Because it would not install stuff you don't need. My point is, "software optimalisation is dead". It's easy to just tie together a few libraries, and make an app. Also with games, remember the times when incredible games were made for consoles in just a few mb's, and new optimisations were invented just to squeeze out extra frames? that's history! a game (excluding 4k textures) nowadays is huge, while the actual code and logic is just a fraction. But it's all libraries and extra bull shit you don't need, but hey it's easy and fast. I'm not saying this is a bad thing perse, but it's the main reason why software is huge and bulky.

@mrgergelyorosz

3 жыл бұрын

Being on the inside, a few things about SDKs: - Often these are tied to contracts. I cannot give a very specific example, but imagine among the lines of "we'll give you a 0.2% decrease on fees if you use our SDK that has advanced fraud detection capabilities." Calculate how much 0.2% on hundreds of millions, or billions processed is :) - Often if you do not use the SDK, you cannot integrate the payment method. UPI is a good example. Not just for Uber: but any app. - When using an SDK, you are moving the burden of building and maintaining the functionality to who owns the SDK. Yes, engineers at Uber might be able to rebuild similar functionality in-house for e.g. PayPal... and then they would need to keep track of the public API changes, add in performance optimizations and so on... that's in the SDK. The cost of becoming a domain expert is a very real cost, and the cost of mistakes with e.g. payments functionality is an expensive one. I agree that software optimization is dead - at least on iOS. Much of this comes from the mothership: Apple. The very same app written in Swift will be much bigger than when done in Objecive-C, and Apple is doing little about it: they've practically admitted the problem as they've increased the OTA donwload limit from 100MB a few years back to 200MB recently. Same goes on how apps are bundled: Apple will add in e.g. the WatchOS app into the bundle, even if the user has no WatchOS. It makes me wonder if growing apps might not be in their disinterest, as they can upsell larger storage phones?

@iWhacko

3 жыл бұрын

@@mrgergelyorosz Thanks for your reply. I was not aware of certain contracts, and mandatory use of SDK's because of advanced features in them. Makes sense in a way. Also, great point about the maintanance, which is true. Not having to worry about api changes is a good thing. But still, a point could be made about using arbitrary libraries, because it has some convenient functions. Let's say including a library to handle SVG files for all images in the app, could be nice not to have to store images for different devices. But what if that library is 10mb because it is not only for svg, but a lot of other filetypes? then having a few extra png files, would take up less space all of a sudden. What I mean by this, we should be critical about the libraries we use, and really think about it if it makes sense. I myself develop on iOS too, and only use Objective-C (I find swift, and other loosely typed languages horrible), I find myself using external libraries too. Most of them are open source. Sometimes, I just copy a part of it, because it has a smart Category in it to extend certain UI classes for instance. I do this, becuase 90% of the library I don't use. But it does take up space.

@daniellarson383

Жыл бұрын

@@iWhacko and this shows the difference between a technical engineer and a product focused engineer. Just because you can write something yourself to save minimal size, is it always worth it? 30-40 years ago, getting every single processing optimisation, while taking it's time, had a decent ROI because of the hardware at the time. Today, optimising and worrying about 5 to 10 mb when we have terabytes of space for almost nothing makes absolutely no sense. Optimising to save that could easily cost you more than what it would actually save, so why bother? I love engineering things to the nth degree and being absolutely dogmatic about building my own systems, but I do that in my own time because it's fun. There's more value in quick to launch systems, fast failure and iterative development processes against product, as opposed to underlying infrastructure to support product, that I can't ever see a good reason to save that minimal amount of space to the amount of space we now have available

Super interesting stuff taking practical use and contrasting it to the backend side of things!

Very interesting to see the complexity of supporting different payment options around the world, thanks for sharing! What bothered be a bit though was the lack of variation in the complexity estimations. Almost everything resulted in being an L, which made it hard to compare things between themselves.

@mrgergelyorosz

3 жыл бұрын

So in the end, most of the projects with an L took similar time to complete. An "S" would be something you could built in a week or two with an engineer per platform and that's it. An "M" something that's say a month with 1-2 engineers per platform. An "L" is where it's 1-3 months with multiple engineers per platform. Turns out when you're talking payments, and you need to support multiple countries, there's rarely a project that's an S. An M would be something that is one country only and is a simple integration. E.g. Venmo: but then we had a bunch of migrations, a special launch & promo plan, and it had to work on Eats at the same as Rides. And then something that would seem simple - like adding Google Pay - becomes complex at the scale of Uber, and launching in 10+ countries. Here's a video on that specific project: kzread.info/dash/bejne/q6OjpaducpO5gqQ.html&index=3 So complexity-wise, the L ones were are comparable. Multiple engineers per platform, at least 1 months of dev work, often more.

@Tynach

3 жыл бұрын

​@@mrgergelyorosz What I'm having a hard time understanding, is why this complexity translates to a large binary size. If you have a function table for each payment method, with each function handling all possible special edge cases, and you have an average of, say, 50 edge cases and 1000 payment methods... That should still compile down to a handful of megabytes at most. Unless there's something like tons of pre-rendered logos at different resolutions, background images for some of the screens, and so on, it doesn't sound like the sort of thing that would bloat the app up to hundreds of megabytes. Granted, you did say it was about 10-15% of the app's size, so only about 30 to 45 MB.. And that can likely be explained largely by the number of SDKs you had to use. But that only goes so far to explain the app's massive size, and your complexity estimates don't seem to correlate with how much space the feature in question would take (if anything it's an inverse correlation, as 'medium' complexity tended to correlate with using an SDK, which likely abstracted the actual complexity significantly).

Great Video, Gergely. You told that Paytm and UPI SDKs would also be present in app for USA region. I am pretty sure you guys at Uber came across Dynamic Feature Delivery (On Demand Feature Delivery) concept and I think it perfectly suits the problem here. The Dynamic Delivery Package(a smaller apk containing Paytm and UPI code) can be attached to the main Uber app only for Indian users, thus reducing the size of APK for US users. I am pretty sure this was discussed in team meetings but was rejected. I wonder why?

@mrgergelyorosz

3 жыл бұрын

Hi Ramakrishna - it's a good question! First, Dynamic Feature Delivery would not be present on iOS: it's an Android-only feature. Second, PayTM was built well before 2018 (in 2015) and there was no such option. Third, it goes back to the cost/benefit of refactoring something that's working: the owning team would need to decide whether to add support and prioritize this work. The current team might be looking into adding support for this: the PayTM and UPI functionality is being built in Hyderabad by a payments team, to the best of my knowledge. It would probably make sense to start taking advantage of this on Android if you ask me.

Ouch.. Didn't realise the size of the actual mobile application. Thanks for sharing. Architecturally I find a lot of startups really lack in how their idea is going to scale from the get go. This can really hurt going forward, especially with huge growth.

Awesome video. Thanks for sharing

Very cool explanation, thanks a lot.

I think it was quite obvious that Uber is not a simple app. But I'd like to see an explanation from an ex-Instagram mobile engineer and manager for why does it take 211 megabytes.

@dejrand

3 жыл бұрын

It's a lot more complex than you would think aha. On the surface it seems simple but you gotta think about all the new features they added like e-commerce, Reels etc, the og version was probably a 3rd the size.

@zheil9152

3 жыл бұрын

Answer: React Native + E-commerce integrations + Facebook Invasive Tracking Suite (TM)

@ADeeSHUPA

3 жыл бұрын

@@dejrand uP

@heroe1486

3 жыл бұрын

Instinctively I'd think Instagram ( and I haven't used it for years so it's probably exponential ) is way more complex than Uber

For some African countries, including Kenya, where I am at, there’s also flutterwave for mobile payments integration. Thanks for this. Simplicity is indeed the ultimate sophistication.

Really insightful video!

It would be most epic if, from a developers point of view, there would be a single and common implementation (much as it can be) payment SDK for each language the banks, credit card companies, the "Uber credits" creator, and community create and maintain in open-source fashion. Choose which to include on a project by project basis

@mrgergelyorosz

3 жыл бұрын

I had similar ideas... then I started to work on payments, got to understand the industry dynamics (banks, gateways, payment service providers, fraud, the cost structures, the regional differences, the national interests) and I now don't think this will ever happen. UPI in India (a government mandated setup) is the closest thing to this: but it will stay within India (the nature of payments and countries being often tied together). And even in India, UPI is just one of many payments you need to integrate.

Making a big and complex app seem small and simple is a very difficult and remarkable achievement indeed. I think you really need to have solid experience to really understand how all the edge cases may increase complexity in almost an exponential fashion

You may put an SDK at “medium”, but in all likelihood the code they’re giving you is massive and the actual complexity is already abstracted away!

so... this just screams for universal payment method world wide

@oriyomilana

3 жыл бұрын

Here is your chance to change the world! ... for the better

Is there not a library that can handle making most of those transaction types for different countries all packaged into one tool? If not, seems like a good business idea considering how many international companies could use that library instead of creating all of those integrations on their own

@SimonBuchanNz

3 жыл бұрын

In theory, the platform's payment API.

@shashankshekhar8970

3 жыл бұрын

Isnt thats what Stripe is trying to achieve? Damn, we missed out on a billion dollar idea 😂

@dinkleberg794

3 жыл бұрын

@@shashankshekhar8970 I thought stripe only handle credit card payments? Not all those different payments for different countries

@dinkleberg794

3 жыл бұрын

@@SimonBuchanNz Yea exactly but every company in theory is making their own payments API. Why doesnt one of these companies package that API and sell it to other companies?

@SimonBuchanNz

3 жыл бұрын

@@dinkleberg794 presumably because it's only a concern if you're big enough, and not big enough to not be worth doing for a company that size to make it work in the UX of the rest of their application.

thanks for the explanation, it's been very clear and helpful

Just a small question... 1) Why don't Uber uses WebView for payments it will reduce the size of the app drastically and make it perform better. 2) Why don't deployment country specific app store? 3) WebView will also make it dynamic and any payment mode can be removed and added.

@mrgergelyorosz

3 жыл бұрын

See my pinned response for more details. 1. Performance (low bandwidth use cases, rendering). Every delay on the main flow impacts people using the app. 2. a)Confusion among the most valuable segment: travelers. Can you imagine someone having 4 different Uber apps on their phones? b) Cost to maintain. For every app, the maintanence cost goes up (aka have to hire more engineers etc) 3. You (or anyone else) can use m.Uber.com if app size is an issue. All web based. 4. Other constraints and data I cannot talk about. All size is just one of the very many tradeoffs a company like Uber needs to care about.

@theflutterfoundry3242

3 жыл бұрын

@@mrgergelyorosz Thankyou for clearing out these doubt! You helped me to not repeat these small mistakes in future! May be these learning could bring more better solution! ❤️

The requirement for the SDKs is one thing... but I would argue it's downright irresponsible for the providers of the the SDKs let them get anywhere remotely as large as they are each. The actual functionality they each provide has no reason being so bulky besides lazy engineering. I suspect they each don't see it as their problem if the SDK they provide is a little unnecessarily bulky, and really it wouldn't be a big deal for an app just using that one SDK... but once an app starts needing a bunch of payment SDKs you really start getting into a tragedy of the commons, where each SDK vendor sees it it as "free" to use up a few MBs here and there, but it all adds up fast.

@biged3175

3 жыл бұрын

SDKs are an integral part of the overall authentication process. SDK has the ability to: Provide a resolution through the means of remote access to the servers. Integrate regular expressions in SKU (networking) with the newline (added) ability to parse different operands into a junction tuple, outputting a natural number reference into the file management server. And Inherit commands through the DOT Matrix, following a bespoke clock-cycle and eliminating the potential for cryptography data mining, finally enabling the logic gate by default for the sole purpose of providing multiplatform micron transactions within the app. It's really as simple as it sounds.

Awesome video! Can you please do a video on the delivery train for the uber app? From writing the code to releasing to the app store I'm really curious what the process is like for an app like Uber!

depending upon the user location one can load on demand payments page with webview will be good idea? there might be hickups to load xhr request but that can cached

Seems like every user will be holding a subset that is not applicable to them. I.e. US users are not going to use the PayTM integration. Is there a good reason why downloading this packages needed for a country ad hoc would be a bad idea?

@mrgergelyorosz

3 жыл бұрын

Good question! With iOS, you cannot download native code: it goes against Apple’s policies. For Android, you could technically do it. It would add delays to users, and technical complexity both to build and maintain to the engineering team, with more edge cases to cover. And then Android would work different to iOS. And PayTM would need to support this (they currently don’t). Keep in mind you’d want to do this if the size “pain” is bigger than the engineering cost. I no longer worn at Uber, but I assume this is not the case today. As an alternative, there is an Uber Lite app in countries with limited bandwidth for Android: its 5MB, has more limited features (eg no map, not all payment types) and uses much of the mobile web. And on iOS, m.Uber.com is a lightweight alternative.

@williamrutherford553

3 жыл бұрын

Are most US users going to use PayTM? Probably not. But if you download the app in the US, and then travel abroad, you NEED that functionality to still work. Imagine landing in an airport in a completely different country, and you can't call and uber until you download 100s of MB of local data. That's a huge inconvenience.

@user-st7ic1tw3q

3 жыл бұрын

@@williamrutherford553 exactly bad business decision on Uber side. Why end user should care about local payment systems or higher local commissions or any other differences? Payment in local to you payment system to Uber. Backend payment in background with local payment providers.

@SimonBuchanNz

3 жыл бұрын

@@user-st7ic1tw3q why is it a bad business decision? The app works fine, hardly anyone cares about it being 300MB vs 20MB, let alone a more realistic 200MB, and they can spend the developer time on more important things.

@meneldal

3 жыл бұрын

@@williamrutherford553 Actually you won't need it if you're from the US, because you won't have Indian credit cards or payment methods.

How shifting logics to backend will suffer UX for an online app? Or is it just saving server cost?

But why are all the SDK's in the app? I get that they are use-cases that need to be handled. But why aren't all the payment SDK's on the backend? It could be very naïve on my part, I do web-apps but mostly backend work, and I've never worked on mobile. Wouldn't it be better to keep all third-party stuff on the server so you could keep the SDK's up to date without having to update the app?

@Nysco83

3 жыл бұрын

I'm struggling to word my question succinctly. But I guess I assumed that if I knew what calls to make, that I could request an Uber with Postman via the Uber API. So my assumption would be that all the app needs is the layout and visual resources to make an Uber-specific, user-friendly version of Postman. I'm really surprised how smart the app itself is expected to be.

@mrgergelyorosz

3 жыл бұрын

There’s a few different reasons: 1. UX. Much of the SDKs of eg PayPal or UPI make for a smoother payments experience. Things like images are preloaded, and the UI is tailored to the OS. 2. Fraud. An SDK can gather (far!) more signals to prevent fraudulent payments. 3. Processor contracts. Many PSPs will offer better rates when they can reduce fraud: so when you use their SDKs. Goes back to point 2. 4. Analytics. An SDK can collect far more analytics for the PSP, and eg detect crashes or freezes. A web component cannot do this in a native app. 5. Far more work to build a decent “native” flow without an SDK. Most PSPs provide APIs or web checkout flows. However, if eg Uber was to use this, they’d need to both build, then maintain this experience... that the PSP provides as their SDK. Most of the reasons are #3 that is based on #2 or #4. Sometimes #5 or #1. On the web, you most likely use “SDKs” if you add online payments: but they could be hidden behind a link or bundled in an iFrame.

How come now when I checked the app is 61 MB as reported by the play store? What sort of optimizations do you think are done I'm especially wondering how you're handling the case for travellers using it at airports - offline, multi-country, etc. Do you predict their travels and download the "plugins" needed or is offline not that big of a deal these days?

@renatocron

3 жыл бұрын

the size of the app on play store can be different from the apk, because play store can cache some parts shared across the apps depending on how the app was uploaded (and a lot of things, like android version) but basically the play store try to only download missing parts and then build a local version to match the uploaded image

I worked on payment and billing system which processes transactions with more than 180+ payment mechanisms. I can tell you, the complexity of payment systems can be really daunting.

Excellent explanation mate.

I am new to Domain Driven Design... your explanation of problem domain well fits DDD solution... i am just curious if the uber app development is based on DDD for such a scale or are they managing using RIBS?

Great video! Subscribed! (Also looking for tips for mobile engineers to get better)

I can see why they didn't move more stuff to server-side. Cause of different internet speeds around the world. Also, if you want to conquer the world with an app it must support all kind of unnecessary stuff. If only our world was more standardised. We need to work on that.

Hi i've a question so how did the engineering team test the integrations with india or brazil payment services, do they even allow access to these payment services outside of their own country and also did you think about creating separate applications for different countries or continents ? What was the tradeoff in that scenario

@mrgergelyorosz

3 жыл бұрын

We tested with either test cards (if we had access to them) or the local ops team helped. Creating separate applications would be a LOT of engineering resources, would confuse people, and it would hurt the segment who travels frequently (an important part of Uber). It basically means hire a lot more engineers and result in more customer support (hire most customer support people) and less revenue (international travelers who forget to download an app might not see local & tailored features). By the way, there is a “localised” Uber app in a few countries called Uber Lite for Android. It’s a very small app, in a few countries like India.

@ahmetakil787

3 жыл бұрын

@@mrgergelyorosz thanks for the response

Well, why not modularize the payment part to enable or disable them as you need, and then being able to free space based on the module you choose to keep?

This video is great. What are you using to write?

So two questions: Why dont you ship different versions of the app which i can update whenever needed? I assume other apps on my phone will use the same sdks - for example regarding paypal payment. Why cant these apps share the paypal sdk?

No matter how complex your code is, it's unlikely ever to take up 300mb of COMPRESSED file size because code compress really well. Open the app package and do a quick look on what's taking up the most space, and it's usually resource files that don't have enough repeated data pattern for compression to work well.

@Winnetou17

3 жыл бұрын

Code compresses really well ? Are you sure ? Do you have a source for that ?

@thelight3112

3 жыл бұрын

@@Winnetou17 The linux kernel is millions of lines of code, and it compiles down a few megabytes.

Great explanation video!

@mrgergelyorosz

3 жыл бұрын

Thanks, Henry!

I am not an expert but can't these be done on the sever? or a constant TCP connect

@mrgergelyorosz

3 жыл бұрын

AFAIK Uber is moving aways from TCP due to performance issues with low connectivity and is moving to QUIC. Here's an in-depth article on why: eng.uber.com/employing-quic-protocol/

As someone who drives for UE, I must say the code base must not be very functional (as it should be for production code, that is) simply based off the pattern of errors from my side of the app. Also, they have a weird way of routing you to addresses. I think they base it on a previous direction and then assume you will go that way, that way we don't do u-turns in people's driveways lol

Payment methods may have been implemented as app bundles (at least on Android). This would make the app size really small initially and just grow as the user chooses different payment methods.

@TheRbray

3 жыл бұрын

Right? First thing I thought was to define something to pull a payment set per region or payment method. Additionally, couldn't much of it couldn't live server-side?

@myothersoul1953

3 жыл бұрын

@@TheRbray It probably could live server side but that's not what is important. What is important is how Uber structures things. Server side uber pays, client side the client pays so better to put it in a huge app than to pay AWS.

Amazing man. Thx!

I wonder what would you do next after having working in the payments team in Uber. I think you have enough experience to found an FinTech startup. If I were to start one would love to have you onboard as CTO or at least as a consultant :)

Yes, but each of these pages can be done in like 20kB, Fraud protection should be provided by the platform, and only god hope that UberEats integration doesn't require to pull half of UberEats into the program

@flobbie87

3 жыл бұрын

Exactly. So why are all these apps so big?

@Nors2Ka

3 жыл бұрын

@@flobbie87 They're written using 10 different frameworks, using OOP and architectural decisions are split among 100 different people, because you can't have a webapp without fewer than 100 engineers.

@mihailmojsoski4202

3 жыл бұрын

@@Nors2Ka OOP on it's own shouldn't increase the compiled code size by a lot, the RAM usage tho..

I agree with Alexandre. Business logic complexity is only partially relevant to the app size. The main issue is Swift, which produces very large binaries with a lot of debug symbols. Android with it's Java/Kotlin code suffers from it too. The same backend app could weight 200+ mb (app+runtime) in Java and 10 mb in Rust. All for the easiness, observability and debugging.

Hi Gergely! Google store has a limit for 100mb app size right? Did Uber need special permission to upload an app larger than that?

@AlienatedBronze

3 жыл бұрын

It shows as 57mb for me, not sure about later versions

Loved this video Gergely, nice job!

Surely it would make sense to handle more of the payment stuff server side?

Which is more complicated, building this complexity or maintaining it?

Great video!

Can't we just install an update package for our region, or where we are receiving too.

@shashankshekhar8970

3 жыл бұрын

Additional complexity when you are moving out of the country. Also would need separate maintenance In all my international trips I have been amazed by how easily the Uber app adjusts to the new country and the location specific features

@myothersoul1953

3 жыл бұрын

@@shashankshekhar8970 Easy for you because the cost is hidden to you. The cost being the resources required on every device the app is installed on. Hidden because your device can handle it.

Awesome insights

Can the app update its code based on the country it is being used in?

Awesome video!

So on Android the app is 59 MB, I noticed most apps on Android are smaller. Do you know why?

@blueblackphantom3839

3 жыл бұрын

Only the apk size is 59MB. After you install it, it increases to around 250mb. Apks are compressed while files on Apple app store aren't. That's what i think.

Why not detecting user country when downloading the App and having some regional versions that support payment methods for just those regions?

@RB-cs5dw

3 жыл бұрын

Cause people travel, then they would have to keep updating all the time

I alway asked myself this question, thanks for answer it.

The Google Play and Apple App Store should definitely allow localized applications to save storage on the end user's phone.

@mrgergelyorosz

3 жыл бұрын

Google has done many optimisations for app sizes, and now supports Dynamic Delivery (developer.android.com/codelabs/on-demand-dynamic-delivery#0) Apple has done nothing similar and Swift-based apps are multiple times the binary size as Objective-C. It’s probably because storage is far more of an issue with Android than it is with iOS.

@ImaskarDono

2 жыл бұрын

@@mrgergelyorosz that's becasue excessive storage on iPhones brings good revenue ;)

Why don't the app ship from google play store with the bare minimum and in the first start it downloads the local pieces of software for the user's specific country? It doesn't makes sense to have code that will only run in india if I am in europe!

@mieloper1942

3 жыл бұрын

The versioning would make it high complexity with much recurring work generated.

Wait, how do they implement all these different payment methods in the app? If it's on iOS, they have to use Apple's in-app purchases, right? (same for Android)

@mrgergelyorosz

3 жыл бұрын

No. IAP is for digital goods only. Deliveroo, Doordash, Airbnb, Lyft, Uber and other apps where you buy a physical thing (eg food delivered, transport) you cannot use IAP and need to build it yourself. Read the App Store Guidelines: “11.3 Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected”

Did I miss something or why didn’t they use something like Braintree to implement payments easier? They almost have all the payments you listed in the video and I’m a little bit confused

How much data collection is going on with that app? I would have thought half the app would be related to that.

Why not fetch components as needed?

Could all these country specific systems be separated into modules/packages? So if you're downloading the app in Brazil for example, it downloads the main app, and then the app downloads only the Brazilian package.

@Winnetou17

3 жыл бұрын

I was thinking the same thing! If the user is far from India and downloads Uber, can't it be without ALL that India-related things ? And say you somewhere "hey, if you go to India you need to download this module/expansion/DLC/whatever"

@Linck192

3 жыл бұрын

@@Winnetou17 Actually I read another comment later about it. They can't do that because iOS does not allow apps to download native content

@Winnetou17

3 жыл бұрын

@@Linck192 Oh, interesting, didn't knew that. Thanks for the reply!

@DanielFenandes

3 жыл бұрын

That is a really bad idea. Can you imagine being in Brazil and going to Europe just to find out that you have to download a new app just for getting picked at the airport ? Really bad user experience

@Linck192

3 жыл бұрын

@@DanielFenandes If the modules architecture was possible, I think that would be a somewhat solvable problem. You could have the app automatically download the required packages in the background when its near some place that might require it

I would have hoped that payment would be a platform-supplied common library, so *all* apps that sell stuff can just call it.

Stripe SDK can reduce a lot of the budle size in the app

Almost all the business complex logic, credit cards validations and edge cases like calling other external web services will be concurrently handled by a robust backend implementation usually in java so the mobile sdk code just need to render the data with some moderate complexity like designing it's service layers. The intent of this explanation was we still do not need that large size app unless Uber doing more granularity in the app itself like caching data into device database for off network situations etc.

Ah, interesting. I work with multiple versions of Microsoft Dynamics, and for localization, it happens the same thing for the most part.

5:45 kinda explains why some debit cards don't work on all apps here in Brazil. For instance, my debit card from bank A works on app X but not app Y. Seems that's because there's some additional work you need to do for each back - and not all apps will have implemented that for a specific back? I think we also call debit cards with this functionality pre-paid credit cards. If you were still on Uber I'd ask you to talk to your team about implementing the credits payment correctly lol it literally happens all the time, I have enough credits to cover a ride or eats order, I select "use credit", they're charged but my default credit card is also charged, so I'm charged twice. I used to email support and they'd say wait you'll be reimbursed which I always end up being, nowadays I just know I'll be double charged and just wait for the reimbursement on my credit card lmao. Another payment method they'll soon need to implement and integrate is PIX, it's a new payment system in Brazil and it's kinda a big deal. Btw I'm SWE myself maybe I could implement that :P hire me.

I thought Elon only worked at PayPal Great video

@miklov

3 жыл бұрын

@Chad Rosswick No, it was founded by Max Levchin, Peter Thiel, and Luke Nosek as Confinity. One merge and name change later it became PayPal.

@randyswagmonster499

3 жыл бұрын

@@miklov It doesn’t make any sense to say Thiel and Levchin founded PayPal when not giving Elon Musk credit. PayPal is the result of the merger between Confinity and X.com making the founders of *both* companies legitimate founders of PayPal

Is the app built with React Native?

Why does Uber need to pre-bundle all the SDK's with the app ? Just download the integrations on the fly, when needed, requested or based on geolocation. This seems feasible, though probably with it's own challenges.

Does Uber use a payment gateway like Stripe?

What is the size of the binary itself?

But why does this only affect iOS app and not the android one? All these features that you talked about seem to be on both iOS as well as android but still android app is very small compared to the iOS one. I remember reading a twitter thread by someone who also worked on uber about how changing iOS app from C# to Swift caused all the issues and is the real reason why iOS app is ridiculously large.

I have a question, if my hobby is coding, am i a programmer? its because you don't need a title to sell bread, but u need it to sell jewels? im not sure when you become a pogrammer. Because Oracle,Microsoft says so?

@Winnetou17

3 жыл бұрын

Easy, two checks, at least one has to be true: - a) have you programmed something non-trivial that can be shown to someone else ? (Like having a project on GitHub, or an executable, or a pull request on GitHub. For the project/executable preferably something that has been used by someone else, or by you in some task that can also be shown. And for the pull request(s) preferably at least one that was accepted) or - b) have you been paid for programming something ? If the answer is yes to either of these questions, then you can say you're a programmer. If not, then I guess it's up to you, but the opinion of other people might differ :)

Although the payment logic seems complex, I'm not sure why it bloats the binary size so much. How many extra kbs of code do you need for an extra if-else condition?

@ritwik5774

3 жыл бұрын

not sure whether you're trolling or don't really know much about external SDKs.

@Chaphasilor

3 жыл бұрын

@@ritwik5774 From what I've seen (I didn't watch the whole video), most integrations were custom ones, and not an SDK. So I do wonder about the size as well...

SDK's lul. Perhaps that stuff should be handled on the webserver instead of on the client. And they should communicate through a common interface like a subset of HTML.

@MrC0MPUT3R

3 жыл бұрын

As a dev who works with payments at another company, that's the dream, but it's not feasible for numerous reasons. For the US the main issue is PCI compliance. Many times you CANNOT take payment details on your backend without spending a lot of time and money to make sure your entire app is compliant with PCI. By far the cheapest, easiest, and fastest way to do things is to use a payment processor who provide ways to process payments without your code ever seeing things like the credit card number, bank account number, etc. Not sure if Uber processes their own payments or not, but I'm sure different countries have their own regulations that complicate things further.

@SimonBuchanNz

3 жыл бұрын

Serving general UI (that doesn't suck) turns out to be really really hard after the first prototype, especially on mobile. Feel free to try though! At worst the attempt will lead to a better understanding of how to factor UX code.

@biged3175

3 жыл бұрын

Well yes but technically no. Ethical web server communications strictly prohibit the use of HTML protocols being treated as a subset. For this to work, you will need to implement JS with the help of Node thus forming an internal-external link, modifying the baseband behaviour of the mask id and fullfilling the requirement to load a terminal server handshake in order to partition the localhost probability into a working command. Simple.

@SimonBuchanNz

3 жыл бұрын

@@biged3175 This is a quality shitpost. 👍

@Cyberfoxxy

3 жыл бұрын

Speak English.

Back of envelope: let's say there are ~50 large complexity services, each with ~1000 files, each with ~100 lines of code, each with ~50 characters per line. Each character is ~1 byte. Multiply it all out, 250 MB in pure source-code. Not sure how source-code translates to app size though

@SimonBuchanNz

3 жыл бұрын

Depends on the language, code style, and, largely, libraries used. To give a very rough idea, though, total source code tends to about 1-10× bitcode.

Why is it only 60mb in android??

I wonder if a lightweight version is possible, with reduced functionality and more offloaded to the server and maybe some parts being purely web based. For people whose devices revolt against huge apps, but who are not bandwidth constrained, for example because they're always in the same geographical region because no money for travel :D I do expect the storage consumption of some of the bulkier apps is down to bugs, like when Discord accumulates 800MB of data which is not cache and cannot be automatically cleared out by device, so you need to reset the app and re-log-in, now that's annoying. And i keep wondering which parts of the app could be trimmed and at what compromises.

@mrgergelyorosz

3 жыл бұрын

Yes there is one! Uber Lite, a 5MB version: www.uber.com/us/en/u/uber-lite-app/

@SianaGearz

3 жыл бұрын

@@mrgergelyorosz huh "This app is not available for your device" Android 5.1. I guess i should start looking around for something newer.

How did they manage to publish an app > 100mb in size on the play store? Do they download the libs later on? Serious question.

@bogicvujadinovic772

3 жыл бұрын

I mean download file for some games is 2-3gb,and uber as a package is 60mb,I believe every app uses a compression mechanism, and during the installation files are being extracted

@unauthorizedaccess8062

3 жыл бұрын

@@bogicvujadinovic772 Games typically use expansion files which are multimedia assets for the most part viz a viz libs sdks etc which are integrated during development and are added to the apk. Hence the question. Edit: just checked the size of uber app on play store, its 60mb. So not sure if he is talking about post install/update size.

I wonder how many things could be removed from the app and placed directly on the backend instead…

Watched the first part, couldn’t get my head around the fact that we went to the moon with 72KB of program data, yet we need to store a whole web server on our phone for a taxi app. Why not make Uber a web app, it doesn’t work anyway without internet... why do I need to host the web site on my own phone just to call a cab? I guess that’s part of how the demand for larger capacities in phones is made.

@mrgergelyorosz

3 жыл бұрын

Uber works fine on the web and has done so for man years. For anyone who doesn't want to download the app, just use m.uber.com/ . A team works on this fulltime with many neat optimizations: eng.uber.com/m-uber/ The web app is at 50kB and it works on 2G networks as well. A lot more details in the article eng.uber.com/m-uber/ . Uber builds apps as people expect these and the majority of people would not think of "searching" for Uber like this. You kind of proved this point, asking for Uber on the web, not realising it's there already, at a size smaller than what we went to the moon with :)

@vali20vali20vali20

3 жыл бұрын

@@mrgergelyorosz It’s even worse maybe, like, I don’t use Uber, I usually walk/bike/drive myself if it doesn’t involve drinking any alcohol. A lot of my friends do, they’re a bit brainwashed if I may say, and that’s how I know about it. Indeed, most complain about the size of the app. Anyway, wouldn’t a web wrapper work better? I think web technologies these days are pretty capable in terms of responsiveness, animations etc, and the phones are pretty beefy specs wise that rendering a fairly complex web page is not a problem anymore. But maybe yeah, Google/Apple want to push something that feels ‘native’ ahead so that they lock the vendors in, I am sure they don’t like an open platform like the web as that means there is space for new contenders in the smartphone ecosystems field. Thanks for the reply and taking the time to read, by the way.

@mrgergelyorosz

3 жыл бұрын

​@@vali20vali20vali20 a lot of people watching this video assume that the app size is the most important thing for users. I cannot reveal specific data, but Uber has done tons of measurements on how important the app size really is vs things like 100ms decrease in load times. The data showed performance & features were far more important. Every app needs to decide if they want to spend time optimizing size, building features, ensuring performance is great on even old devices etc. As shocking as it might be most iOS users don't really care about app sizes (and those who do can pin m.uber.com on their home page - some people actually do!). And neither does Apple (the way apps are packaged in a bloated format compared to Android, and the lack of e.g. dynamic delivery features Google built all prove this).

@vali20vali20vali20

3 жыл бұрын

@@mrgergelyorosz Okay, interesting, makes sense. Thanks for the information.

@Gabriel-ms6qw

3 жыл бұрын

@@mrgergelyorosz Yea, we use Cordova for our mobile apps because we are a small team and the app is pretty slow (especially on low end mobiles). I can't imagine how laggy something like Uber would be

I’m glad that this video was not titled as Why is The Uber App So Large?? "as a millionaire"

They could learn from mobile game companies and start shipping in-app updates for country specific things. Whatever the reasons Uber has, from customer's side its just not important and the app is bloated. Population that moves across regions would simply have to download an in-app update.

This is not very reasonable if you ask me! They could create a service and manage all these different methods on the Uber's server and then expose a standard/universal/unified interface for the client to use. I don't see any reason as to why this had to be implemented like this

Why all these SDKs and complexities are not handled by the back end?

@SweatySockGaming

3 жыл бұрын

He commented about it on a few comments already