My thoughts on mobile development (and I've skipped Titanium)

The last months have been busy for me. Very busy. Our company is - as you probably know - heavily engaged in the mobile area. That means specifially for me: doing development for mobile devices. And that’s what this article is about. It’s not about dogmatic views about which technology is best! I know that others have those points of view. I don’t care. I believe in solutions that solve the needs. No matter how you’re doing it. And I believe in what users are saying.

We had specific use cases for new stuff (tba very soon). And we had to make decisions. Decisions about the technology to choose. First of all: we’ve developed for iOS devices (Android is on the road, too). No Blackberry, no Windows, no Symbian or however. We’ve focused on the main players. Sorry to say that, but the others are these days less important. And we built solutions for customers - not for internal usage.

Let’s go through some step’s which in my opinion are important to consider. And let’s see if and how a technology maps to that. I went through different technologies and IDE’s in the past months, like native iOS development, native Android development, mobile web, Titanium, PhoneGap etc. So I (hopefully) have a nice overview.

Performance

Yes, performance is important. Users want to click (better: touch) and directly see an action. They don’t want to wait for 2 seconds. You’re lucky if you’re users don’t want that. The best example was Facebook. They’ve shifted from a mainly web-based iOS application to a native application. The main reason was performance on the users side. Don’t underestimate that. Friends of mine, which have complained to the app are now very happy (and none of them is an IT guy).

You can get a reasonable performance with a web app - but that heavily depends on the network. Or on how you store data locally (using HTML5). But the (my personal) best experience has been with the native IDE’s (Objective-C for iOS and Java for Android). Those apps are running as expected by users. The available “not-real-native” (I abbreviate with: NRN in this article) ways like Titanium or PhoneGap have been OK with that (it depends on the amount of data you’re using).

Usability

People like doing things they are familiar with. I’m one of those persons. And they like a kind of same look and feel. When they touch on the arrow in the left top corner they know that the app switches back to the previous screen. And they want to see a direct result (see performance).

Web development does fullfill that partly. You need a real good CSS to make things look native. And at the end they don’t feel native. Users are feeling that. Sometimes you may not care - but it’s really important. If your users are able to distinguish between a “web app” and a “native app” - you’re lucky again. Often users aren’t. The native IDE’s fullfill it. They ARE native. Depending on the NRN: they (may) feel native, too. That’s there job. To compile a language abc (mostly JavaScript/HTML) to a “soup of native code”.

Network coverage

Are your users living in high network coverage areas? Ten MBit downstream always available? Then you’re lucky - once again. But what happens if there is no or little network coverage? Does the app work? Should it work? What you may hear from users are comments like “it’s slow - again” or “I can’t use it at location abc”. Availability is a critical success factor. And that’s something you (mostly) can’t influence. So you’ve to design a mobile app which respects that.

If you don’t use HTML5 in web application as a storage - you’re lost. Or you don’t care about network coverage. All other ways (native IDE and NRN) enable you to respect network coverage. Man, they have classes and methods to even detect which kind of network (WiFi or WWAN) is available and how that is covered. Think about that. Nothing is more worse than getting a call from a CEO which tells you that he can’t connect to his data.

Security

I love security. Users don’t. They don’t like remembering internet passwords. And they don’t like to enter passwords into multiple applications/web sites. Have you considered your companies password rules like “change the password every 90 days”? And how do you store data? Is everything online and you don’t have a local data storage (see network coverage)? Or do you store data locally? If yes: where do you store the passwords? Or the confidential sales data? Can that become hijacked? Think about it.

That’s a point where I personally think web technology is not the best way to create solutions. You don’t have access to the real secure storage like the iOS Keychain. And have you ever tried to encrypt stuff locally using web technology? Or prevent the backup of your stuff? Try some Google searches - maybe you’ll find something. That’s the point where I definetly fall in love with real native development. They can do everything - because they ARE native (I’ve to repeat that). For one of our apps we’ve implemented Domino certificate-based authentication (including the certificate enrollment). Users love it - setup once, never to change. IT security loves it - no longer weak HTTP passwords. Very cool IMHO.

Deployment

Deployment is another component. Web apps are easily to deploy. Just change the server side. Native apps can be easily deployed, too. Just think about the apps you’ve got on your mobile devices. 'nuff said.

Documentation and Development time

One of my favorites (and in this case not user-related): Documentation on the technology. That means the documenation of the provider. And how and where to get help from others which have more experience. That’s even more important when you’re new to stuff (as I was). Web development isn’t so hard to do. You need JavaScript and HTML(5) experience (there are armys of developers in the world which can do that). The stuff is very mature. You’ll find a lot of documenation for that. It’s the same for native development. The sources, the examples, the community stuff I’ve seen, read and consumed - all has been awesome. Why? Because it is very vell maintained - and there are A LOT of other people doing this stuff, too. I can’t say that for the NRN - documentation is sometimes (or often, depends on the NRN) a crap. Point.

All that leads to development time. Web development could be fast, very fast. If you’ve got frameworks. Hell, you can get a web developer for 50 EUR/h or less to do the main UI stuff and just add the backend yourself. That’s not the same IMHO to native development. It took me some time to get familiar with Objective-C. Nowadays I’m feeling well with my speed. There is still a lot space for improvement and for getting better - and faster. But i. e. I’m nearly as fast as I was in my Titanium times. And Android development…well…I know Java a bit ;-).

Dependencies

I don’t like to depend on something I can’t control. Adding additional, non-controllable layers could be a very, very bad idea. You can control the ExtLib (if you now how to change it), but you can’t control NRN. That’s the point where NRN drove me crazy - and that’s why we’ve skipped them. Have you ever updated a SDK with a x.x.point release? I think so. Has that messed up your application? I don’t hope so. But that was my – personal – experience. Those “IDE” have messed up the functionality of apps. There was a need to update for a needed functionality - and that update broke heavily existing code. The last Titanium app has been converted a few days ago. Goodbye you not so nice fellow. (OK, this passage is very personal experience but I had to say that).

Re-reading the post I must say that it could be - unintended - some kind of dogmatic. Sorry. But that’s what I think. You may have other opinions. I hope you have other opinions. I may change my points of view in the future. But currently I see the real native development as a key component to an applications success. And personally I learn a lot of new and cool stuff nowadays. You never know what’s it good for.