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.

Choosing a mobile framework: Make a list over frameworks you do want to look into

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the seventh step -  Make a list over frameworks you do want to look into ?

It is important to list any framework you think it's worth considering, and probably a few that you don't think is worth considering, as it's quite critical to select the right framework in order to save development time after you have learned a framework.

This is not the step where you start looking at every detail about the framework, only find them, briefly read about them, and decide yes/no on the question: Can I consider this framework?

The frameworks I consider for this project are:

• Appcelerator Titanium (appcelerator.com)
• Phonegap (Apache Cordova) (phonegap.com)
• Native iOS + Native Android (And perhaps native WinMo)
• Rhomobile (rhomobile.com)
• Corona SDK (anscamobile.com)
• Moai SDK (getmoai.com)
• Mosync (mosync.com)
• Mono for iOS/Android (xamarin.com/monotouch / xamarin.com/monoforandroid)
• Edgelib (edgelib.com)
• Unity 3D (unity3d.com)
• Marmelade ( madewithmarmalade.com) (Earlier known as airplay sdk)
• appMobi (appmobi.com)
• App Game Kit (appgamekit.com)
• Cocos2D-x (cocos2d-x.org)
• Others I might not have found yet?

You shouldn't even consider pricing of the frameworks at this point, although that might be a major factor to considering a framework.

You might want to consider the platforms you are choosing when looking at various frameworks. For instance, I prefer if a frameworks supports all the platforms I want to target, but for now, I will consider platforms that support at least iOS and Android.

Why don't I include AppInventor, DragonRad, DroidDraw and other click-and-create frameworks? Well... Quite simple: Try to do graphics/drawing/physics in any of them. If you just need forms/push buttons and sending/getting data to/from a website, sure, use any of them, but as soon as you move out of what a click-and-create framework can provide, you should consider a real framework where you can do some actual coding.

If you are going to be a mobile developer, be sure to choose a framework that doesn't limit you from your creative ideas.

Update 7/3: Added cocos2d-x

Choosing a mobile framework: Any programming languages you want to avoid?

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the sixth step - Any programming languages you want to avoid?


It's better to consider languages you want to avoid rather than listing the ones you do want to dig into. If you start selecting a programming language, you will limit the number of frameworks you can consider.
Example: you only want to write in C#, there is Mono/Monotouch and of course MS .net. But what if that platform doesn't support the features you need?

Since the syntax of languages today is barely dialects of one another, you should as a developer/programmer be willing to jump into a new language, just as much as a toddler wants to learn how to walk. (Yes, I have a toddler at home).

When you have learnt 3-4 programming languages, you start seeing the similarities, and the differences, and you usually figure out that most languages are very closely related. It's just another object, a function, a variable, an array here, a hash there etc.

Although working on several languages can be confusing at times, always keep reference manuals close by when you are stuck.

I only have one language I always want to keep away from, and that is VB. I always end up using more time figuring out why on earth Microsoft never put VB out of it's misery...

When you have compiled your list over languages you don't want to learn, go through it again, and consider if you really do want do choose a framework that suits the needs for your project, or suits your programming language skills.

Choosing a mobile framework: Choose the platforms you need to target

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the fifth step - Choose the platforms you need to target


This should be fairly simple, as you just have to list up the platforms you want to support. However, it is a good idea to also consider if the application should be for smartphones, tablets and/or desktops.

Here's a few examples:

1. You are going to make a game for tablets, but the game would be just as good on a desktop. You should consider if you need to develop the same twice (1 for desktop and 1 for tablet) or if you should have 1 codebase for both.
2. You are making an app for smartphones, but hope it can be reused on tablets. Should you go all the way to desktop as well, or stick with smartphones only, and perhaps make a minor tweaked version for tablets?
3. You are going to develop a desktop-only application. My question today would be: why? Wouldn't it be better to do a desktop + tablet or web version?

Basically you end up looking at both platforms and technology, when choosing which platforms to support. I do however recommend just choosing platform and form factors in this step and if needed change when looking at frameworks.

For my project I'm only targeting smartphones and tablets, however I do see that the application can work for desktop as well. So I will try to write reusable code. Reusable code is usually either very low level code or very high level code, while languages that are wrapper for low level quite often end up being quite platform specific.

For instance, VB and C# libraries isn't reusable across platforms, but C and JavaScript libraries is most likely reusable. (JavaScript is depending on the platforms web browser capabilities). There are more factors than only the language, but I've more or less always been able to adopt/port a C library to any given platform.

My conclusion for my current project will be to support in the following order:

1. Android and iOS
2. Windows Phone
3. (Windows 8 Tablets, if released...)
4. Desktop

For form factors this is my priority:

1. Tablets (7 inch and up)
2. Smartphones
3. Desktop (15 inch and up)

In a matrix to summarize:

	Tablet	Smartphone	Desktop
Android	1	2	-
iOS	1	2	-
Windows (7 and newer)	4	-	3
OS X (Lion+)	-	-	3
Windows (XP/Vista)	-	-	5
Matrix for preferred platforms and form factors

Since MS is very likely to release Windows 8 with tablet support, I need to consider that already now, as that might end up being the third major tablet-market player. Why didn't I include Googles chromebook? Currently I have 0 demand for chromebook versions, and that isn't likely to change within the next 12-18 months.

So focus is iOS and Android tablets first, smartphone second, then perhaps desktops (Win 7 + OS X).

Choosing a mobile framework: Non critical functions

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the fourth step - Chossing/Identifying the features that aren't critical to your app, but nice to have.

It should be fairly simple to do this step, as you should already have an idea of what you haven't written down in either step 2 or step 3.

For my current project it was only Text to Speech that isn't critical. I do want to implement it in my app at some point, but it can come later.

It is recommended to do a bit of research on these features to see how hard they are to implement. If they are easy enough, you might want to implement them instead of adding them to the todo list.

I did quite a bit research on Text to Speech, and it's fairly simple to implement if you aren't using a framework, and are coding native on at least iOS and Android, but for frameworks, it still looks like a no-go. However, there are a few third party companies building TTS engines that might work for my app, so I need to see have hard it is to create a plugin/module for any chosen framework as well.

This leads to adding a feature to step 2:

• How hard is it to create plugins/modules?

I'm not updating step 2 with this, but I'll keep it in mind when comparing various frameworks.

Choosing a mobile framework: Identify which critical functions you think it's OK to implement/write for yourself

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the third step - Identify which critical functions you think it's OK to implement/write for yourself.


It should be fairly simple to narrow these elements down, if you still have something left on the list from the first step. You should always consider each function that you want to implement yourself, if it might be better to let the framework handle it (if it can...).

I need the following to functions in my current project:

• Basic image manipulation
• Drawing/Painting

Let's have a closer look:

Basic image manipulation: I need crop, rotate and zoom. These are fairly simple to implement. If the framework has image manipulation, I will weigh towards it, but it's not that critical. My current project can even survive without it.

Drawing/Painting: I need to be able to draw simple figures. I do have some SVG's that I do want to use for drawing some simple images, which should be possible to fill. I've added a google presentation below to show it. This can be implemented as a canvas (html5), opengl, some native drawing wrapper, or other options. I prefer if it has some built in 2d vector functionality, but falling back to opengl is also acceptable. (And would probably perform better as well)

As my app cannot function without drawing/painting, I do feel this is so critical, that it's worth using most of the development time on this area.

Here's what it should be able to do:

Note about the image: I've used images from google image search, so if you do have a copyright on any of the images, please let me know, and I'll be sure to mention you in the post, or remove the image if you don't want it in the sketch.


Some of these features might require quite an amount of work to implement, so always consider if you either learn a great deal about the framework, the platforms, programming techniques, and if you can reuse any of the code in a later project. Also consider if you can use any third party helper libraries to ease your development, and probably speed the development time up as well. However, you are in full control when you write from scratch.

Choosing a mobile framework: Identify critical functions, you don't want to implement yourself.

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the second step - 
Identify critical functions, you don't want to implement yourself.

You need to identify which functionality you don't want to implement yourself, in order to figure out what framework to start with.

This is most likely core functionality of a framework or third party libraries for the framework. I prefer core functions over third party libraries, as you never know when a third party library might stop supporting newer versions of the framework or newer platforms. (Well, to be honest, you newer know this for a framework either, but is usually a risk worth taking.)

What are critical functions you don't want to implement? I mean functions that you shouldn't need to go into native code on each platform supported by the framework. For instance if you do want sound in your application, that is most likely a critical function.

From the list from step 1 I had three functions that the framework needed. As the application I'm working on is a bit larger, and I do want to "future-proof" myself, I expanded the list a bit to the same as in the original post.

• Drag and Drop
• Basic access to camera
• HTTP(S) request support
• JSON support
• Custom user interface elements (Must be possible)
• Custom user interface placement  (Must be possible)
• Audio playback (simple)

Why I don't want to implement these functions myself?

Let me go through each function:

Drag and Drop: I've done drag and drop before Qt natively supported it, and it was a hassle. I've done drag and drop on the web before there was a properly cross-browser drag and drop javascript library. It wasn't worth the workload.

Basic access to camera: It will be diffcult and timeconsuming to make sure you are up to date on all platforms/devices for this one.

HTTP(S) request support: It's not that difficult to implement if the platform supports tcp sockets, but it's better if it's supported directly.

JSON support: There are tons of libraries for json, so that should be fairly simple to implement yourself, but since there are that many json libs, it's likely that one or another is built into the framework. It's easier and better to choose a framework that already has it.

Custom user interface elements and placement: I do need a bit more than push buttons and text fields. Who doesn't? There are enough text-box-push-button-radio-button apps out there. However for this step it's important to figure out how to implement it. Does it require OpenGL, are there core graphics functions for custom UI elements? Do you use HTML/CSS? How is the performance?

Audio playback: Should be fairly simple to playback a mp3/wav or similar file on the given platform. For this project it's non-critical when looking at latency, but I know already that if latency is critical, Android is currently not possible, however, I know that Google has this on their roadmap, so maybe later.

This raised a few questions for each functionality, which will be addressed when digging into each framework.