5 Alternatives For Developing Native iOS Apps

Nerval's Lobster writes "]The simplest way to join the ranks of iOS developers is to learn Objective-C and/or Swift (the latter, while not quite ready for prime-time upon release, has gotten a lot better with its recent v1.2 update). But for everybody who doesn't want to go down that route, there are other ways to create native iOS apps. Over at Dice, David Bolton went through five alternatives: Xamarin, Codename One, Embarcadero C++ Builder/Delphi XE/AppMethod, RemObjects C#/Oxygene, and DragonFireSDK. (Three of the systems, excepting Rem Objects C# and DragonFireSDK, are cross-platform, as well.) His conclusion? "There's no shortage of systems for developing native apps for iOS and other platforms, but cost will most likely determine your choice. Other than the annual Apple developer fee, creating in Swift and Objective-C; with regard to [these alternative] platforms, Embarcadero is the most expensive."

Comments

slashvertiment

[sanf780]

Another Dice post...

Swift is ready

[SuperKendall]

People are shipping production apps with Swift. It works fine, the main lingering issues are more with XCode stability than the usability of Swift itself.

As I've grown used to it I favor it over Objective-C now, and I don't find it very hard to switch back and forth as needed for older projects or older code in the same project.

One thing I really like is a very layered syntax, where you can be pretty verbose and clear if you like, but also strip away a lot of symbology when that makes sense for more terse code.

Don't do this

[Anonymous Coward]

Don't do this. Use the right tool for the job, languages aren't that hard to learn (after the first).

You'll miss native APIs and be at the mercy of the developer.

Re:It's a multivariate problem

[dgatwood]

Here's the thing: No decent UI is going to be portable anyway. Every platform out there has its own idioms that users expect an app to obey, and no cross-platform technology will realistically conform to those idioms well enough to not feel out of place.

The only good approach for writing portable code is to get people who understand the platform to write a fully native UI, and to write all the underpinnings in a portable language. Share the model, and maybe share the controller, but don't even attempt to share the view. Therein lies the path to madness.

native not required in most cases

[Anonymous Coward]

I was involved in the development of a number of native mobile app, which usually involved extending other products to add a mobile option to tick a box. Without fail 4 out of 5 of them would have been better implemented as a pure web UI as they added nothing of value that required them to be native: No alerts, no offline functionality, no special networking or use of device features. It's mostly the case that management sais "we need a mobile app", "native is better", "do iOS first" or whatever the flavour of the month is.

Make it a mobile-first web UI for anything that does not clearly need to be native, immediately stop sucking.

Why not web-app?

[jellomizer]

Sure there are some apps that need more direct access to features. However I don't get why web apps are ignored?
Most of the apps for the phone are just basic forms that then connect to the Internet and get data back. This is stuff we have been doing on the web already.

The neat thing about web apps are the following.
1. They work on multable mobile devices.
2. You can update and upgrade automatically.