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?"
The one really good thing that has come out of the Apple fashion parade is objective C. Jobs' legacy isn't all the shiny fashion crap, it is this powerful and really rather beautiful language. This is from someone usually branded a Microsoft shill. If you want to write iOS/OSX take advantage of the native tools.
"Our opponent is an alien starship packed with atomic bombs," I said. "we have a protractor"
Learning the language itself is not that difficult. Learning the SDK and how things work in Cocoa-land is the important part.
For example, if you need to display a list of of items in a list, an UITableView will work the same regardless of your language choice. You will still need to understand the idiosyncrasies of working with UITableViewDelegate and UITableViewDataSource.
I would stick to Objective-C for the moment as there are more learning resources online.
I'm already getting barraged by headhunters asking for five years of Swift minimum for contracts now...
If you're just starting out you're going to be learning a lot, reading blogs, reading stackoverflow, and there is far more Obj-C out there than Swift now. So you since you want fast, not best, Obj-C is the correct choice for you. Not necessarily for everybody, but for you.
since you are already a C programmer and are talking about maybe moving to android at a future time. i would write as much as possible in C and just bind to the UI with java/objc/swift.
take advantage of what you know. build wrappers around the java/objc code you will need to you can easily transport that to whatever platform you are on as long as it binds with C.
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.
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.
This portends badly. You don't know enough about any of the languages currently in use on any platform, and your goal is "the fastest and easiest way to market?" The obvious solution is to give the job to someone else who knows what they're doing.
So, since that's not what's happening here (and any sane - and most insane - business would go that route), this is a case of "I've got a cool idea for a mobile app but I don't know anything about the platforms or how to code in the languages behind them, and I don't want to give any details about what its' performance and resource requirements are because someone might steal the idea." This is further borne out here:
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?
Why not just download the dev kits for Android and iOS and ask yourself if you can even understand the development documentation, the APIs, etc? The problem right now is yo don't even know enough to ask the right questions: you don't want to commit to something (objc vs swift) this early in your learning curve and then find out you made the wrong choice because you didn't take a month to pick up some basics.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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.
Adobe flex. Cross platform, works on everything.
Your choice then... to be good on the platforms you write for, or evenly craptastic for everyone. Cross platform equals lowest common denominator. If you want to put out apps that people will call good... do the extra mile and code for that platform.
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.
You say you're an experienced embedded-systems developer. Those are rare. Stay with that and get better at it. There are already a huge number of people grinding out appcrap, more than the app market can support. Soon there will be a glut of former phone app programmers, if there isn't already.
Try to get in on the back end of the "Internet of things". That crowd is overrun with appcrap people and has no clue about embedded.