Slashdot Mirror
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."
or 5, but they're all weird.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
Why would someone recommend
DragonFireSDK
over say...
CoronaSDK
I don't know.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
You could of course a popular SDK that works on desktops as well. But who would do that?
-- Political fascism requires a Fuhrer.
I read the this article with distain. It is clear that the author hasn't tried any of these tools. Yes, Embarcadero's RADStudio and Delphi products are expensive. Yes, I have shelled out the yearly maintenance fee when my current employer wasn't a Delphi shop. Other than being a relic from the 90's, why?
The answer is simple - it works. Originally developed as a Windows development tool, it can now target iOS, Android and even OSX. Author doesn't address the latter. It has excellent database connectivity for both desktop and mobile. On the mobile platform, you can use SQLite or Interbase to Go.
Apps can be written which can incorporate wifi and/or Bluetooth to create tethered apps allowing seemless integration between desktop and mobile. It is easy to write apps that can use Parse or Kinvey to leverage cloud computing. And, if you know what you ate doing, you can leverage frameworks not already supported.
FireUI is not a framework, it's a tool built into the IDE so that you can design views and see how they adapt and look on other platforms. This is done using a crossplatform framework, under the hood called FireMonkey. I won't lie, it does add to the size of the app. You use styles (canned and custom) to change the appearance of the components. They have native looking control styles as well.
There are also 3rd party vendors, such as TMS Software or the open source D.P.F. components which ARE native code controls. They provide Delphi wrappers around the the frameworks. This eliminates the speed barrier imposed by the FM3 layer if it bothers you.
The beauty of this tool is the ease in which apps and full applications can be written. But, yeah, it's pricey.
AppMethod is a monthly plan for their tools.
Delphi used to have an amazing 3rd party ecosystem. Stupidity by management at Borland/inPrize clusterfuck killed Delphi in favor of their Java products. What java products? Exactly. Thankfully, there are still 3rd party vendors who provide amazing addons - just many have left and may never return in favor of C#.
REMObjects used to be a component vendor for Borland and provided a product called Prism which implemented their own dialect for .Net until they felt they got stiffed by Borland. They released Oxygene to replace Prism. They make great stuff.
No, I don't work for Embarcadero. I am a fan. And, if you want to develop vertical apps for, say, the enterprise, it's worth looking in to, But, the adoption rate is low in the US. Wish that wasn't the case.
@HarryCheung has tested mobile app by reimplementing the same app with 13 different languages. This includes C++ (fastest on iOS and Android), Swift, Xamarin, J2ObjC, Javascript & RubyMotion (slowest on iOS). All the code is available on GitHub for the community to improve further. Disclosure: I provided feedback on the posts but was not involved in the testing.
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Then you've got hybrid systems like Cordova. Code your UI and logic in HTML5, use native plugins with javascript interfaces to access the more unusual stuff.