I’ve seen and heard a lot of discussion about how people build applications for mobile devices. While there are literally hundreds of thousands of apps out there for Apple, Android, Blackberry and other smartphones, I can’t help but think the majority of these are one-off efforts. In this series in the blog, I’m going to tackle some of the issues with developing mobile apps, especially for enterprise use, and along the way propose some ideas for making the process easier and more repeatable.
I’m going to start this series by discussing the basic concepts of how you might develop an application for a smartphone or a tablet. I’m scoping it at this high functionality level and not looking at feature phones, at least not right now. I’ll use Apple as my primary example, but things are similar for other devices and mobile operating environments.
If you have an Apple iPad or an iPhone, many of the apps use the native software development kit, or SDK. It is available from Apple’s developer website and contains almost everything you need to start creating apps. Like any software you plan to use, make sure you read all the legal terms and conditions before you agree to them. If you work for a company, make sure your manager and local attorney also agree that you can use the SDK. This goes not only for Apple, but for Google, Blackberry, Microsoft, Samsung or any other SDK provider.
Most native apps on Apple devices are written in Objective-C, an object-oriented language. If you’ve developed software using C++, C#, or Java, Objective-C might take some getting used to. If you are comfortable with SmallTalk, however, it should seem much more familiar.
An Objective-C application is developed using the traditional write-compile-link-run-debug iteration, though the Apple XCode environment is quite powerful and makes this loop straighforward. Nevertheless, it is not a whole lot different from what programmers did 10 or 15 years ago. Objective-C is not a scripting language, is not interpreted, and on mobile devices you need to do your own memory management.
That said, when you create an app with a native SDK, you can use the very best and most powerful features on the device. You can optimize your app as much as you want and you have maximum control. This is very important for many software engineers. The app will be as functional, as beautiful, as secure, as bug-free, and as fast as you and your team can make it. It may also take you much longer to develop the app because you need to do all these things yourself.
Yes, the SDK makes your life easier, but it is still the case that when you go the native route you need to do more of the basic development yourself.
Here’s another important issue: if you write an app using a native SDK directly, you will essentially need to completely rewrite it when you use native SDKs for other devices. I say essentially because you may be able to write some of your apps non-UI program logic in C++ and re-use that for Apple, Android, and some other environments. There are some additional but similar tricks available.
To be on the safe side planning-wise, if you decide that you need to support multiple devices and you are using the native SDKs, assume that you or someone else will rewrite the app as many times as necessary to get the broad support you need. It is not uncommon to develop the first app for the iPhone and then outsource the creation of versions for other devices based on the original reference implementation. This can be expensive and time-consuming because you need a lot of people to get this done.
For some apps you will need to go the native SDK route for the reasons I stated above. If you do not have extreme requirements for look-and-feel, device functionality, or performance there are some other choices.
In future entries I’ll look are extending the native approach with libraries, something I call, oddly enough, “Extended Native.” I’ll also discuss the pure HTML5 web approach, and poke at the strange middle ground between Native and HTML5 called “Hybrid.” Tools that target multiple devices such as cross-compilers can also work, and I’ll get to them as well.
Next up: HTML5