There's also the problem of ongoing maintenance on multiple platforms. In the best case, it was written with a dual platform toolkit (iOS and Android) and MS adds a 3rd platform to that toolkit to make it easy to port and maintain all three. Even if that were all true, it's won't be for every developer and you'll still have problems bringing people to the platform.
2) Built in Objective-C with a custom audio engine in C++. Audio latency on Android was horrible at that time, MS was probably worse. It would have been a terrible app on those platforms if I did port it. This was before cross-platform toolkits existed. It needed to be a native app with low level access audio to hardware. I wasn't going to make an app where you tap a drum and wait 100ms to hear a sound.
Not that this counters anything you said nor that relevant to this topic, but as a nerd I am genuinely curious if this was true. I used to write lowlat audio stuff for iOS so I was well aware of the situation Android vs iOS (and because of my large interest in audio Android in general always makes me puke in my mouth a little -- like it is one of those neat little hidden indicators that while Apple is a hardware company, Google is fundamentally an ad company -- they really don't give a shit other than prioritizing ad delivery).
Anyway, Windows itself obviously has solid low-lat audio services, was it really that bad in the mobile stuff?