If your business is looking to develop its first mobile app, deciding which mobile application development framework to build it in, and what skill set you’ll need from developers, can be tricky with so many types of development frameworks emerging. Here’s a breakdown of some basic types of frameworks, with a few leading examples of each, and a look at some of their strengths and drawbacks to help you make the right choice for your business’s app:
Native platform mobile app development frameworks. The iOS (Apple) platform and Android (Google) platform are the market leaders. Developers write code using the native tools of the platform. iOS developers use the iOS SDK, Xcode IDE, Objective-C, Core Animation, Core Graphics, Accelerometer and Cocoa Touch UI framework. Android developers use the Android SDK, Eclipse IDE with ADT plugin. Android apps are written in Java, or via plug-ins, can be written in a variety of languages including C,C++, Perl, PHP, Python, Ruby, Ruby On Rails, Scala and Scheme.
HTML5 and JQuery mobile application frameworks for multi-touch web apps that run in the mobile device browser. SproutCore, JQuery Mobile, and Sencha Touch are three of the leading tools. These frameworks create HTML5 browser-based (not-native) mobile apps that cleverly emulate the multi-touch UX of native apps on Apple and Android touchscreen devices. Since they’re HTML5 and browser-based, these mobile apps will run in the browser of Apple, Android, even Blackberry Torch devices. An HTML5 app is one of a couple of options you have to write once and run everywhere.
Cross-Platform native mobile app dev frameworks. PhoneGap and Appcelerator Titanium are two leaders. Also referred to as “wrappers” for creating hybrid web-apps, these open source frameworks essentially wrap a web application inside a native application that can be distributed via the native app stores for iPhone, iPad and Android. The hybrid web-mobile app approach is another alternative to let you target multiple platforms with a single codebase. A wrapper also makes it possible to build mobile apps for app store distribution using developers who haven’t mastered native platform languages and tools like Objective-C and Cocoa Touch. Developers use their existing web skills with JavaScript, HTML and CSS to code the application, and the framework compiles most of the code into a native iPhone, iPad or Android app.
Rapid mobile app development frameworks. AppMakr and Mobile Roadie are leading tools. AppMakr is a browser-based mobile app dev framework that makes it super-fast to create an iPhone app from existing content such as an organization’s YouTube channel, blog posts, and other social network feeds. Such apps can be created and submitted to the Apple App Store or Android Market in a matter of hours.
The Big Questions
Organizations are trying to figure out whether apps developed in write-once-run-everywhere frameworks can really hold their own next to native apps. When planning a mobile app strategy, having single codebase that reaches users on any platform is the end game – user base, cost savings, time-to-market, simplicity, and maintenance all would be optimized. No organization gets excited by the prospect of developing an app for iOS, building it again for Android, and then paying once more to code a web app. But for some app requirements doing all three can turn out to be the only viable route to market, for now. One thing is clear. When it’s launched, the app has to perform well enough to win a critical mass of user adoption.
In cases when it’s deemed necessary to write the app three times for Apple, Android and Web, organizations next turn to the question of which platform to target first, and where the web app should rank on the roadmap. No one wants to get the sequence wrong.
Strengths And Drawbacks
A friend involved in developing the beautiful PBS iPad app met me for lunch and we discussed the strengths and weaknesses of the various mobile app dev frameworks. Our talk echoed the conclusions of dozens of developers answering questions about mobile app dev frameworks on public forums like Quora.
The HTML5 and JQuery mobile app dev frameworks are on the right track, and they’re okay for building a simple browser-based multi-touch mobile app with a simple UI that doesn’t need to tap into the platform’s native features. However, for apps with more sophisticated requirements, or the need to deliver a flawless user experience to acquire users, many developers find that these platforms aren’t mature enough yet. To illustrate, my friend showed me a demo of a browser-based app developed in SproutCore for a television network rival of PBS. The emulation of native touch apps was pretty cool. Its buttons were touch activated; its menus loaded similarly to menus developed in Xcode and Cocoa Touch; it imitated iOS’s gestural page navigation; and it copied the bounce of a native iOS app when you scroll up at the top of a page.
Using two iPads, we literally set the SproutCore app on the table side-by-side with the PBS native iPad app to compare. Several UX differences became noticeable. Gestural transitions, smooth in the iOS app, were jumpy and exhibited a weird flutter in the browser app. Buttons, which changed state when touched in the iOS app, remained unchanged with no visual cue when tapped in the browser app. Menus, which loaded instantaneously in the iOS app, exhibited a performance delay before opening in the browser app. The bounce at the top of the page wasn’t quite the same. It can be frustrating, my friend said, for a UX perfectionist when the write-once-run-anywhere frameworks don’t give you access to the platform’s native UX capabilities. For an organization like PBS with a brand reputation for high-quality video content, launching with a flawless and beautiful UX was identifed as critical to maximize user acquisition. Despite the cost, hiring native iOS developers was the right strategy for getting the app onto the iPad. Now that it is released, the app has received stellar user ratings and reviews.
As for the wrappers (the cross-platform native mobile app dev frameworks like PhoneGap and Accelerator Titanium), the requirements of the PBS iPad app ruled them out as well. The app needed custom APIs (to access PBS’s streaming media content via the Amazon Elastic Compute Cloud). The team wanted to utilize UI-Web-View to embed HTML in specific areas of the iOS native app to create server side views. Requirements like these aren’t easily accommodated via a wrapper, my friend said. You’re in a box with these frameworks and you’re stuck with their developer tools. Titanium boasts capabilities to access the camera and other hardware on the device, which is impressive. But again my friend’s team found it more flexible developing with Xcode to access the native hardware.
Obviously, rapid mobile application development frameworks like AppMakr didn’t make the cut for my friend’s project. Their focus on compiling mobile apps for App Store distribution quickly from existing YouTube channels, blog posts, and social media feeds disqualified them as tools for a more ambitious app. Still, you have to credit AppMakr. For something so simple, it has attracted customers including Whitehouse.gov, Newsweek, and social media guru Seth Godin. All launched AppMakr apps and got their social content “mobilized” and packaged for the App Store in a matter of hours.
Not every mobile app has the sophisticated requirements of the PBS iPad app. But looking at the different mobile app dev frameworks through the lens of its tough requirements is instructive in sorting out what kinds of apps they’re suited for.
Native Platforms And Web – Getting The Order Right In The Roadmap
Platform preference of your target users, budget, timeframe, business objectives, the coding skills of your existing developers, and special requirements for UX and API integration – all may drive the sequence of Apple, Android, and web development. But for organizations seeking mass adoption of their mobile app, the critical factors are: (i.) maximizing total addressable audience, and (ii.) launching with a UX that will engage users. The roadmap decision often results from an optimization exercise performed on these two factors.
HTML5 web apps represent the maximum total addressable audience. Even though discovery of web apps can be an issue because they lack the powerful distribution channels of the native app stores, in theory HTML5 web apps can be used by anyone with a mobile brower based on Webkit or Chrome. That means Apple, Android, even Blackberry Torch. What’s not maximized on web apps is UX. If an organization reasons that initial user satisfaction has to be optimized in order to drive user adoption, establish brand quality, or differentiate from competitors, it may choose to do its initial launch with a native platform app despite the smaller addressable audience compared to a web app. The platform they choose to make a big splash with UX more than likely will be Apple iOS. Compared to iOS native apps, my friend said, Android apps feel like Microsoft. Developer Ish Harshawat echoed this in a Quora discussion, calling out Google for doing a poor job of communicating to developers the best practices for user experience and design. The result is a lot of the apps that started with Android as the look and feel seem kind of haphazard in usability, he said. Android 3.0, codenamed Honeycomb, introduces a completely new user interface suitable for tablet devices, but it remains to be seen how much this shifts the UX equation.
Android’s burgeoning growth, which recently surpassed that of Apple, has made big headlines in recent months, but organizations need to distinguish between growth numbers versus the current installed base of the two platforms. Nielsen figures show in the past six months Android became the top choice of consumers buying smartphones. 40.8% of smartphone buyers chose Android devices, versus 26.9% who opted for an iOS smartphone or 19.2% who preferred a Blackberry. NPD Group research put Android at a sizzling 44% of U.S. smartphone sales in the third quarter of 2010. To date, 85 competitors have lined up against iPad, and most of them will run Android. However, in installed base the iPhone still leads with 28.6% of the market compared to Android’s 25.8%..
By the time my friend’s team started with PBS, the PBS organization already had launched an iPhone app, which all agreed was the right first move. The question was what the mobile roadmap should look like going forward. Following their own optimization exercise on UX and addressable audience, the team decided to do a native iOS app for iPad first, an HTML5 web app next, and native Android smartphone and tablet apps after that.
It was the right choice for their organization. What mobile strategy works best for you?
Native platform mobile app development frameworks. The iOS (Apple) platform and Android (Google) platform are the market leaders. Developers write code using the native tools of the platform. iOS developers use the iOS SDK, Xcode IDE, Objective-C, Core Animation, Core Graphics, Accelerometer and Cocoa Touch UI framework. Android developers use the Android SDK, Eclipse IDE with ADT plugin. Android apps are written in Java, or via plug-ins, can be written in a variety of languages including C,C++, Perl, PHP, Python, Ruby, Ruby On Rails, Scala and Scheme.
HTML5 and JQuery mobile application frameworks for multi-touch web apps that run in the mobile device browser. SproutCore, JQuery Mobile, and Sencha Touch are three of the leading tools. These frameworks create HTML5 browser-based (not-native) mobile apps that cleverly emulate the multi-touch UX of native apps on Apple and Android touchscreen devices. Since they’re HTML5 and browser-based, these mobile apps will run in the browser of Apple, Android, even Blackberry Torch devices. An HTML5 app is one of a couple of options you have to write once and run everywhere.
Cross-Platform native mobile app dev frameworks. PhoneGap and Appcelerator Titanium are two leaders. Also referred to as “wrappers” for creating hybrid web-apps, these open source frameworks essentially wrap a web application inside a native application that can be distributed via the native app stores for iPhone, iPad and Android. The hybrid web-mobile app approach is another alternative to let you target multiple platforms with a single codebase. A wrapper also makes it possible to build mobile apps for app store distribution using developers who haven’t mastered native platform languages and tools like Objective-C and Cocoa Touch. Developers use their existing web skills with JavaScript, HTML and CSS to code the application, and the framework compiles most of the code into a native iPhone, iPad or Android app.
Rapid mobile app development frameworks. AppMakr and Mobile Roadie are leading tools. AppMakr is a browser-based mobile app dev framework that makes it super-fast to create an iPhone app from existing content such as an organization’s YouTube channel, blog posts, and other social network feeds. Such apps can be created and submitted to the Apple App Store or Android Market in a matter of hours.
The Big Questions
Organizations are trying to figure out whether apps developed in write-once-run-everywhere frameworks can really hold their own next to native apps. When planning a mobile app strategy, having single codebase that reaches users on any platform is the end game – user base, cost savings, time-to-market, simplicity, and maintenance all would be optimized. No organization gets excited by the prospect of developing an app for iOS, building it again for Android, and then paying once more to code a web app. But for some app requirements doing all three can turn out to be the only viable route to market, for now. One thing is clear. When it’s launched, the app has to perform well enough to win a critical mass of user adoption.
In cases when it’s deemed necessary to write the app three times for Apple, Android and Web, organizations next turn to the question of which platform to target first, and where the web app should rank on the roadmap. No one wants to get the sequence wrong.
Strengths And Drawbacks
A friend involved in developing the beautiful PBS iPad app met me for lunch and we discussed the strengths and weaknesses of the various mobile app dev frameworks. Our talk echoed the conclusions of dozens of developers answering questions about mobile app dev frameworks on public forums like Quora.
The HTML5 and JQuery mobile app dev frameworks are on the right track, and they’re okay for building a simple browser-based multi-touch mobile app with a simple UI that doesn’t need to tap into the platform’s native features. However, for apps with more sophisticated requirements, or the need to deliver a flawless user experience to acquire users, many developers find that these platforms aren’t mature enough yet. To illustrate, my friend showed me a demo of a browser-based app developed in SproutCore for a television network rival of PBS. The emulation of native touch apps was pretty cool. Its buttons were touch activated; its menus loaded similarly to menus developed in Xcode and Cocoa Touch; it imitated iOS’s gestural page navigation; and it copied the bounce of a native iOS app when you scroll up at the top of a page.
Using two iPads, we literally set the SproutCore app on the table side-by-side with the PBS native iPad app to compare. Several UX differences became noticeable. Gestural transitions, smooth in the iOS app, were jumpy and exhibited a weird flutter in the browser app. Buttons, which changed state when touched in the iOS app, remained unchanged with no visual cue when tapped in the browser app. Menus, which loaded instantaneously in the iOS app, exhibited a performance delay before opening in the browser app. The bounce at the top of the page wasn’t quite the same. It can be frustrating, my friend said, for a UX perfectionist when the write-once-run-anywhere frameworks don’t give you access to the platform’s native UX capabilities. For an organization like PBS with a brand reputation for high-quality video content, launching with a flawless and beautiful UX was identifed as critical to maximize user acquisition. Despite the cost, hiring native iOS developers was the right strategy for getting the app onto the iPad. Now that it is released, the app has received stellar user ratings and reviews.
As for the wrappers (the cross-platform native mobile app dev frameworks like PhoneGap and Accelerator Titanium), the requirements of the PBS iPad app ruled them out as well. The app needed custom APIs (to access PBS’s streaming media content via the Amazon Elastic Compute Cloud). The team wanted to utilize UI-Web-View to embed HTML in specific areas of the iOS native app to create server side views. Requirements like these aren’t easily accommodated via a wrapper, my friend said. You’re in a box with these frameworks and you’re stuck with their developer tools. Titanium boasts capabilities to access the camera and other hardware on the device, which is impressive. But again my friend’s team found it more flexible developing with Xcode to access the native hardware.
Obviously, rapid mobile application development frameworks like AppMakr didn’t make the cut for my friend’s project. Their focus on compiling mobile apps for App Store distribution quickly from existing YouTube channels, blog posts, and social media feeds disqualified them as tools for a more ambitious app. Still, you have to credit AppMakr. For something so simple, it has attracted customers including Whitehouse.gov, Newsweek, and social media guru Seth Godin. All launched AppMakr apps and got their social content “mobilized” and packaged for the App Store in a matter of hours.
Not every mobile app has the sophisticated requirements of the PBS iPad app. But looking at the different mobile app dev frameworks through the lens of its tough requirements is instructive in sorting out what kinds of apps they’re suited for.
Native Platforms And Web – Getting The Order Right In The Roadmap
Platform preference of your target users, budget, timeframe, business objectives, the coding skills of your existing developers, and special requirements for UX and API integration – all may drive the sequence of Apple, Android, and web development. But for organizations seeking mass adoption of their mobile app, the critical factors are: (i.) maximizing total addressable audience, and (ii.) launching with a UX that will engage users. The roadmap decision often results from an optimization exercise performed on these two factors.
HTML5 web apps represent the maximum total addressable audience. Even though discovery of web apps can be an issue because they lack the powerful distribution channels of the native app stores, in theory HTML5 web apps can be used by anyone with a mobile brower based on Webkit or Chrome. That means Apple, Android, even Blackberry Torch. What’s not maximized on web apps is UX. If an organization reasons that initial user satisfaction has to be optimized in order to drive user adoption, establish brand quality, or differentiate from competitors, it may choose to do its initial launch with a native platform app despite the smaller addressable audience compared to a web app. The platform they choose to make a big splash with UX more than likely will be Apple iOS. Compared to iOS native apps, my friend said, Android apps feel like Microsoft. Developer Ish Harshawat echoed this in a Quora discussion, calling out Google for doing a poor job of communicating to developers the best practices for user experience and design. The result is a lot of the apps that started with Android as the look and feel seem kind of haphazard in usability, he said. Android 3.0, codenamed Honeycomb, introduces a completely new user interface suitable for tablet devices, but it remains to be seen how much this shifts the UX equation.
Android’s burgeoning growth, which recently surpassed that of Apple, has made big headlines in recent months, but organizations need to distinguish between growth numbers versus the current installed base of the two platforms. Nielsen figures show in the past six months Android became the top choice of consumers buying smartphones. 40.8% of smartphone buyers chose Android devices, versus 26.9% who opted for an iOS smartphone or 19.2% who preferred a Blackberry. NPD Group research put Android at a sizzling 44% of U.S. smartphone sales in the third quarter of 2010. To date, 85 competitors have lined up against iPad, and most of them will run Android. However, in installed base the iPhone still leads with 28.6% of the market compared to Android’s 25.8%..
By the time my friend’s team started with PBS, the PBS organization already had launched an iPhone app, which all agreed was the right first move. The question was what the mobile roadmap should look like going forward. Following their own optimization exercise on UX and addressable audience, the team decided to do a native iOS app for iPad first, an HTML5 web app next, and native Android smartphone and tablet apps after that.
It was the right choice for their organization. What mobile strategy works best for you?
Comments
Post a Comment