This article is more than 1 year old

Get your staff working on the move: Develop that app for mobile

Mind the gap between the data centre and the handset

Tools for the job

For Windows, the choice is Visual Studio. The Express version doesn't cost you anything and the commercial versions will set you back only a few hundred quid if you want the extra bells and whistles they give.

You will want to do the job properly, and Microsoft would add that it is working to unify the environments so that your work will be transferable from mobile devices to traditional platforms.

On the Mac you need the Xcode development system, which is a free download from the Apple App Store. And for Android you need the Android Developer Tools (ADT) – though in the next few months this will be superseded by the new Android Studio which is in Beta as I write.

The Android developer tools are available for both Windows and Mac

With regard to the platform you use, you need to be running Visual Studio on Windows 8.1 if you want to develop for Windows Phone 8, and with Xcode you will need a reasonably recent flavour of Mac OS X (Snow Leopard or later).

The Android developer tools are available for both Windows and Mac. They are Java-based and use the Eclipse integrated development environment (IDE), which also makes them the most open source of the lot.

Having spent more years than I care to remember as a .NET developer in a Microsoft world I know my way around it pretty well already, so I tried out Xcode and ADT to see how they compare.

The Android setup was the hardest to get going, primarily because it is the only one that doesn't come as a packaged, proprietary app.

Since it is Java-based one has the usual fun persuading it to see the Java installation and in my case persuading it that the 64-bit version of the kit really should be able to run on the 64-bit version of Windows 7 on my HP laptop.

That said, it took only a few minutes to figure out what was wrong, and the Mac version ran with no such gremlins.

Once running, the IDEs all take pretty much the same approach. The layout looks very similar: there is a pane with a hierarchical representation of all the code files and libraries included in your project; a pane with a graphical representation of the screen of the device you are developing for; and an emulator application that runs a virtual mobile device on your PC or Mac into which the IDE injects the executables so you can run and test them.

You can, of course, test your code on a real device but it is a whole lot easier to run with the emulator until you are happy with the result and want to take the next step.

The approach to developing applications is pretty simple: design the look and feel graphically on the GUI view of the device, then add the code that reacts to events associated with the user pressing and typing stuff.

Looking at the Mac version (there have been Java and Windows developer IDEs for donkey's years), this will be refreshing for anyone who ever came across the Macintosh Programmer's Workshop, the development kit for the Mac back in the days before Mac OS X. This was slightly more complex than the user manual for a Polaris submarine. Xcode is child's play in comparison.

Off to a good start

The other great thing about the various IDEs is that there are loads of tutorials and “getting started” guides. Going from a bare-essentials installation of the IDE to running your first program will take you 15 minutes or less. In fact in most cases you can run “Hello, world!” or similar by creating a new app from a template without writing any code yourself. That really is impressive.

All great so far, then. So what's the catch? Well, writing decent applications is not a simple task. There is more to it than drawing a few GUI objects in a pretty design window on your PC or Mac.

There is a pile of documentation for each of the offerings detailing how to use the IDE, describing the various libraries and system calls and so on. The documentation doesn't teach you how to write efficient code, or how to write properly in the various available languages. You will have to learn that separately.

Which brings us to the development language you use. For iOS you have a choice of good old Objective-C, or the newer Swift which is kind of a derivative. They are both C-like but also sufficiently different that it takes a little while to get used to them. Of the three platforms it is probably the least like what the average developer is used to.

In the Windows world you have the standard .NET choice of C# and Visual Basic. If you are used to full-fat Windows development you will probably find yourself thinking the mobile version feels cut down, though Microsoft will point out that it still acts as a common language which can still reach up from the handset to the back office.

On Android, Java is the way to go. Because the developer kit is Eclipse-based the IDE should feel familiar to any of the bazillion users who have used this for bigger Java development tasks.

The golden rules

We have established that all of the platforms are pretty simple to get up and running, and that (quelle surprise) to do effective software development you will need people with software development skills. You will need a few other things as well, though.

First is the ability to read the vendors' GUI guidelines. There is a reason why all good iPhone or Windows Phone or Android applications look similar and hence have transferable usability properties. They have been written by people who have read the vendors' guidelines on how to present things, what to put in the standard menus and so on.

Read and digest the design guides and make your Windows Phone aplication, say, look like a Windows Phone application. Think of the desktop apps you have come across over the years and recall the ones that you hated most: they are the ones whose developers thought their way of presenting the GUI was better than the vendor's.

Secondly, as you would for desktop applications, build yourself libraries of common code and re-use them wherever you can. Never code the same functionality twice, and let version control underpin your development cycle so that you can always roll back to the previous version if you screw something up royally.

Thirdly, you need design talent. I can write, say, an effective Windows application if it relies on windows, menus, dialog boxes, radio buttons and the like. The design guidelines tell me how to do it and the IDE's cool design features make it idiot-proof to align things correctly.

But I am graphically challenged. Ask me to design an icon or a logo or to make a phone-based app that has the look and feel of my company's funky web site and I'm stuffed.

Fourth, you must have a test regime. If you are building a corporate app there are two possible audiences: your staff, who will berate you hideously if the app is difficult to use or is as flaky as a flaky thing; or your customers, who will moan about you on social media if the app doesn't do what they want. Lack of testing equals shonky apps.

The fifth but by no means least thing you will need is a policy dictating which platform(s) you develop for. If you are writing for internal users then you have some level of control over the range of devices you have to support. If you adopt a single platform as the corporate standard then you have only a single device to develop against.

If you are developing something for customers to use then in an ideal world you would support all three platforms, but since there is no single language that works on all three you find yourself having to employ either multi-skilled developers (a scarce resource) or more bodies, each of which has more focused skills.

You might well decide that priorities should follow market share. Whatever you decide, it is better to do fewer platforms well than to do all of them shoddily.

In a nutshell

If you want your customers or staff to use applications on the move, give really strong consideration to writing apps for their mobile devices.

Leaving aside the fact that any kind of software development requires skills in software engineering, modern IDEs are gobsmackingly easy to get to grips these days.

It is genuinely realistic to consider writing your own applications and you will be able to achieve a remarkable amount in a relatively short time.

Choose your platform(s) carefully, make sure you underpin development with version control and proper design and code control, and go for it. You will be surprised at how doable it is. ®

More about


Send us news

Other stories you might like