The Mobile Programming Dilemma
Mobile apps are the new, hot thing. Â Developing an application for a mobile device, be it web based or a native app, is where the industry is spreading out. Â Why? Â Because it's a chance to literally live in someone's pocket, and that is real estate most marketing companies want. Â But how do you do it?
There are five mobile platforms: Â iOS, Android, WebOS, Windows Phone 7, and Blackberry. Â And each one has their own programming specifications: Â iOS uses Objective-C, Android uses a version of Java, WebOS uses HTML5 and CSS, Windows Phone 7 uses Visual Studio, and Blackberry uses Java. Â So which do you learn, and how do you know what platform to use?
Ideally, you would want to develop for all platforms, but that's not always possible. Â That is especially true if you are the only developer. Â So, you need to start hedging your bets, and develop for the most popular platform. Â That takes you down to either iOS or Android. Â You could also use a development SDK like Titanium from Appcelerator or Corona, and do cross-platform development, but that's not a good idea. Â Let me tell you why.
If you develop for a cross-platform environment, you need to develop at the lowest common denominator. Â That means, instead of taking advantage of the hardware you are going to deploy to, you have to make exceptions which will dumb down your app. Â For instance, while most mobile devices have the same hardware specifications, not all have a Gyroscope (like iPhone 4 and iPad 2). Â Maybe you are going to be deploying to a device with a wide-screen display (like the Motorola Zoom), but you can't use that if you are also deploying to a 4:3 display (iPad, iPad 2). Â This is just an example, but it shows you some of the problems with developing cross platform. Â Then there are the issues with software optimization.
Sure, you may be able to compile your code easily with an SDK, but often you get a performance hit which will make the app perform poorly. Â For instance, your animations may drop from 60 frames per second to just 10, or just 3, depending on the platform to which you are exporting. Â That's a problem, and not one that is easily surmountable. Â There are exceptions to this rule, but in general this is true for most development tools out there.
So what is a developer to do? Â That is the dilemma I've been at for months. Â There are a lot of great platforms out there, and I want to be able to develop for as many as possible. Â SDK's provide a means to the end, but they are not ideal because they code for the lowest common denominator. Â For me, that means picking one platform, or at least one programming language, and sticking with it. Â And, because of my biases, that means programming for iOS.
There are lots of reasons to focus on iOS, but the main reason is that I own several iOS devices, and not any android devices. Â I know the specifications of iOS devices, and can only guess at Android devices. Â And I know the iTunes App Store very well. Â So that is where I would place my money in development.
But what about Android, you ask? Â Yes, it is a very viable platform (assuming it will survive the current legal battle with Oracle for stealing Java code), and I think I will eventually start programming for it, when Objective-C libraries are included in the Android SDK. Â But that project is still in it's early development phases, and I'd rather develop for just the one platform.
So that's my take on mobile development. Â Others will probably say developing for Android is the ideal way to go, but for now I see it as something for future plans, and instead focusing on a platform with which I am already familiar. Â That, and I have to say I was influenced by my visit to Cupertino for a Faculty and Student iPhone Programming seminar. Â ^_^