Slashdot Mirror
Ask Slashdot: Swift Or Objective-C As New iOS Developer's 1st Language?
macs4all (973270) writes "I am an experienced C and Assembler Embedded Developer who is contemplating for the first time beginning an iOS App Project. Although I am well-versed in C, I have thus-far avoided C++, C# and Java, and have only briefly dabbled in Obj-C. Now that there are two possibilities for doing iOS Development, which would you suggest that I learn, at least at first? And is Swift even far-enough along to use as the basis for an entire app's development?
My goal is the fastest and easiest way to market for this project; not to start a career as a mobile developer. Another thing that might influence the decision: If/when I decide to port my iOS App to Android (and/or Windows Phone), would either of the above be an easier port; or are, for example, Dalvick and the Android APIs different enough from Swift/Obj-C and CocoaTouch that any 'port' is essentially a re-write?"
This is fading away. The better solution is something like PhoneGap. This lets you build mobile cross platforms apps in HTML/JavaScript.
Since Phonegap got bought by Adobe you are better off with the open source port of PhoneGap Apache Cordova.
Swift is still a very immature language, with lots of bugs in the compiler, rough support in the debugger and IDE, and the syntax isn't even set in stone yet (don't expect the syntax to settle down before Swift 2.0, probably some time in late 2015 if not 2016). There are a number of things that you still can't do in Swift (e.g. providing a callback function for APIs that expect a C function pointer), and you'll just spend a lot more time hitting your head against walls than writing working code. On top of this there are many more resources available for learning Objective-C than there are for Swift, and the pitfalls and corner cases are better understood for Objective-C than they are for Swift. As a bonus most of your instincts honed on C will carry over to Objective-C (while they are likely to lead you astray in Swift).
Swift is a really exciting language, and fun to play around with, but it's not ready for production work (yet). It will get there, but in the mean time you should stick with the established tools, which means Objective-C for iOS and Mac OS X app development.
just a ghost in the machine.
A lot of comments here saying how Obj-C is "ugly", and so forth. I wonder how many commenters are actually using it to any great extent, on a day-to-day basis, rather than have just looked at it out of curiosity for five minutes?
If you want to write an app now, Obj-C is the only sensible choice. Swift looks promising, but it's not ready. It's changing almost weekly and at the moment it's actually introducing bugs into the frameworks where none exist in Obj-C. If you want to live on the bleeding edge, go for Swift, but if you want to write an app, get it working and ship it out of the door, Obj-C is the only game in town today.
Once you get into Obj-C, it's a much more elegant language than it's usually given credit for anyway. Sure, it's old, but the runtime and compiler work put in in recent years makes up for many of its older roots. Manual memory management is not required, there is a dot syntax for properties and so on, so square brackets are not the only way to call getter/setter methods. As a pure superset of C99, it's easy for a C programmer to learn. It's also a small language. The real power lies in the frameworks, and that will take you far longer to learn than the language. Don't be put off by the superficial "ugliness" of Obj-C code, it isn't relevant. It's expressive and straightforward, and as a former C++ programmer, I also found it dramatically more productive when I first adopted it over a decade ago. It is possible to become fond of it, believe it or not. Whether the same eventually becomes true of Swift, only time will tell. Ignore the nay-sayers who have probably never actually used Obj-C in anger in their lives.
Using a text editor to write code for a device like an iOS device, that simply displays the weather or a stock price is so ... 1960s?
Well -- 1970's maybe. 1960's were more about drum storage and all that. Even in the early '70s, the 029 keypunches didn't let us correct typos -- you had to hold the "dup" key down to duplicate the bit you got right, and then carry on keying from where the mistake started. The 129's were much better, as they only punched the card after you finished the whole line.
Although come to think of it, I did write a nice simple weather app in 360/Assembler for a class in 1974.
No. Well...maybe. Actually, yes. It really just depends.
I was recently pondering whether my game engine (written in C++) should have it's native OSX back-end / interop written in Swift or Objective-C. From what I can see, for what I need to do, Objective-C remains the clear choice, at least for now. There's a lot of good documentation on Objective-C / Cocoa, as well as lots of examples for how to interop between Objective-C and C++. I haven't even been able to determine if this is possible with Swift after searching around a bit on the net. Interop with Objective-C, yes, but that's pointless for me. I don't see Apple obsoleting or depreciating Objective-C in the near future. There's a heck of a lot of legacy code in that language, and like you mentioned, it seems like Swift wouldn't even be a proper replacement at this point for everything Objective-C can currently do.
As with pretty much any other language-choice debate, you really first need to know what someone plans to do with it before you can make a worthwhile recommendation. All languages have strengths and weaknesses, so it's foolish to point to one without even knowing what you'll be doing. The OP first wants to know about "quick and easy" for which I'd probably recommend Swift, but then wants "portability", for which I'd recommend C (for him, since he knows that - personally I use C++) with carefully walled off interfaces to the GUI frontend, but *only* if the complexity merits such treatment rather than a simple port in native code for each version. Without any more info, I can't make a better recommendation than that really.
Irony: Agile development has too much intertia to be abandoned now.
It was my understanding that if you want "complete" control, you still need to use ObjC, and that Swift was for dashboards, things previously known as WebApps, and other lightweight situations where you aren't actually doing anything novel, just packaging an interface to a datastore or moving sprites around.
That said, Swift is just as good on inheritance as ObjC, and does garbage collection correctly (benefits of a CLR).
ObjC has been tuned to OS X/iOS, and if you write in ObjC, you should be able to make a single back end that's easily portable to OS X as well as iOS; Swift would be more for iOS only.
I really do like the real-time iteration available in Swift though.
That said, my opinion must be crap, because I'm older than Java too :D I still like Pascal and Common LISP, but wouldn't write a modern application in them (flashback to writing Avara mods in the 90's using ClarisWorks). Most stuff I write these days is in C or Python.
Oooof. So much wrong in a single post. Let's review....
Swift definitely does not do garbage collection. Obj-C actually had a garbage collector for a while (Swift never has) but it was optional, and support for it has ended.
What Obj-C has now is something called ARC (Automatic Reference Counting). At compile time (not run time) the compiler does a static analysis of the code and determines where it needs to add memory management code, and then quietly does so for you. This means there is no run time hit, and behind the scenes everything is still manual memory management. Sometimes you still need to hint to the compiler what to do (usually when trading pointers with C), but 99.99% of the time it just works.
Swift is built on the same runtime as Obj-C, so it inherits ARC. With Obj-C, you can turn ARC off and continue writing manual code, and I'm not sure if Swift allows the same, but it's the exact same behavior. Swift uses the same manual memory management functions as Obj-C in the background, while in the foreground the developer still writes without memory management. I'm not sure what this "benefits of a CLR" is you're talking about, as that's a term usually associated specifically with the Common Language Runtime of the Microsoft language family, but it's neither here nor there. Swift does not run in a VM (it's natively compiled just like C or Obj-C), and it does not have a garbage collector. (But the compiler will add your memory management code for you.)
As far as Swift being multi platform, Swift most definitely for sure runs on OS X, so the language choice has absolutely no bearing on what platforms you want to port between. I have a partially Swift project going on the Mac right now. Swift is definitely not iOS only. Beyond that, it looks like Apple will be working to open source much of it and move it to other platforms.
I'm not sure what this business is about Swift being for lightweight solutions. It runs on the same runtime as Obj-C, it's starting to be as fast as Obj-C, and it interoperates with any Obj-C code (as Obj-C will interoperate with any Swift code). Apple has never messaged that it's for lightweight apps, and developers aren't treating it that way. I still prefer Obj-C, but I'm not sure what that bit is about at all.
Sure Java exploded but it became the Honda Civic of languages while C is still around but Delphi is not.
The news of Delphi's death has been greatly exaggerated.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
I was very tempted by Xamarin but put off by the $$$. Is it as good as claimed?
My company got a few licenses for a project recently since our client wanted it done in C#.
From version 3 it has the ability to write cross-platform GUI code. The other option being to write Android/iOS GUI code seperately through C# mappings of their native apis. I wasn't responsible for trying the x-plat GUI part out but I do know that ultimately we were unimpressed and elected not to use it, instead developing for Android and later porting the GUI code to iOS. From memory it was just too limited.
It may be acceptable for routine business apps but then why not just develop them as a web-service and avoid the Apple-tax and pain of dealing with Apple's provisioning cluster fuck. (Seriously why do so many company's want to use iPads for internal apps? Distributing apps on them is a major pita)
The other pain point for us was third party libraries. In theory you can import jars and it will automatically map them to C#. In practice that doesn't work. We had to support mobile scanners with a laughably bad and somewhat broken API and broken default apps. I ended up writing an Android service to deal with all that crap. When it is time to add iOS support we'll have to write an iOS specific layer.. (iOS bluetooth access is too limited to directly access the scannner so that will probably involve treating it as a keyboard and capturing keystrokes...)
IMO. the real value is for Windows shops that want to utilize their existing investment in tooling/developer training, reuse existing core-logic code and/or write their core logic once in C#. For places like that it could be worth the several thousand dollars per developer.
Here's why you should learn Objective-C first:
Swift is designed to make it easy to build apps that include a mix of Swift, C, and Objective-C. Therefore, there's no reason to believe that it won't be possible to write fully capable apps for iOS and OS X in Objective-C for the foreseeable future. And even if, God forbid, Apple decides to be a bunch of a**holes and starts shipping a bunch of Swift-only classes in a reckless and desperate attempt to pressure developers to switch to Swift, you'll still only be a tiny bit of glue code away.
That's not to say that Swift isn't interesting. The ability to test code on the fly is certainly cool, and if Swift proves to be a long-term-viable language, I'd imagine it will eventually (over a couple of decades) become the dominant language for OS X and iOS development. However, there's plenty of time to learn Swift. If you want to start writing real-world code today, you're better off learning Objective-C, because there are orders of magnitude more examples, you'll be more likely to find employment (there's way more Objective-C code out there to maintain), and more people can help when you run into problems.
Ask again in five years, and the answer might be different, but for now, IMO, Objective-C is the clear choice unless you don't already know any C-based language, and probably even then.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Objective-C didn't "come out of" Apple or NeXT or Jobs. It was created by Brad Cox and Tom Love at ITT and Stepstone in 1983 and is derived from Smalltalk-80. Jobs just bought the company in 1995.
Nobody said Java was useless. I just can't think of why I'd use it over another language unless I had to. I'd either pick C/C++/objC for speed, or I'd pick Ruby/Python for efficiency, or I'd pick Groovy or Haskell if I was leaning functional... depending on my needs. I can't think of why I'd go in the middle. Seems like the worst of all worlds.
Rust and Swift are very on par languages attempts, with the exception that Swift also has a very nice compile time JIT and hot-coding environment. However, and this is crucial: Swift is beating Rust to the punch - and that is an important factor in languages. Swift had 200,000 devs download the language spec in the 1st 24 hours. That is probably 10x more than have ever downloaded the Rust spec.
Rust is still listed as experimental, as Swift is being rolled out to developers. The Rust team is still arguing over implementation, in an unfortunate design-by-committe kind of way. Rust has no killer-application driving it. Swift does. Swift is Driven by Chris Lattner, who has probably done more for the compiler world in the last 10 years than the next 25 guys put together (LLVM, Clang, OpenCL, etc). And Swift is backed by a huge amount of Apple dollars. Even the Original developer behind Rust has tipped his hat to the project. So Yeah, I expect Swift to rocket to the Top 5 languages in the next 2 years while Rust stays a academic plaything for many years to come.