I have been thinking and discussing with some folks about platforms. Currently there are two approaches to building a platform. The first is building the runtime environment. The quintessential example is Windows OS. If you build desktop apps you use tools specifically designed for building applications on the Windows OS like Visual Basic, PowerBuilder and C++ with MFC. With the rise of the web and no browser monopoly, developers had to deal with fragmentation of the platform. The developer tools and frameworks began to become the platform. Essentially the tools hid the OS or Browser from the developer. Developers just needed to learn the framework and then deploy where the app would run. The two biggest runtime platforms today are Java and .NET. Java’s write once run everywhere captured developers attention. While Java failed on the GUI front I believe it was an implementation issue not a problem with the paradigm.
As iOS market share erodes and Android continues to fragment, developers need to tackle this problem of write once run everywhere head on. Which brings us back to the question of building a platform. The difference is that you the developer must pick what constitutes the platform. What I mean by platform is you the developer chose the OS or your tools as the platform. Neither choices is better than the other. Rather the choice defines how you develop your app and constraints that might be imposed by your choice.
In choosing the OS as the platform you implicitly or even explicitly are saying your app fully support an OS. When a feature is evaluated one of the question is does the target OS(es) support the feature. Developers don’t think do my tools support the feature. Typically developer tools are tools created by the OS vendor for example .NET for Windows, Xcode for Apple and Google SDKs for Android/Chrome. Thus when an update to the OS is released, so are the developer tools updated.
The benefit of this approach is that you can develop apps that can do anything that is allowed by the OS. The apps usually perform at the fastest speeds possible on the native OS. They also tend to be small even managed code like .NET or Java as the OS includes the runtime and standard libraries. You can do anything you want unless limited by the OS. As long as you can imagine the app and the OS allows it you can build it.
Even picking to use 3rd party tools for development is more about productivity and less about cross platform. For example if you want part of your web site to run on a disconnected mobile device PhoneGap is a natural choice to rapidly get an app out to your users. Another example is I know C# inside and out so picking MonoTouch by Xamarin makes perfect sense as my learning curve is reduced.
Not everything is perfect in OS land. You can find yourself raising your development costs exponentially the moment you need to support multiple OSes or in some cases like Android multiple flavors. It is uncommon for a iOS native developer to also be able to build the same quality and productivity level in Android or Windows. Even if you can find such staff a bug in one version may or may not exist in another OS version. So development costs tend to be much higher either due to multiple OS specific teams or the need for checking all OS versions. In addition users on one platform may feel slighted if there version is not as feature rich as other OS versions.
A variant of the OS as the platform is browser as the platform. In choosing browser as the platform you are making HTML and related technologies the platform. In this model you are making a decision to only support HTML standards. Thus if the web allows it you can do it but you are not fully supporting the OS. This is an important distinction as browsers are not 100% compatible. In addition the HTML5 standard is not final and already newer versions are being drafted. Thus when building for HTML you need to ask can the feature be built using HTML.
The benefit is that you can build upon existing HTML apps and sites. Do not underestimate the value of re-use. You team is building to the web and just adding additional functionality, form factor and testing. Yes I am understating the amount of work but in the name of highlighting your teams skill set is still very relevant. You still may cut the teams into specific browser teams but the core skill sets are the same. In addition just because a new device, device type or mobile OS comes out does not mean you build a new app. However keep in mind that your apps are limited to what you can envision in HTML.
HTML is the main draw back to this approach. HTML and related technologies are not bad but they do define the limits of what can be accomplished. HTML is neutral and thus caters to the lowest common denominator. Thus new features in devices will appear first in native apps and later in HTML once the standard catches up. If you are building cutting edge apps HTML may not be for you however a lot of developers will not find HTML a barrier.
In choosing your development tool as the platform you implicitly or explicitly saying your app only supports what the development toolset can support. When a feature is evaluated one of the question is can the tool build the feature. It is a subtle but distinct difference. PhoneGap allows you to make calls but fully utilizing the new iPhone 5s motion co-processor is limited. Typically the tools are built to be cross platform. Depending on the approach the tools can be limited to basically the same as writing native apps. Examples are Xamarin with its .NET based tooling, PhoneGap and Titanium.
The benefit is primarily in easing the pain in writing multiple versions of the same app to run on different target devices. The tools can be a single code base that targets multiple devices to a set of code that includes shared and device specific code. The reasons for using such tools are varied but usually fall in the ability to have your team efficiently build multiple apps.
In choosing your tools as the platform you need to consider
- Tool limitations for example PhoneGap uses HTML for UI and exposes common device functions. This means your users see a non-native UI and only have limited access to functions exposable to PhoneGap. Questions in using PhoneGap might be is the device functionality sufficient? Will users notice that the UX may not be native? Other tools have their own issues. Thus know them and your current and future requirements can lead to a better decision and outcomes.
- Vendor lock for example will the vendor be around in several years. Picking a 3rd party Does the vendor have the resources to cover all your target platforms and to the same level of features?
There is no one right answer. All three above platforms can be used to successfully build apps for your target users and devices. The big thing is to pick a platform and understand the limits of that platform. It could mean the difference between a successful startup or blowing up your IT budget.