mhussa, you've made some great points in that post. I'll try to answer some from my personal perspective and that of Airplay SDK. Firstly, I'm not surprised to hear your horror story about some other x-platform "solution". There are many bad platforms out there. Airplay SDK is very different though; Airplay apps have already been deployed on over 300 different devices across 7 major OS platforms.
In your intro you say "We can either spend time learning/maturing a single high quality platform (which is what consumers want) or port content to multiple average platforms." I assume the single platform you refer to is Apple's. Obviously the only consumers who want content on that platform are the owners of Apple devices. What about the other 400-500m smartphone owners, i.e. 10x the Apple install base? They want content for their devices, not Apple's. Not all of them will be as app-hungry as your average Apple owner, but the combined opportunity still exceeds the Apple one. Currently the Apple distribution channel is by far the best, but it's also by far the most crowded, and therefore difficult for the developer to get their app noticed.
Now in response to some of your numbered points:
1) Yes you have to learn Airplay's framework. But Airplay's core OS-abstraction APIs are very standard POSIX-like. Airplay supports use of all standard C/C++ libraries also, including STL. Airplay supports OpenKODE, the emerging Khronos standard for OS abstraction. Airplay supports use of OpenGL ES 1.x and OpenGL ES 2.0 directly (for developers who are happy to ignore devices without hardware graphics acceleration; otherwise they are encouraged to use Airplay's own stream-based drawing API, which can fall back to software rendering, e.g. on devices such as Nokia N97).
In porting from Apple to any non-Apple platform, one has to learn the non-Apple framework in question (e.g. Android). There is a strong argument that porting from Apple to Airplay is easier than porting from Apple to any non-Apple platform, given the standard C-nature of Airplay, the quality of the desktop tools, etc.
With regard to testing, I would argue that Airplay's single-ARM-binary approach, together with the structure of app stores today, means developers do not need to test on every single device they are claiming support for. Let me explain. Firstly, using Airplay, the vast majority of your code path is identical ARM instructions across all devices. Our investigations have shown that, for a reasonably complex app, about 98% of the code execution path stays within the Airplay app (and is therefore identical CPU instructions across devices) and only 2% calls through the OS abstraction layer. That means the opportunities for per-OS or per-device bugs are vastly reduced, compared to the traditional method of porting and recompiling within the OS platform SDKs.
Secondly, the app store world today is (thankfully) different from the operator stores of yesterday, in that developers are not obliged to support all-devices-of-nothing. If a developer has a budget only to test on a few “hero” devices, then they are perfectly able to submit the app and flag it as available only for those devices. If the app is successful, the developer can afford to buy in more devices, test, and extend the reach of the app over time. Furthermore, the ability for developers to update apps on the store, and for consumers to get their money back (e.g. Microsoft Marketplace) opens up the opportunity for developers to test on key devices within each OS platform, flag the app as available for ALL devices, and potentially fix any per-device problems only if they get flagged by consumers.
Thirdly, there are some remote-testing solutions out there (e.g DeviceAnywhere, Perfecto Mobile) that are a pretty good way of “smoke testing” an app on any chosen device. Over time we plan to build up relationships with some of these services such that Airplay SDK licencees can use the services at a cost that makes sense.
2) “Are the returns for porting to other devices worth the effort?” Obviously I can’t make any predictions. But the key thing about Airplay SDK is that the developer doesn’t have to place their bets on which OS platform or app store channel will bring them the money. Nobody knows how the hierarchy will pan out; all we know is that Apple will still be No. 1 in 2010 (and probably for a while longer), and that there will be a No.2 and No.3. Once your app is on Airplay SDK, you can deploy to all OS platforms / channels and wait for the market to determine what platforms / channels are successful without incurring risk. That transforms the economics for developers.
3) “If you are fortunate enough to have a super successful product then worry about porting to another platform when it becomes a problem and not before.” That makes some sense, but there is still the issue of what platforms your port to, in what order. See (TWO) above – Airplay SDK means that you don’t have to worry about this. Also, if your app isn’t successful on the iTunes Store, doesn’t mean it can’t find success elsewhere. I know developers who are making more money on Android Market than they are on the iTunes Store, because the latter is so crowded.
4) “Do you work to the strengths of one device or stick to an average capability across all targets and hope for the best?” It doesn’t have to be one extreme or the other. Cross-platform does not have to mean lowest-common-denominator. Airplay SDK allows you quickly to write your app so that it works on all devices, then it’s up to the developer how much time they want to spend writing “if/then/else” code to provide optimised user experiences for different platforms. By the way, these optimisations tend to be by form factor (screen resolution, touch/non-touch etc) not by device manufacturer.
5) “Each target device/OS may have quirks which means you'll need to address it in different ways.” The link you provide within the Airplay documentation explains that, with Airplay SDK, you do NOT need to worry about these quirks, provided you follow some very simple guidelines. I quote “There is little that the Airplay application has to do explicitly to enable correct inter-operation with a target device…it is strongly recommended that the Airplay application calls s3eDeviceYield() at least once every 10 milliseconds.” The exhaustive unit-testing of the low-level (Airplay System) APIs on every target device is one of the things that hugely differentiates Airplay SDK from other supposedly cross-platform offerings.
6) “Version controlled source code management for multiple targets can become a challenge.” Airplay SDK is designed to facilitate a single source codebase across all targets. If a developer chooses to make per-form-factor optimisations, nearly all of these can be accommodated through “if/then/else” style codeblocks (the Airplay APIs allow dynamic querying of device form factors). Some developers may choose to use #if blocks sparingly, and create separate ARM binaries for separate SKUs, but this is rarely necessary.
7) Re. targeting ARM and Intel… Airplay SDK has always supported x86. Just select an x86 build configuration, and select Windows as the deployment target.
Hope this is helpful,