As previously stated, the market share numbers are misleading. Apple always comes out on top because they own the expensive (fashionable) sector of the market. If you look at the number of devices, it’s a very different picture. Android owns the bottom and the middle, and is eating bits of Apple’s lunch at the top too (look at the $1000 Android phones which arguably have the best cameras of all phones, and let’s face it, it is the camera which drives that market).
Whether an aviation app developer should spend time addressing both platforms is a different Q, and choosing just the obvious one is a reasonable decision, though it is a lot more reasonable in the US than in Europe 
because if your objective is to displace the existing players then you must address the platforms in actual use. In the US, FF dominates, and is IOS only.
If I was developing a product to sell in Europe and it involved a phone/tablet app, there is no question we would have to support both. Actually, we would avoid writing an app; we would make it server based and the “app” would run in a browser. Apps are a huge hassle. But this isn’t an option in this case, for performance and other reasons.
Probably not a worthwhile discussion because Jepp are not going to allow their terminal charts to be displayed on an Android app
At my company we have launched a mobile app. When we first developed it, the first thing we looked at was the devices our users own (which we know from when they log in on our website). It was 90% +iOS. So we launched that first, and got endless grief from Android users (“How can you ignore 50% of the market?”), despite 1.saying an Android version would come 2.sharing the 90% stat to explain why we started with iOS. Now we develop on a cross-platform framework (ReactJS) so it’s mainly the testing which takes time; we’re actually starting to “outsource” that to (a self-selected slice of) our users, Apple-style
FWIW, last 2 months’ traffic on EuroGA (anonymous google analytics audience stats)
Of course, this is not the same thing as what people use in the cockpit – unless you are talking about phones or tablets. Windows isn’t going to feature there.
Peter wrote:
Actually, we would avoid writing an app; we would make it server based and the “app” would run in a browser. Apps are a huge hassle. But this isn’t an option in this case, for performance and other reasons.
A huge number of “apps” are nothing more than a thin wrapper around the website anyway, so probably a huge number of “app” writers are already doing this, but for some reason people have an aversion to pinning a website on their phone’s “desktop” so you have to release an app because people will be searching in the App Store or Google Play. So you basically release an app which is essentially just a shortcut to your website. Once WebAssembly gains enough language support, I suspect the days of a native app will be largely in the past (with the exception of things like aviation mapping software which MUST be able to run 100% of the time without an internet connection, and relying on having the web page cached just isn’t good enough – it has to actually be stored on the phone 100% guaranteed, however, this could still be a local JavaScript or WebAssembly program running in a browser)
Also it depends what you mean by “server based”. Many things on the web which aren’t just basic web pages but do “app like things” are often running almost entirely client side in JavaScript (for many reasons, it is a lot more practical to write a complex piece of web software in the good old “client server” manner with the client being written in JavaScript (or something that transpiles to JavaScript), with the server providing a JSON/REST API to the JavaScript client. Writing complex web software in the server only is a royal huge pain in the ass, and I’m glad it’s something that’s largely been left behind).
One reason for server based stuff is that nobody can see the source code, the database, etc.
It can work very well. A good example is the Foreflight web version. I didn’t renew my FF sub and didn’t buy a modern Ipad either (because of lack of support for fly-by waypoints in autorouting) but did have a good play with their web version. It was intentionally missing a load of features relative to the Ipad version (which is a great pity; I much prefer preflight planning on a PC with a decent screen etc) but it did work well in terms of user interface responsiveness. No idea what the architecture was i.e. client/server split.
Does GP have a PC/browser version?
The user interface for something like ForeFlight web version would likely be entirely client side (running in the browser) and written in JS. If the user interface is being generated server side, basically you have to reload the page every time you change something to regenerate the page, which would be very clumsy.
Does GP have a PC/browser version?
Presumably not
No it doesn’t. Doesn’t have a fax or a teletext version, either ;-)
Edit: I actually admire your resistance to an iPad.
What? No fax?
Arrghhh……
