The most recent sighting of this question came from a blog post on the Vizteck site titled “Phonegap vs Titanium“.
I believe the question should be broadened a little more to consider some additional solutions:
- Mono/Xamarin (C#)
- Rhodes (Ruby)
- Kony (Lua)
For me the question ultimately boils down to:
How should I invest my resources to attain mobile application success?
Since I left Appcelerator to work for StrongLoop, the following question often accompanies the former…
How can StrongLoop contribute to my cross-platform mobile success?
The most challenging aspect of this question is the value these mobile cross-platform tools provided at their inception is not the same today because the requirements for “mobile success” have evolved and the challenges are different.
The evaluation needs to work on assumptions that fit today’s mobile needs in addition to the assumptions that created the initial demand that proliferated cross-platform mobile tools.
To effectively evaluate cross-platform mobile tools in today’s environment it helps to look back to 2010 when Titanium and PhoneGap –the two cross-platform tools with the greatest reach– proliferated.
Mobile in 2010
In 2010, mobile was still at its infancy (some say it still is) and application delivery was mostly focused on finding a programmer that could get your app in the app store.
Mobile cross-platform tools were exploding at this time because:
- Native programming resources were scarce
- Enterprise was both hungry and late to the game
- Applications and their creators were independent
Native iOS mobile developers were scarce because before iOS few people programmed in Objective-C. It was an obscure language that few knew until the iPhone made it the popular in colleges and universities across the world. If you wanted to make an iPhone app you would have to learn an entirely different language, use a new IDE and do it on a foreign operating system. This drove application developers to seek and experiment with cross-language tooling.
Enterprise was hungry and late to the game
Enterprise app marketplaces for iOS or Android did not exist, and the primary corporate interest in iPhone applications was from the marketing line of business. Central IT compounded the challenge by making it nearly impossible for developers working in a large company to even attempt to build and iOS application. First you were going to need to buy Apple Macs (corporate procurement was PC only), second many IT organizations wouldn’t even allow an Apple on the network, and finally it was unlikely employees could even install the application on a company mobile device. This promoted the current iOS and Android app outsourcing movement that has defined mobile delivery for the past five years.
There are some exceptions, such as USAA creating one of the first in-house cross-platform mobile development teams and launching the first banking application to allow check deposit using a smartphone in May 2009 (if you doubt how visionary this was, remember that the iOS SDK was not available until Feb 2008). Another innovator, American Airlines, launched the first paper-less airline travel iPhone app using TSA-supported QR Codes in July of 2010. The initiative was led by the marketing line of business and was delivered with a hybrid team of in-house server developers and a local game studio.
Mobile applications were islands not bridges
Applications did not (or at least rarely) integrate with internal corporate services or data. The marketing line of business and independent driven initiatives focused on a few social network feeds and isolated mobile first data.
This resulted in the largest cost being a single mobile client developer spending most of their time on the application’s user experience.
This in turn led to early cross-platform evaluations being very mobile client developer centric. Early RFPs and RFI’s for evaluating a mobile tool focused heavily on enumerating specific mobile device feature support and tooling language.
The resulting application coding centric view around a single app disproportionately weights problems from these early days of “One Riot, one Ranger”* mobile delivery. At this time a single programmer carried the project from start to finish for an app that had a shallow ‘stack’ with few 3rd party service integrations.
Mobile Success in 2014
The success criteria for what is “mobile application success” changed significantly over the past four years.
Today it’s full stack mobile supporting hundreds of mobile applications, customized for each business unit and mobile user persona. Three forces have influenced the development of these applications:
- Enterprises’ need for mobile apps is exploding
- Mobile demands access to data
- Proliferation of SDKs, modules and components
Enterprise mobile is exploding
In the same way enterprises lagged consumers during the Internet revolution leaving CTOs and CIOs to scramble for a web strategy, the “consumerization” of mobile forced corporate technology leaders to resolve the demand for mobile applications in a fragmented mobile device world.
Today’s corporation will not have one or two mobile applications in their mobile catalog; they will have hundreds. The comparison is for every desktop software product there are two or three mobile applications that combined will provide the same value. Compared to their desktop counterparts mobile applications are “proverbs not novels”. Mobile apps have limited computing, network, and memory resources as well as–the most precious resource of all–users’ attention and time. A mobile app chops up large desktop experiences into mobile “minutes” for employees and users to open an app perform an action and then jump to another app or just go on with their life. This changes the execution strategy from building one or two large applications to making many small apps that work as a confederacy of enablement.
Mobile demands access to data
Current mobile applications require tighter integration than ever before. Specifically in the services and data the mobile apps consume. Many enterprise mobile applications will not be seen on consumer app stores, and will focus on surfacing internal enterprise data from legacy CRM and ERP systems and promote user action on this information. This forces greater value on connecting, integrating and maintaining the data mobile applications consume and generate.
Proliferation of SDKs, modules, and components
Open source has been around for a long time, but crowd supported SDKs and components to add features and functionality and accelerate application development exploded after 2010. GitHub launched in May of 2011 fueling the movement, and more recently GitHub released Boxen to automate dependencies in development environments. In 2012, npm makes it easy to add new features to Node apps; as does CocoaPods for iOS application libraries. All these systems make it easy for developers to incorporate the rapidly expanding ecosystem of open source components into applications.
Mobile cross-platform IDEs and vendors that fail to seamlessly integrate with the ecosystem of shared components and templates will fall behind and fail to meet developer expectations.
What does this mean for evaluating cross-platform mobile?
Cross-platform solutions need to be evaluated in the context of these new demands. Simply unifying mobile programming languages to access to native device features and functionality will not be enough for mobile application success.
- Support more of the full application lifecycle.
- Go deeper in the mobile technology stack.
- Be able to incorporate community code quickly from a rich ecosystem of feature components.
While application runtime performance is important, a robust cross-platform solution can reduce apps’ overall “time to value,” and promote richer user experiences by enabling use of third-party components. Giving an additive compounding return on investment when multiple applications are created in an “app factory” delivery strategy.
A constructive framework for cross-platform evaluation measures along two vectors:
- Full mobile application lifecycle
- Full mobile application stack.
Mobile cross-platforms are moving for depth and breadth
Mobile platform solutions like Appcelerator, Xamarin, and vendor-supported PhoneGap/Cordova environments have addressed these additional requirements by extending their core technology across the application lifecycle and deeper into the technology stack.
Appcelerator has addressed some of these challenges with acquisition and partner integration. The CocoaFish acquisition in 2012 became Appcelerator Cloud Services, supporting the backend needs of mobile applications. Additionally in Appcelerator integrated Functional Test from Sosta, crash analytics and application performance from Crittercism, adding to the original Titanium tool chain.
Xamarin has extended its powerful cross device C# runtime and IDE to include third-party components directly in the environment from their component store. The platform provides continuous integratin (CI) build and automation for windows developers with its OSX build agent. The companies’ 2013 acquisition of the Calabash framework from LessPainfull provided the foundation for their Xamarin Test Cloud.
The PhoneGap story is more complex. Usually “PhoneGap” refers to the open source distribution of Cordova (cross-platform provider Icenium has an excellent write-up regarding this issue here). Cordova has a fragmented vendor landscape. There are many vendors that support the Cordova technology strategy (IBM Worklite, HP Anywhere, Intel XDK, SAP Platform – formerly SUP) as well as the traditional Adobe-owned PhoneGap. Each vendor has IDEs, supporting components, and tooling that target the needs of a mobile delivery team with vendor-supported services.
Today StrongLoop fits in the middle tier of mobile, focusing on mobile service problems that have historically challenged app success.
It does this by:
- Making it easy to connect mobile apps to data using LoopBack on top of Node.js and the rich npm ecosystem.
- Helping you to maintain and monitor Node applications with StrongOps.
- Giving you greater control over where your mobile backend runs. Insuring your mobile backend server can be run on your local developer machine, your on-premises hardware, or on cloud providers like Rackspace, Cloud9, Amazon, Heroku, or Redhat OpenShift.
Additional recent developments such as the formation of npm, Inc. in the Node community confirm the power of packaged components.
Hopefully this approach to evaluating cross-platform mobile technology will help in evaluating the right cross-platform a tool for your mobile app success.
If you still want a simple answer to Titanium vs. PhoneGap. I would recommend reading Kevin Whinnery. His article gives a very honest comparison of the two technologies.
Full disclosure, I worked with Kevin at Appcelerator as Lead SE
Looking for Node.js and API development training? StrongLoop instructors are coming to a city near you:
- Nov 6-7: Denver, CO at Galvanize Campus
- Nov 13-14: Herndon, VA at Vizuri
- Dec 3-4: Framingham, MA at Applause
- Dec 11-12: Minneapolis, MN at BestBuy
Check out our complete Node.js and API development training, conference and Meetup calendar to see where you can come meet with StrongLoop engineers.