Mobile app development is a mess. Sure, it’s getting better but it still has a long way to go catch up with the development process on the desktop or even backend technologies.
Last year, german software company SAP cited that the development costs for a mobile app covering more than one platform starts at $50.000 and other figures I’ve seen concur with that estimate. Considering that this covers only the initial development, a lot of small and medium-sized business will think twice about developing their app and again think doubly on how to keep costs small. Back at doo we had mobile development teams for each platform, writing native code for each and even adapting workflows to suit the habits and expectations of users of the respective mobile OS.
But not many teams will be able to afford so much manpower, and so, with a tight budget and time schedule for our evopark app, I looked at and evaluated a lot of mobile development frameworks in the past weeks.
Currently the main players (in no particular order) are:
Xamarin is even more focussed on the ‘native’ aspect to improve the user experience. Their per-developer-per-platform price tag was somewhat off-putting for us but I’ve heard a lot of good things from other developers who use it.
AppMethod also has a price tag that was outside our budget but it also looked like an interesting approach. Even if I’m not certain that a C++ codebase - as appealing as some aspects of it are - is contemporary standard.
Qt is one of the oldest cross-platform UI frameworks on the desktop and is working on expanding into the mobile market. They’re currently restructuring the project to provide better accessibility to new developers. After hours of cursing while trying - ultimately without success - to build the native map module for my Android phone, I decided to wait for that initiative to progress somewhat further.
At evopark, being vary of the sluggishness that some HTML-based apps exhibit, we decided to use Titanium. Now, with a few weeks of development under our belt, I’m still uncertain whether it was the best choice. Certainly, the code base - in Literate CoffeeScript - works on both iOS and Android but we experienced a lot of situations where code would work fine on one platform and violently crash - with only sparse log entries - on the other.
And although I could live with some
if OS_IOS code, what really boggles my
mind is how bad the developer experience with Titanium is. From starting the
build process to the app opening on a device, no less than a minute will pass.
Change a single line and start the whole thing over. And never mind that the
“Titanium Studio” IDE with its slow speed seems to be built to prove all
prejudices against Eclipse-based IDEs.
Luckily there is the command line tooling and - most notably - TiShadow to get a speedier process. And from what I’ve seen of Ti Inspector it provides some decent debugging when targeting iOS. On Android, it’s mostly debugging like it’s (PHP in) 1999: a lot of log-statements to output variable contents and state. Regarding the use of the IDE’s debugger, I refer you to my previous statement about build times.
Somewhat frustrated by that experience, I took last weekend for a quick look at Ionic and very much liked what I saw. We now started a side-project with it so in a few weeks I may be able to compare its HTML5-based performance to that of Titanium.