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.
Another Dice post...
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
Also RoboVM 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
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.
Anywhere Software 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.
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.
Qt 5.x offers IOS / Android and Windows Phone App development
Qt5.4 supported platforms
The Python multitouch framework Kivy is quite nice for anyone that's looking to possibly do cross platform apps.
You get the highest performance app if you build directly using ObjC for iOS. But your application is then not portable; if you don't care, fine. If you do care, you have to look at the alternatives, which vary in more than just price-point. Consider performance vs cost of development and QA and maintenance (for multiple platforms) vs price of development tools vs. flexibility of the tools vs. low-level hardware access. Among other variables one could name. Our offering in this getting-to-be-crowded field is '8th' (8th-dev.com). The apps it produces are faster than Corona/PhoneGap, and (in our opinion) easier to code than Xamarin et. al. Not to mention that we are less expensive than our serious competition.
@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.
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.
... 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 world has moved on.)
So I recently spent a day remaking an iOS app in React Native that I had spent a week writing in Swift. (in both cases, probably 90% of the time was learning & reading docs than actual coding). So React Native is Facebook's development tool for writing native-feel iOS apps using Javascript. Basically, Javascript runs on iOS and interacts with a native library mimics their React.JS framework. It provides a sort of HTML-like syntax and CSS styling for designing your UI. The key selling points with React Native vs others is that UI interaction is kept silky smooth in it's own thread and rendering happens in a native view, not in a browser webview instance. React Native is still very beta and it's docs seem to assume some familiarity with React.JS. Xcode only just builds the framework and starts it, and by default your actual program in Javascript is fetched from a local webserver (npm start). This allows you to edit your code and quickly hit 'control-r' to reload changes and rerun. When you're finally done, you bundle your Javascript with the app. React Native won't replace the flexibility of native development and Apple's Swift has made iOS (and OS-X) native development much easier but you still need to learn iOS APIs and concepts like UI constraints. React Native lets you just deal with UI in terms of hierarchies of rows and columns that can resize or not, yet you can still create an app of the style of Flipboard or Flickr's.
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"
Well done the alternative to developing on iOS is not developing on iOS. If you are developing on iOS and use another language, say ObjectiveC instead of Swift, you are using a different option.
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.
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 5 MB.
The neat thing about web apps are the following.
1. They work on multable mobile devices.
Unless Apple refuses to implement a feature of the web platform that is vital to your application. Users of Safari couldn't upload pictures or video until iOS 6, Safari had no WebGL support until iOS 8, and IndexedDB is horribly broken. Even in the current version, does it support uploads of data types other than pictures and video?
2. You can update and upgrade automatically.
Which isn't always a good thing. They might want to use the old version in order to avoid defects that the new version introduced. Or they might want to run their own copy of an application in order to avoid sending their confidential data to a web application operator in a different jurisdiction. See also "Who Does That Server Really Serve?".*
* The author and publisher of that essay find iOS abhorrent for other reasons.
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?
i'm really happy that someone has mentioned Delphi as a viable development platform for anything. I've been working with it for the last 15 years, and it's a great language. Glad to see someone is pointing out the fact they went cross platform with the latest generation of the product.
A and B in your post are alternatives.
Missing option is referred to whenever /. does a poll. This article on Dice's /. refers to a Dice article which uses alternative incorrectly pluralized where they mean options and I believe the original post was making that point.
Anyone with mod points the above post does not deserve to be hidden because of an incorrect understanding of the parent.