Working on a ReactNative App lately. One question that comes up is what devices would be supported.
first a tangent about supported browser strategy
This overlapped in the browser land with this Twitter thread I came upon. I wonder what our real stats are on IE11? How much we can those numbers be trusted really? Prompted by some sessions at the Google developer conference I had been looking into shipping in modern JS instead of having babel inserting polyfills in production bundles, and this pertains to that. One thing suggested was only shipping polyfills to the browsers that need it. There are webpack plugins that can help with that, but what if >98% of our users don’t need those polyfills at all. What is the risk involved with just completely moving to ES2017 and forgetting all about the old browsers at this point? And along with that what then is the major benefit of webpack. Does moving to more modern js very much coincide with moving to using ESmodules and the jump to simpler packager tools like Snowpack or Vite where we could get the awesome hot module reloading stuff…
Ok Back to the mobile device strategy Here is the gist of the strategy we are looking at adopting.
Apple:
Apple is the simpler case. Basically we’ll go for any devices that support the latest version of iOS or iPadOS. This ends up covering a rather large range of hardware, the set of which changes over time with new releases, but the nice thing is that this list at any given time is pretty clear given it is completely determined by Apple.
iPad
We will plan to release to the iPad app store as well as the iPhone app store. However, because of current market analytics data where it doesn’t look like we have a very significant iPad user base as compared to iPhone, we will not be doing much/any customization for the iPad version as compared to the iPhone version. This may be considered a sort of tier 2 support. iPad should work, but at least in the short term we are not going to be addressing iPad specific functionality or optimizations.
MacOS
New macs support installing mobile apps from the store, most should just work, so we shouldn’t need to block it from being installed (which is an option?), but bugs or issues that support gets on this would be tier 2 or 3 territory - interesting, and maybe it exposes something less than ideal about the app that would be good to fix for the real iOS anyway, but it won’t be a priority for us.
Apple Watch
Nope
Android:
Android is a much more nuanced situation in some ways it is similar to supported web browsers idea and thus breaking it down into tiers seems like a good approach.
Tier 1: Fully supported
”popular” devices with latest version of android or minus 2 versions. For example if Android is at version 11 we support down to Android 9. Popular is rather subjective on purpose. While we can try to put some more objectiveness to that for support or QA to use internally (devices with more than x number sold in the US etc.) it is probably a losing battle to try to define it to rigidly, and leaving us with the flexibility to consider a troublesome device as a tier 2 feels like a reasonable compromise.
Tier 2: We will consider bug reports on a case by case basis
Fringe devices like most android tablets, flip/fold screens, budget level phones etc. with latest version of android or minus 2 versions.
Tier 3: unsupported but not blocked
Any devices with older or custom versions of android - Fire tablets, ChromeOS laptops that run Android apps etc. We don’t block install from the store (if that is even an option?). So, as long as we don’t know specific reasons that it shouldn’t work - device doesn’t have a camera or some other nonsense - then we consider bugs or other problems that get reported as potentially interesting, but we have no obligation to address them. Customers with these devices would be in “you’re on your own” territory.
Tier 4: actively blocked devices
Unclear if there are devices we would want to do this on. Android 4 tablets (surprisingly still quite a few our there) AndroidTV? Peleton bikes?…