5 Alternatives For Developing Native iOS Apps 54
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."
join iOS with this One Weird Trick (Score:4, Funny)
Application defined (Score:2)
I think the editors assumed that the majority of people would understand "app" as short for "application", or user-facing computer program. This usage was common by 2000 if not earlier, in any case several years before Apple's App Store debuted.
slashvertiment (Score:1, Insightful)
Re: (Score:2)
LOL Slashdot is telling us things we either don't give a shit about, or are already well aware of.
Re: (Score:2)
I'm glad to see things are finally getting back to normal around here.
Re: (Score:2)
LOL Slashdot is telling us things we either don't give a shit about, or are already well aware of.
Not to mention: if price were really their top consideration, they'd probably have included Rhodes.
Swift is ready (Score:5, Insightful)
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.
Re: (Score:2)
This. Xcode 6 has generally been a disaster, with 6.2 and 6.3 being the worst of the bunch by far. I've experienced almost nonstop crashes while trying to use the debugger, some literally just seconds apart.
I ended up downgrading to 6.1 because I couldn't usefully debug any iOS or OS X code in 6.2 or 6.3. It still misbehaves in strange ways every so often (bizarre bugs that truly defy comprehension, and are probably fixed in 6.2 or 6.3), but at least I can hit the step button more than about two or three
RoboVM for the Java Crowd (Score:2, Informative)
Also RoboVM [robovm.com] if you'd like to leverage your Java skills. Allowing you to target Android and IOS.
http://www.javaworld.com/article/2836880/java-ios-developer/robovm-beckons-java-8-programmers-to-ios.html [javaworld.com]
Don't do this (Score:2, Insightful)
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.
Paid placement story? (Score:3)
Why would someone recommend
DragonFireSDK
over say...
CoronaSDK
I don't know.
Re: (Score:2)
Sort of: it's a Dicevertisement. Nerval's Lobster is the sockpuppet that Dice uses to post its own stories to Slashdot (without any disclaimer that Slashdot is owned by Dice.)
Qt? (Score:3, Funny)
You could of course a popular SDK [www.qt.io] that works on desktops as well. But who [videolan.org] would [github.io] do [apple.com] that?
Re: (Score:3)
Yes, it's *somewhat* popular, but the apps have always been butt-fugly and never really looked native--even after they finally saw the gross error of simulating/re-implementing controls and went to native controls.
Re: (Score:2)
I doubt you have any clue which App is written with which tool/framework etc.
Re: (Score:2)
I doubt you have any clue which App is written with which tool/framework etc.
And, you're wrong about that. Java (currently) and Qt (haven't checked lately) both have tell-tale signs in the UI, things that are not correct for the platform (OS X) and that are distinctive. (Just two examples from Java: default buttons the wrong shade of blue, text in buttons positioned too low. Even after Qt switched to using native controls, there were dead giveaways in the look of Qt apps.)
Re: (Score:2)
We talked about mobil devices, not OS X.
And your claim about Java having the wrong colour or text position in default buttons I can not support.
Never noticed anything different. And my Apps I write myself are all in Java .
Regarding Qt, I have unfortunately no idea :D
Re: (Score:2)
We talked about mobil devices, not OS X.
The post I responded to:
You could of course a popular SDK [www.qt.io] that works on desktops as well.
As for this:
And your claim about Java having the wrong colour or text position in default buttons I can not support.
I'm sure it does look fine on Android, since for that platform it essentially is the native toolkit. But it does look wrong in many ways (default button was just an obvious easy example) on OS X.
Re: (Score:2)
As I said before: I don't see any difference in Java Apps on OS X, neither on 10.6.x nor 10.8.x or 10.9.x, running Java 6 to Java 8.
Perhaps you mean SWT based Java Apps (like Eclipse) that everywhere look like SWT ...
Sorry, did not notice you originally answered to a post that explicitly talked about QT/Desktop.
Re: (Score:2)
But who [videolan.org] would [github.io] do [apple.com] that?
A: You should NOT be giving the impression that either Google or Apple use Qt because you found a few independent developers how make apps for Android or iOS which happen to use Qt.
B: The OSX VLC GUI is written with Cocoa/Objective C, the only platform than I know is Qt is Linux.
I haven't used them much on Windows, but Qt apps on OSX are always a train wreck, nothing feels write, everything looks fake (because it is fake, all the controls are emulated), nothing lines up, and all look like a warmed over
Re: Qt? (Score:3)
"Native look and feel" is pretty much a bullshit argument. If it were important, web applications would never have taken off. The important thing is that a UI is attractive and functional, not that it looks exactly like the UI in other applications. Even Microsoft and Apple products often don't have "native look and feel" because they're pushing some new thing like the Ribbon.
b4i if you feel comfortable with BASIC (Score:2)
Anywhere Software [b4x.com] produces B4A for Android apps, B4I for iOS, and B4J for desktop Java. They all use a dialect of BASIC very similar to Visual Basic. The Android version, at least, compiles to Java bytecode and gives full access to the Android libraries, etc.
The first two are about $100 for a license and 2 years of updates, the third is completely free. There is a vibrant community, and the main developer is very active on the forums, answering many questions.
Clueless Article (Score:3)
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.
Re: (Score:2)
Stupidity by management at Borland/inPrize clusterfuck killed Delphi in favor of their Java products. What java products? Exactly.
Sybase. Power++. Same story. Sigh.
Re: (Score:2)
Glad to help. I would suggest you visit fmxexpress.com as well. Lots of articles and links to code for developing FMX apps for iOS and Android.
Developing components for FMX is a different process than for VCL components. Personally, I haven't had the time to delve into this area and, right now, more inclined to buy COTS until I have more time to really delve into styles.
Good luck.
Qt 5.x (Score:1)
Qt 5.x offers IOS / Android and Windows Phone App development
Qt5.4 supported platforms [doc.qt.io]
Kivy (Score:1)
The Python multitouch framework Kivy is quite nice for anyone that's looking to possibly do cross platform apps.
Re:It's a multivariate problem (Score:5, Insightful)
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.
Re: It's a multivariate problem (Score:1)
I think you really need to take a look at RADStudio or Delphi's FireUi and FireMonkey.
FireUi allows for the creation of a master view. Then, you can add/remove elements by target platform and/or screen size. You apply styles (which are akin to css3, I guess) and it just works.
Android requires the NDK as the produced code is not Java. Other platforms, the resultant binary is for the cup structure.
And, there are native code components as well. The advantage here is you can reuse your other code across pla
Re: (Score:2)
It's not just views. The entire design idiom is different:
13 languages performance tested on smartphones (Score:2)
native not required in most cases (Score:2, Insightful)
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 flavou
Why not web-app? (Score:4, Insightful)
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.
Offline use (Score:2)
Most of the apps for the phone are just basic forms that then connect to the Internet and get data back.
And many are not. For example, how easy is it to use a web app on an iPod touch or iPad mini that is away from its Wi-Fi connection? An offline-capable application can wait for an Internet connection to become momentarily available, sync, and then let the user view the data later even after going offline again. The HTML5 platform supports features for offline use, such as application cache, local storage, and IndexedDB, but I was under the impression that these were limited to some stupidly small size like
Requires users to own a device running "proper OS" (Score:2)
Say management requires you to make an application available to people who currently use iOS. Would it be more cost effective to A. make it for iOS, or B. make it exclusive to PCs and Android and ship an Android device at no additional charge with each copy of the application?
Cordova (Score:3)
Whatever the question is ... (Score:1)
... the answer is NOT Delphi. The only thing worse than Objective-C is an obsolete Pascal dialect no one uses. You do not want your code base in that. Plus the not-Borland Embarcaradaradado thing has turned the $50 development tool of the 90s into an expensive "enterprise" tool that costs too much. Ironic that Delphi's selling point in the 90s was how cheap it was. These days, the Borland ship has sailed and you don't want to be on it. (And I was a big Delphi developer in the 90s - I loved it - but the worl
React Native (Score:1)
Don't forget the other cost.... (Score:2)
Apple forces you to submit apps using the most recent releases of OSX through their proprietary "app loader"
Of course, the same thing COULD be accomplished using a web-based uploader, but that isn't the "Apple way"