Slides from Mobile Development Choices: Native App vs. Web Apps session at JAX conference in Mainz, May 2-6, 2011.
Most content taken from Mobile apps choices: Native Apps vs. Web Apps blog post.
This post shows various differences, in various categories between building native mobile apps and web mobile apps. I know that everyone has their own experiences and opinions, which I would love to hear. So, don’t hesitate to hit the comments at the end of this post.
| Native App | Web App | |
|---|---|---|
| Platforms | ||
| Platform | Five different mobile platforms:
Other notes:
|
Mobile web browser. Differences still exist as different versions of mobile platforms run different browsers, with different support for various latest HTML5 features. |
| App discovery, monetization, support | ||
| App discovery | App Store – proven and popular. | A number of options:
|
| App approval | App is published to an app store and goes through review process before being approved | Instant, no approval process |
| App installation | Downloaded from app market and installed | Open URL in a mobile browser, or another popular option is to create a short cut on the phone. The short cut gives more of a “native app” feel. |
| App update | Updated app goes through review process, then downloaded and installed | No approval or download process. Just update the mobile web app and everyone gets the new version. |
| App support, maintenance, adding new features |
The more platforms you support, the more challenging and difficult it becomes supporting and adding new features.
It’s not uncommon to have different native apps for iOS and Android with different feature sets. The app for iOS is usually more mature and stable.
|
Supporting and adding new features is much simpler, as you write once and it’s available on every platform. Write once, deploy anywhere. |
| Monetization | App Store – proven monetization strategy. | Web apps have a number of options:
|
| Porting/add new platform | Need to learn another mobile platform Need to learn platform’s “UI approach” |
Nothing – build once, run anywhere (almost). Might need to tweak the UI a little bit to “fit” it better in to the underlying mobile platform. Difference in browsers and supported features. |
| Experience | ||
| Performance | Faster for some UI functions, especially when heavy graphics are involved. | HTML5 improves on the infrastructure of the Web and makes applications faster and more functional. JavaScript rendering engines are getting faster and are good enough for most Web applications. |
| User experience | Native application have a lot of UI effects, usually more developed UI “logic”. Native apps can “feel faster” and screen sizes on mobile devices makes native apps more enticing as well. | Can be “very good”. For example, an app like Gmail. Will continue to improve and get better. |
| Perception | Today most people associate mobile apps with something you download and install. | We are so used to desktop web apps, so it’s just a matter of time before we “get used” to mobile web apps. It’s also important for more and more (good) web apps to become available. |
| Phone features | ||
| Video/Audio | Built-in | Possible with HTML5 |
| Offline or disconnected apps | Native apps can work in disconnected mode. | Offline mode can be achieved with HTML5. |
| Full screen mode | Built-in. | Can be in full mode by hiding browser address bar. |
| Accelerometer | Built-in. | Possible with HTML5. |
| Push | Possible with native platforms. | Possible with HTML5 technologies. |
| Integration with phone services |
Good integration with phone services:
|
Still somewhat limited with HTML5. But, more and more apps like that get data from the Internet, and not the client device. |
| Integration with phone hardware |
Integration with phone hardware
|
Some support via HTML5 is now available for camera/video. |
| Enterprise, development | ||
| Developer Skills |
Need to learn one or more of the mobile platforms and their underlying programming language/SDK:
Every platform will also have its own approach and style to developing and designing mobile user interfaces.
|
Developers can use HTML, JavaScript and CSS to create mobile web apps without of learning new languages to code native applications. But, that doesn’t mean that some training won’t be necessary to adapt exiting HTML/JavaScript/CSS skills to mobile development. |
| Development cost | Expensive, as still relatively small number of developers master these skills. | Can be significantly cheaper. Large number of developers who posses web development skills – HTML, JavaScript, CSS. But, some training might be needed to learn how to develop UI for mobile apps. |
| Mobile development frameworks | Every mobile platform has its own SDK. Even though Android and BlackBerry both use Java, applications are not compatible. BlackBerry plans to allow running Android applications on BlackBerry devices in the future, probably inside a special wrapper (virtual machine).
|
A number of options available today for building web mobile apps:
|
|
Tools that can build both native and mobile web apps: Tiggr Mobile (coming up), PhoneGap, Open plug, Adobe Flex Mobile, Titanium Appcelerator, Corona SDK |
||
| Enterprise integration | Existing infrastructure could be reused but also need service layer to communicate between client (mobile) and server. Can use REST, SOAP or custom communication protocols Hessian, Protocol Buffers. | Existing infrastructure can be reused. |
Virtually any application we used to have on a desktop from email to drawing to CRM, is now available as a web application. I think a similar move will happen in mobile, as more and more natives apps are moved to become mobile web apps.
After months of promising we have finally moved Exadel Flamingo to exadel.org and released version 2.2.0. exadel.org is our community site for hosting open source projects. Flamingo is a light weight framework for connecting rich web and mobile user interfaces to enterprise back end.
Click on image to enlarge
Flamingo connects Seam, Spring, and Java EE 6 (soon via CDI/JSR299) with the following user interfaces:
Version 2.2.0 is updated with Hessian 4 and JavaFX 1.3 support.
Server-side components, methods or services can be easily invoked from the above listed clients with minimal code. Flamingo provides the following features:
Click image to enlarge
As you can see from the image above, no matter what client you are using, invoking a method in your enterprise applications looks very similar which allows for great reuse.
How to get started?
The Mobilization of Enterprise Applications with Exadel Flamingo article on JavaLobby.com. Also check out Flamingo Q&A.
Q&A with James Sugrue from DZone on using Exadel Flamingo to build mobile applications for iPhone and Android.
Exadel Flamingo is a framework for connecting rich UIs (Flex, JavaFX, Swing) to enterprise back-end such as Java EE, Seam and Spring. Very soon Flamingo is going to move to our new open source web site exadel.org.
Something you probably were not aware of is that Flamingo now also has a mobile portion. It allows to easily connect clients running on popular smartphones such as iPhone and Android to your enterprise back-end. In fact, if you have an existing enterprise application with rich Web UI, with Flamingo you can reuse the same enterprise services and use them on smartphone.
Go here to download a demo application or sign up for a live demo (via web conferencing).