We’ve just launched our systems@work App for Android mobiles, so (with a little configuration and an upgrade to the central server application) our users all over the world can connect to their company’s systems@work database and submit and authorise forms through their Android mobiles.
It’s hard to find reliable statistics on relative market share for Android and iOS in the business sector (precisely those who might use time@work, expense@work or forms@work), but it’s clear that Android has won at least half the market, and in some areas of the world, much more than half. When, at a recent LLP Group company get-together, I asked my colleagues which of the two they use, a clear majority put their hands up for Android. A couple rather sheepishly owned up to Windows Mobile, but, with apologies to the two of them, for the moment I’ll ignore that opportunity. And the Blackberry one too.
At least Android phones can be cheap. When we reached the final stages of testing the Android version of systems@work a couple of months ago, I went out and bought myself one for just 40 GBP (with about ten minutes of free local phone calls thrown in to sweeten the deal). It took me some time to get used to the different style, but once I got inside our App it seemed like familiar territory and our App worked just as well. I was able to submit the invoice for the Android phone, as a legitimate business expense, using the App itself just twenty minutes after I bought it. (That’s logically equivalent to driving home a car salesman in the car he’s just sold you. Or something like that.)
Developing apps hasn’t been a painless experience. The problem for App developers is that the technical environment for App software is utterly different for iOS and for Android. And when it comes to Android you have the additional worry that you must make sure that what you’ve developed will work on the most ‘vanilla’ version of the operating system, because Android can be ever so slightly different on different devices. Apple’s iOS, on the other hand, is always the same (barring new versions).
So, App development is expensive. It took us more than a year to finish the iPhone version and around six months to complete the Android one. At least the web services that read and update the systems@swork database are the same for both Apps.
Our App is complex, though very simple on the surface. When you connect it to your systems@work database, it takes the forms that are defined there, and which are always very different for every one of our systems@work customers, and renders them in your mobile, together with all the lookup lists, date fields, numeric fields, and so on. that you need to fill in.
You can have as many forms as you like – for time entry, for expense entry (in local or foreign currency), for mileage calculation (with the distance between two place names or postcodes being automatically calculated by Bing if that’s what you need), for absence requests, for just about anything. You can photograph a receipt (or the Tower of Pisa for that matter) and record a voice memo. When you’ve finished entering data (online or offline) you can upload your transactions, photos and voice memos, to the server, sending forms for immediate authorisation or feeding the data into forms and timesheets that you can finish off in the browser.
I dream that one day there might be a single programming language that will work for both iPhone and Android, even if we’d then have to write a third version of our App. Stepan, our development manager, tells me that there’s talk in the technosphere about a new language or development environment called Swift that might solve just this problem. I look forward to it, but not tomorrow.
For the moment, and for some considerable time to come, we’re happy to have launched systems@work for Android as a separate App. It’s functionally identical to the one that works on an iPhone, so we’ll go on developing both in tandem, at least until we’ve finally caught our breath and have the stamina to begin again with Swift,