They’re basically multiple apps built in to one. I don’t see how there would be an experience difference between going to your home’s phone screen to open a different app vs going to the super-app’s home screen to open a different sub-app.
Like it’s literally just replicating the functionality of the phone’s OS but in a single app. The only possible difference I can see is that the sub-apps are more tightly integrated with one another, but the same is basically true for apps from the phone/OS maker (I’m mainly thinking Apple here since that’s what I have, but I’m sure Android has similar with its built-in apps).
The “4 apps” example is pretty wrong. You can pay someone directly in the iMessage app with Apple Pay, then order from whatever other app (also paying using Apple Pay). They included “your mobile wallet needs to be updated” as if that’s something you have to do every day just to pad the number of apps. In reality it’s two apps, iMessage and the food ordering app. In WeChat it’s probably the same, the messaging sub-app which probably also has the ability to pay someone directly, and the food ordering sub-app. (Although in both situations it would be more efficient for the boss to make the order and just have you pick it up.)
Apple Maps (and I’m sure Google Maps too) also has the ability to compare prices among ride share apps and go directly to the book screen of those apps like she said for Gaode Maps. It can also take you to a restaurant’s page on a food delivery app.
Also, what she says at 3:03 is a pretty bad thing. In the US in most places you can pay with cash, card, and your phone’s built in tap to pay. Everywhere else is just cash and card because they haven’t modernized (or just cash because they’re stingy about paying card processing fees). Being able to pay with cash anywhere is pretty important imo for multiple reasons, privacy being a big one.
I’m chatting with my wife on FB messager. She sends a link to a restaurant I should check out. It opens in FB messenger html wrap-around thingy. I click the 3 dots. Tell it to open in the normal browser because it sucks in the FB messenger thing. It goes to the webpage and I can see the menu. I want to know where it is. I click the link for the map, then click the map to open in Google Maps so I can see where it is. I agree to new user Terms of Service. Now I can see the location. Cool, I can look at reviews, too. Nice. I go to book a reservation which means I need to open back the webpage. It tells me I have to download an app for that so I do that and set up an account and do that to book at this one restaurant because there are about 6 of these kinds of services and there is no telling which restaurant uses which one. Nice, it’s all set. Then I open yet another app to get a ride-share and agree to their new terms of service (love how this seems to happen once a month in each app in the west). Now I can go eat at the restaurant. They take cash or credit but no apple pay/ samsung pay / google pay. Awesome.
So yeah, pretty much the same experience you get in China, I can see where they are 1:1.
EDIT: I have 3 different parking apps on my phone because there is no single one in my city. Depending on where you park it’s a different fucking app. I got to the next city over for something? Cool, download a new fucking parking app.
because there are about 6 of these kinds of services and there is no telling which restaurant uses which one
The same could easily apply in China. Does this restaurant have reservations set up with WeChat? Or do you have to switch to AliPay or something else for it? That’s not a problem solved by super-apps, it’s a problem solved by the maps app (or maps sub-app in the super-app) working with more restaurants. Also, for both reservations and parking, we’re basically talking about which country has a larger monopoly on those services. The fact that you need 3 different parking apps means your city doesn’t having a single parking monopoly.
“Well you are using westernapp, there’s your problem!”
Big brained reply moment.
Look, the point is Google reservation don’t work at all these restaurants. It depends on the restaurant and which of the 6 different app/services they use. You say the same could apply to China and yet your solution is the same for the Chinese apps. Additionally, China could regulate it so all vendors have to be able to use any of these 2 or three apps and could force them all to API integrate with each other. In fact, I would not be surprised to see such a thing in coming years there. Will never happen here.
“Well you are using westernapp, there’s your problem”
I mean Facebook specifically. It’s shit at everything.
You say the same could apply to China and yet your solution is the same for the Chinese apps.
Yeah, because my point is that there’s no difference between a super-app and a tightly integrated phone OS or set of apps for these kinds of things.
Additionally, China could regulate it so all vendors have to be able to use any of these 2 or three apps and could force them all to API integrate with each other. In fact, I would not be surprised to see such a thing in coming years there.
Are they working on that law right now? What has changed recently that makes that more likely than 5-10 years ago?
Interpreting that as requiring open APIs, obviously more open APIs would very much help with that kind of integration, but right now it seems like it’s all based on the creator of the ecosystem (Apple, Google, Tencent, Alibaba) working with individual establishments or more specific apps to offer as much as possible. I’m sure restaurants have a similar process to get fully integrated in Apple or Google Maps as they do to get fully integrated into WeChat or Alipay. The main difference I can see there is the number of restaurants working with those ecosystems, which has nothing to do with whether the ecosystem is a super-app or a set of apps built into an OS.
Interpreting it as requiring restaurants and such to work specifically with WeChat and/or Alipay, that just sounds like granting a legal monopoly/duopoly to those couple of companies. If it were state run that might be great, but Tencent and Alibaba aren’t state run.
Wow I replied to points in a structured manner, how cringe. I had a lot to say on a topic I’m interested in, how embarrassing. I guess my neurodivergence is showing, I’ll try to hide it for you.
The key difference is in the architecture. With the traditional approach, each app is a self contained unit of functionality that slaps its own UI on top. You interact with one app to do one thing, then you have to switch to another to do another, and so on. Crucially, they don’t have any shared context and it’s not possible to compose functionality from different apps together in a meaningful way.
With the WeChat approach, you have a single UI framework, and apps are effectively services that plug into it. Now it’s possible to have a shared context that spans multiple apps, and to pull their functionality into it. It basically facilitates creating workflows that involve multiple apps where each app is a component of the workflow. It’s a similar idea to the way Unix philosophy works where you have a bunch of command line utils and you can pipe data through them in a script composing their individual functionality.
This doesn’t have to be done using a mega app like WeChat, you could bake that into the OS itself, and I think it would actually be a very good architecture to do that. I think that the approach of coupling the UI to the business logic is the wrong way to go. It’s much better to decouple these things, and allow the user to create whatever workflow they want that fits their particular use case leveraging functionality provided by different apps.
Right, I mentioned that you can do this at the OS level in my comment. However, the way iOS does it is not general, it’s something devs have to do on case by case basis. What I’m talking about is the decoupling of the UI from the logic being the default. The OS can present a single unified UI to the user, and the apps just provide service functionality. The app can then add a default view for itself, but the user could adapt it any way they wanted.
I’m not sure I fully understand. Having a pre-made UI would limit what functionality could be implemented. And it sounds like the OS developer making 90% of an app then just letting third parties plug in their back end. Like a white label kind of thing? Or do you mean something more like UIKit/SwiftUI?
No more than the GUI toolkit that the OS already provides. You’d just build UIs like you normally do, and then specify the endpoints that the widgets connect to for the data. The key here is that all apps should be forced to explicitly provide an API layer that the UI component talks to, and that anything you as the user want should be able to talk to that API.
I do too unfortunately. Incidentally, this could even be handled by the GUI toolkit itself since native apps have to rely on it to build the user interface. The toolkit could just automatically generate a JSON API based on that for example.
They’re basically multiple apps built in to one. I don’t see how there would be an experience difference between going to your home’s phone screen to open a different app vs going to the super-app’s home screen to open a different sub-app.
Like it’s literally just replicating the functionality of the phone’s OS but in a single app. The only possible difference I can see is that the sub-apps are more tightly integrated with one another, but the same is basically true for apps from the phone/OS maker (I’m mainly thinking Apple here since that’s what I have, but I’m sure Android has similar with its built-in apps).
The “4 apps” example is pretty wrong. You can pay someone directly in the iMessage app with Apple Pay, then order from whatever other app (also paying using Apple Pay). They included “your mobile wallet needs to be updated” as if that’s something you have to do every day just to pad the number of apps. In reality it’s two apps, iMessage and the food ordering app. In WeChat it’s probably the same, the messaging sub-app which probably also has the ability to pay someone directly, and the food ordering sub-app. (Although in both situations it would be more efficient for the boss to make the order and just have you pick it up.)
Apple Maps (and I’m sure Google Maps too) also has the ability to compare prices among ride share apps and go directly to the book screen of those apps like she said for Gaode Maps. It can also take you to a restaurant’s page on a food delivery app.
Also, what she says at 3:03 is a pretty bad thing. In the US in most places you can pay with cash, card, and your phone’s built in tap to pay. Everywhere else is just cash and card because they haven’t modernized (or just cash because they’re stingy about paying card processing fees). Being able to pay with cash anywhere is pretty important imo for multiple reasons, privacy being a big one.
On standard Android:
I’m chatting with my wife on FB messager. She sends a link to a restaurant I should check out. It opens in FB messenger html wrap-around thingy. I click the 3 dots. Tell it to open in the normal browser because it sucks in the FB messenger thing. It goes to the webpage and I can see the menu. I want to know where it is. I click the link for the map, then click the map to open in Google Maps so I can see where it is. I agree to new user Terms of Service. Now I can see the location. Cool, I can look at reviews, too. Nice. I go to book a reservation which means I need to open back the webpage. It tells me I have to download an app for that so I do that and set up an account and do that to book at this one restaurant because there are about 6 of these kinds of services and there is no telling which restaurant uses which one. Nice, it’s all set. Then I open yet another app to get a ride-share and agree to their new terms of service (love how this seems to happen once a month in each app in the west). Now I can go eat at the restaurant. They take cash or credit but no apple pay/ samsung pay / google pay. Awesome.
So yeah, pretty much the same experience you get in China, I can see where they are 1:1.
EDIT: I have 3 different parking apps on my phone because there is no single one in my city. Depending on where you park it’s a different fucking app. I got to the next city over for something? Cool, download a new fucking parking app.
> Using Facebook
Well there’s your problem.
Instead, your wife can send you the Google Maps link that automatically opens the Google Maps app where you can see reviews, reserve the table and find a convenient shortcut to the ridesharing app. I rarely see terms of service updates.
The same could easily apply in China. Does this restaurant have reservations set up with WeChat? Or do you have to switch to AliPay or something else for it? That’s not a problem solved by super-apps, it’s a problem solved by the maps app (or maps sub-app in the super-app) working with more restaurants. Also, for both reservations and parking, we’re basically talking about which country has a larger monopoly on those services. The fact that you need 3 different parking apps means your city doesn’t having a single parking monopoly.
“Well you are using westernapp, there’s your problem!”
Big brained reply moment.
Look, the point is Google reservation don’t work at all these restaurants. It depends on the restaurant and which of the 6 different app/services they use. You say the same could apply to China and yet your solution is the same for the Chinese apps. Additionally, China could regulate it so all vendors have to be able to use any of these 2 or three apps and could force them all to API integrate with each other. In fact, I would not be surprised to see such a thing in coming years there. Will never happen here.
But keep coping, brother.
I mean Facebook specifically. It’s shit at everything.
Yeah, because my point is that there’s no difference between a super-app and a tightly integrated phone OS or set of apps for these kinds of things.
Are they working on that law right now? What has changed recently that makes that more likely than 5-10 years ago?
Interpreting that as requiring open APIs, obviously more open APIs would very much help with that kind of integration, but right now it seems like it’s all based on the creator of the ecosystem (Apple, Google, Tencent, Alibaba) working with individual establishments or more specific apps to offer as much as possible. I’m sure restaurants have a similar process to get fully integrated in Apple or Google Maps as they do to get fully integrated into WeChat or Alipay. The main difference I can see there is the number of restaurants working with those ecosystems, which has nothing to do with whether the ecosystem is a super-app or a set of apps built into an OS.
Interpreting it as requiring restaurants and such to work specifically with WeChat and/or Alipay, that just sounds like granting a legal monopoly/duopoly to those couple of companies. If it were state run that might be great, but Tencent and Alibaba aren’t state run.
Oh look, the
debate style of quoting things line by line and blasting out a paragraph for each thing. How embarrassing for you. Cope harder, westoid.
Wow I replied to points in a structured manner, how cringe. I had a lot to say on a topic I’m interested in, how embarrassing. I guess my neurodivergence is showing, I’ll try to hide it for you.
Disengage.
Yeah I agree that is the problem, you should do that stuff with Wechat instead
The key difference is in the architecture. With the traditional approach, each app is a self contained unit of functionality that slaps its own UI on top. You interact with one app to do one thing, then you have to switch to another to do another, and so on. Crucially, they don’t have any shared context and it’s not possible to compose functionality from different apps together in a meaningful way.
With the WeChat approach, you have a single UI framework, and apps are effectively services that plug into it. Now it’s possible to have a shared context that spans multiple apps, and to pull their functionality into it. It basically facilitates creating workflows that involve multiple apps where each app is a component of the workflow. It’s a similar idea to the way Unix philosophy works where you have a bunch of command line utils and you can pipe data through them in a script composing their individual functionality.
This doesn’t have to be done using a mega app like WeChat, you could bake that into the OS itself, and I think it would actually be a very good architecture to do that. I think that the approach of coupling the UI to the business logic is the wrong way to go. It’s much better to decouple these things, and allow the user to create whatever workflow they want that fits their particular use case leveraging functionality provided by different apps.
That already exists.
Right, I mentioned that you can do this at the OS level in my comment. However, the way iOS does it is not general, it’s something devs have to do on case by case basis. What I’m talking about is the decoupling of the UI from the logic being the default. The OS can present a single unified UI to the user, and the apps just provide service functionality. The app can then add a default view for itself, but the user could adapt it any way they wanted.
I’m not sure I fully understand. Having a pre-made UI would limit what functionality could be implemented. And it sounds like the OS developer making 90% of an app then just letting third parties plug in their back end. Like a white label kind of thing? Or do you mean something more like UIKit/SwiftUI?
No more than the GUI toolkit that the OS already provides. You’d just build UIs like you normally do, and then specify the endpoints that the widgets connect to for the data. The key here is that all apps should be forced to explicitly provide an API layer that the UI component talks to, and that anything you as the user want should be able to talk to that API.
Ahh, yeah that would be pretty good, but I doubt it would ever happen in the West.
I do too unfortunately. Incidentally, this could even be handled by the GUI toolkit itself since native apps have to rely on it to build the user interface. The toolkit could just automatically generate a JSON API based on that for example.