5 ms·

As a mobile developer: The two primary OS ecosystems are already difficult to develop for. And we already kind of have a third if you count Amazon Fire, as the

by asow92 4y ago

As a mobile developer: The two primary OS ecosystems are already difficult to develop for. And we already kind of have a third if you count Amazon Fire, as they run Android without Google services, which creates all kinds of edge cases specific to this OS flavor. What could end up happening is the smaller OS markets would end up getting a lower quality of service because it's hard for product teams to justify the dev and maintenance time investment for smaller user bases. Stretching us thiner than we are will mean a lower quality of service for all app users unless it becomes easier to develop for multiple OS flavors at once. And no, RN and Flutter are not silver bullets here: they come with their own tradeoffs that each team must assess for their product.

palata 4y ago
> And we already kind of have a third if you count Amazon Fire, as they run Android without Google services Genuine question: how is that different than e.g. /e/ OS? It's not like there are tons of alternative Android SDKs. I essentially see this: - iOS - Android with Google Services - Android without Google Services - others Of course you need to support the first two. Apparently you do support the third, which is great. But then I would think that if it works on Amazon Fire without the Google Services, it will work on a de-Googled /e/OS, CalyxOS or GrapheneOS.
- 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.

by asow92 4y ago

palata 4y ago

> And we already kind of have a third if you count Amazon Fire, as they run Android without Google services Genuine question: how is that different than e.g. /e/ OS? It's not like there are tons of alternative Android SDKs. I essentially see this: - iOS - Android with Google Services - Android without Google Services - others Of course you need to support the first two. Apparently you do support the third, which is great. But then I would think that if it works on Amazon Fire without the Google Services, it will work on a de-Googled /e/OS, CalyxOS or GrapheneOS.

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.