Everyone wants to go mobile today. But what’s out there is a mobile jungle – besides fragmentation across devices, platform fragmentation is very pronounced, and different mobile browsers. As BYOD(Bring Your Own Devices) is becoming common in workspace and schools, what does it mean for content developers?
At least you might have heard of native apps, web apps (or HTML5 apps for nowadays) , or hybrid apps. Borrowing from Salesforce website, here is a basic categorization: (commonly known options, more details : Native, HTML5, or Hybrid: Understanding Your Mobile Application Development Options)
- Native apps are specific to a given mobile platform (iOS or Android) using the development tools and language that the respective platform supports (e.g., Xcode and Objective-C with iOS, Eclipse and Java with Android). Native apps look and perform the best.
- Hybrid apps make it possible to embed HTML5 apps inside a thin native container, combining the best (and worst) elements of native and HTML5 apps.
Why Not Just Go Mobile?
Why Not Just Go Native? Because native app means native cost. (Thanks to Jim Cowart ‘s article)
In VisionMobile’s Developer Economics (2012) report, they found that the average mobile app would take roughly three man-months to develop. The average cost, at the time, to develop an app for iOS (the “best platform for generating revenue”) was $27k. They also found that only 54% of iOS developers managed to break even. 54%? That’s a bit concerning, but it doesn’t stop there.
In the Developer Economics 2013 report, Vision Mobile described what they called the “app poverty line” – if you made less than $500 per app, per month, you were below the app poverty line. Of the survey respondents from that report, 82% of them were writing mobile applications to make money. Of that 82%, 67% of them were below the app poverty line! They go on to say:
“In mobile development, loyalty to one platform is not something that pays off. Our research shows that the revenues are higher when using more platforms.”
If you want wide coverage you need to create an application that will run on iPhone, Android, Windows Phone, Symbian, BlackBerry 7/10, Nokia platforms, and more. That’s where web apps come to rescue.
Jim Cowart points out the main questions you can ask that will help determine your options:
– Do you need to have an app store presence? If yes, then mobile web is out. If “no” or “not necessarily”, then mobile web is an option.
– Are you OK with no app store presence, you need the ability to frequently update the application and you’re not nessarily concerned with heavy monetization of the app? (Believe it or not, this happens – particularly when an established company is expanding its reach to mobile to establish presence before other mobile initiatives.) If yes to all 3, then mobile web could be your answer (assuming you don’t need heavy device API availability).
– Do you need to be able to access device APIs (accelerometer, camera, GPS, key chain, use push notifications, etc.)? Then mobile-web is out.
When you don’t need an app store presence, aren’t really using device APIs, aren’t as concerned about app monetization or you have alternative ways to monetize your content, want to be able to update the content often and potentially take advantage of re-using a responsively-designed desktop site. Mobile web is your choice. Its low development cost, low technical barrier and easy distribution across the widest range of devices are crucial. And because your content is on the web, it’s searchable, which can be a huge benefit in some cases. (Jim Cowart noted : Don’t underestimate what’s possible here. Both time.com and forecast.io are good examples of what’s possible with this approach. It’s worth noting that some device-level APIs are available to mobile web applications – good examples being geolocation, media capture, contacts and others.)
Web-based HTML5 solutions appear as 2 practices now : Web Sites vs. Web Apps, an excerpt from VisionMobile blog explains:
For developers, it is easier to draw the line between web sites and web apps if we think of the technical distinctions. Web apps have some defining attributes that bring them closer to their native counterparts:
– rich/interactive user interface, possibly mimicking the native UI of the device
– using advanced device capabilities – like geolocation, camera integration, or other technologies that the W3C Device APIs and Policy Working Group is developing
– action-oriented rather than information oriented
– not relying heavily on (or hiding when possible) the browser chrome (back button, reload button, address bar)
– working off-line, for example using HTML5 ApplicationCache, localStorage, or indexed database
Long term the distinction should not matter. According to FT’s Stephen Pinches, it really doesn’t make any sense, on the long term, to speak about the future of the mobile web: “there shouldn’t be “mobile” and “desktop” but simply good, user-centered design, which adapts and responds to the screen size and features of the device upon which it is displayed. However, on short to medium term, there is a need to differentiate and ensure the user experience is as good as possible on a given device.”
But web apps can’t access native features on the device, also the offline storage and security might be a concern. Hybrid apps could provide the best of both worlds. Hybrid apps can store their files on the device or on a server. REST APIs are used to move data back and forth between the device and the cloud when storing files on the device.
Special Requirement for Education/Training
There are many factors that play a part in your mobile strategy, such as your team’s development skills, required functionality, offline capability and user data tracking capability. For education / training purpose, the user data tracking is a special requirement that only some authoring tool like Claro can provide. Because of the tracking capability from LMS, educators even can provide mentoring to distant learners through mobile learning apps.
Examining what Claro is striving to provide, except the pure native apps creation, it covers all other possibilities mentioned in this article. What’s more, the options to download to LMS or desktop are also important for “true mobile learning” – learning anytime anywhere. It caters to as many preferences and alternatives as possible. And then it crafts the authoring environment without the need to code a line for learning content authors.
If you have any question about what mentioned in this article, you are welcome to leave your messages.