Thursday, March 1, 2012

Choosing a mobile framework: Web-based, appstore, desktop, mobile?


This is a follow-up for Choosing mobile dev platform/framework and looks closer at the eigth step - Choose if your app should be web-based or an actual app in the appstore or both, should it be mobile and desktop?

As mentioned in the original post, this one isn't always easy to figure out. Usually you want your app/product to target all end-users, no matter what kind of device they are on. Usually you can list up a couple of questions to figure out how to choose target devices/platforms.

Who is your target audience?
For this project I do need to integrate into VLEs (virtual learning environments) at some point, but more customers require the end-product to be accessible on mobile devices. This points me towards a web-page/web-based application, as some of the code most likely can be ported between a mobile app and a VLE integration. My target audience uses both mobile and desktop platforms, so I need to target both.

Should the application be mobile, desktop or both?
Second, I look at what sizes/types of devices I need to target. My current project needs both to be accessible through desktop computers, as well as through mobile devices. Again this points to having a common code-base, so a web-app would be great. Although some frameworks provide this for native as well.

Can the application be a web-page, or do you need it to be native?
So it all comes down to the question of being native on a given platform. That is usually a question of performance, but not necessarily. As there will be some animation, drag and drop, sound, I think from a performance perspective it would be good to have a native app, but if a web-app performs OK, why shouldn't I just wrap that in any of the app-wrappers?

When looking at performance, always test on low-end devices. If you can get your app to perform well there, high-end devices shouldn't be a problem. For instance, I created a small drag and drop test in a web-app wrapper. Works perfectly well on a Samsung Galaxy S2 and Galaxy Tab 10.1, terrible on the iPad 1, bad on an iPad 2, and is totally unusable on a HTC Wildfire as well as on a Samsung Omnia 7.

Basically that is because of the JavaScript interpreter on each of the platforms is different, as well as the raw cpu-horsepower. I'm surprised to see that much difference between iPad 2 and Galaxy Tab, but I know Google and Apple has various JavaScript engines in each of their respective WebKit code bases. As for the Wildfire, I'm not surprised, as it had Android 2.1 and only a 600 MHz cpu, which isn't really that much.

However, the app I created was a quite simple animation, as well as some drag and drop touch gestures, so I suspected it to perform better.

This points me towards a native app instead.

So 2 points for web-based, 1 for native. Although the performance factor is more important than common code-base, so I would say it's a draw for now. I will review this when looking at each of the frameworks later on.