3 ms·
Real world example: One of the app teams I work with has apps for iOS, Android with Google Services, and Android without Google Service (FireOS). The FireOS ap
by asow92 4y ago
Real world example: One of the app teams I work with has apps for iOS, Android with Google Services, and Android without Google Service (FireOS). The FireOS app is behind the Google app and here's what one of the Android devs had to say about it:
"There are a few libraries we use that aren't supported on Amazon, but the big ones are that it doesn't have access to the Google Play store or Google Play Services. Amazon has their own app store and subscription system, which isn't too bad conceptually, but it does require restructuring the subscription code to have a more generic store interface, and implementing that for the Amazon store
Google Play Services is more of a pain. They've become much more integral to Android apps generally since we last updated the Amazon app, and we've also become more heavily dependent on things like Google Analytics/Google Tag Manager. The native APIs for those rely on Google Play Services. The suggestion from Amazon seems to be to use the javascript versions, which I think means creating a dummy webview and invoking javascript through it."
So there is a time cost associated with maintaining this bifurcation which may not match up with the potential return.
Granted, this maintenance may be a one-time investment or can be thought of when designing a new app, but many apps have been around for years at this point and have plenty of baked in assumptions about the OS ecosystem that it's running on.
I'm not saying alternate OSs can't be done, but it will be a hard sell for many app product teams unless engineers add support out of love for the project on their own time.
- palata 4y ago> Google Play Services is more of a pain. They've become much more integral to Android apps generally since we last updated the Amazon app, and we've also become more heavily dependent on things like Google Analytics/Google Tag Manager. Yeah, that's exactly the goal of Google: lock-in. The Play Services are nice, so you use them, and then your users are stuck with Google. You don't really care about the few users who would use your app on a de-googled phone, so in the end, the user is screwed. > So there is a time cost associated with maintaining this bifurcation which may not match up with the potential return. Right. But what I don't get, really, is this: you seem to say that you already support FireOS (which has a cost), and that you can't afford supporting another de-googled Android flavour. But my point is that if it works with FireOS, then it should work on any de-googled Android flavour. Also moving away from the Play Services is definitely hard. Ideally one would not start using them in the first place. For instance many apps use Google Analytics because managers somehow like to look at statistics, but I am convinced that in many case they don't do anything remotely useful with them (except confirming their biases and showing nice graphs in presentations).
- asow92 4y ago>Yeah, that's exactly the goal of Google: lock-in. The Play Services are nice, so you use them, and then your users are stuck with Google. You don't really care about the few users who would use your app on a de-googled phone, so in the end, the user is screwed. Yes. > Right. But what I don't get, really, is this: you seem to say that you already support FireOS (which has a cost), and that you can't afford supporting another de-googled Android flavour. But my point is that if it works with FireOS, then it should work on any de-googled Android flavour. We were approached by Amazon to build a FireOS app in the early days in exchange for prominent featuring back when the Fire Phone was launching, and it hasn't really panned out as valuable since then. > Also moving away from the Play Services is definitely hard. Ideally one would not start using them in the first place. For instance many apps use Google Analytics because managers somehow like to look at statistics, but I am convinced that in many case they don't do anything remotely useful with them (except confirming their biases and showing nice graphs in presentations). Agreed in theory, although actually getting away from that can be harder in practice.
- palata 4y ago> although actually getting away from that can be harder in practice. Sure. A rational company will say "the more profitable way is to reinforce Google's position, so we will do that". At the end of the day, the goal of a company is not to build a nice product, but to make money. If making money means going with the monopoly, so be it. The only way to change it is to make it more profitable for the company to support the alternative. But in this case I can't see how a law could enforce it (how would it even formulate that?), so the monopolies win. That's sad, but that's how it works. That's also precisely why tech is part of the climate change problem and not of the solution: we don't build tech that help the world, we build tech that makes money. And making money means using energy, which means burning fossil fuels. Technology destroys the planet because the rules incentivize it to do so.
- asow92 4y agoI think these points are fair, and we are just following market forces. If a new phone OS suddenly popped up with a ~20-30% market share we would obviously need to support it; we are in the business of building apps and not smart phones or their OS. Begin rambling rant / feel free to not respond to any of this: Imagine for a moment that you are trying to build and distribute something as big as an OS: How would you fund it? Would it be non-profit, state driven, or open-source? Or would it be a for-profit company with for-profit incentives? If it's the latter, market forces will likely dictate lock-in and closed-source development. This isn't necessarily meant to be nefarious to users: it's just how it has to work if it's going to work at all. On the topic of free software / open OS's and user habits in general: Most users don't want to toil in the fields of setting up a custom OS for the sake of privacy or software freedom: The vast majority of users just want a convenient way to check their messages, find restaurants, hotels, and flights, engage with social media, play a casual game, maybe use a niche app or two, and check the news. Users get complacent when they build habits, so if you want users to switch they need a 10x better reason to switch to consider breaking their habit. I don't know how something like /e/OS is going to become popular enough to actually pull it off without government intervention, and then we're just trading one market bully for another. Sure we have examples of privacy focused companies seeing success like Duck Duck Go, but think about how much easier it is for the average user to switch to a new search engine over a phone.