During the days when Blackberry was fighting for its place at the app development table, I met several times with the company's head of developer outreach. An energetic man, he had many views to express, most of which made a lot of sense. There were good reasons to code for the Blackberry platform: It was easier, in some senses, to develop for than other platforms; and users were more willing to pay for BlackBerry apps than for Apple iOS and Android apps, where the notion of "everything should be free" had already taken root.
However, as he clearly articulated one afternoon, none of these benefits meant much if app developers chose to write for the BlackBerry after writing for Android. The dynamic, he explained, went like this: Companies coming out with new apps almost always wrote the iOS app first. This was generally a native app because Apple users are finicky enough that they tend not to be satisfied with apps that don't exactly fit their guidelines.
After writing the iPhone/iPad app, there comes the moment of decision. The worst decision for the #3 player is that the vendor chooses to develop for Android next. Android development is a black hole due to the vast number of form factors and OS versions that must be accommodated. Said the fellow from BlackBerry, organizations don't ever truly exit the Android development process. They keep porting and testing the app on an endless list of devices until they finally decide they've covered enough of them to meet their goals. Only then do they stop porting on Android. In other words, the decision to stop is a purely economic one, rather than the naturally occurring end of project when all desired devices have the app.
After the Android ordeal, the company has already decided that further development of the app to other devices is no longer economically justified. So typically, they do not port to the #3 player. That player was, at the time of these conversations, BlackBerry. Today, it's Microsoft's Windows Phone.
There is, of course, another path vendors or businesses can choose after writing the iOS app. That is to write a multiplatform app, generally using HTML5 and some framework. Such an app can work well enough on Android and the subsidiary platforms that it becomes the overarching multiplatform solution. (In reality, there are often small tweaks made in the product for individual devices, so that minor vendors are still somewhat disfavored.)
The reality is that for vendors outside of the top two spots, this approach is the only path that gives them any hope of ever getting a big enough app ecosystem. For this reason, BlackBerry loudly touted its HTML5 support and Microsoft extols its own support for that strategy.
However, the HTML5 approach underscores the disenchanting but uncompromising reality: If you're not first or second in the mobile race, it really doesn't matter who has the bronze medal, you're in the same boat as all the vendors behind you.