Mobile developers across the globe have developed and released more than 650,000 iPhone apps, 400,000 iPad apps, and 600,000 apps for Android. Are you thinking about building an app? A key step in the process is choosing the right programming language, which depends on how scrappy you’re willing to be.
Make sure you’ve researched cross-platform app design and reviewed the common pitfalls of developing your app. Decide on your audience and what platform you’ll use, and then weigh your options to select a language.
What languages have you used to build your app, and why did you choose that one? Let us know in the comments.
Objective-C is the iOS standard, considerd the “correct” language, according to Stephen Kaliski, who works for NYC-based start-up Poptip. The iPhone — and all iOS programming for that matter — is written in Objective-C through Apple’s Xcode integrated development environment (IDE).
Advantages of using the iOS standard of Objective-C are the following: It’s high performance, so you get to make use of the phone’s actual functions, such as the camera. Plus, there’s a larger developer community that new app developers can reach out to for help. Additionally, coding your iPhone app in Objective-C allows the app to match the ‘feel’ of all iOS supported devices. “You can write universal apps which operate on both iPhone and iPad,” says Kaliski.
However, there are some difficulties with Objective-C programming. For one, the language is not necessarily easy to learn. Furthermore, some elements of Xcode are much different than your typical development process. Finally, Objective-C does not allow the app to be scaled to other platforms, such as Android phones or Windows phones.
On top of that, CSS and HTML, if used together, allow the separation between structure and filing, which some competing front-end capabilities have missed, says Robbins.
Ruby, apt for functional programming of web apps, combines utilities for a more streamlined development process. Robbins, who previously worked with Ruby, doesn’t necessarily see this as a positive feature. “One of the problems with Ruby is that engineers see a function that is built into a language, and they therefore think it’s fast — they don’t dig into the implementation of that function as a language,” he says. Robbins recommends using a third-party utility instead, for better all-around understanding of the app and its development. “When you’re using a third-party utility that you know is third-party, your natural skepticism is higher, and you’re going to look at that code and see what’s slow and what’s not. Ultimately you’ll have a better understanding of how exactly your application is running,” he says.
The creation of new languages and improvement of existing languages harvests healthy competition within the app world, a strength in the ever-developing industry. It is up to app developers to determine which language is right for them, always keeping in mind efficiency and functionality.