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?"

Comments

Obj-C

[occasional_dabbler]

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.

Re:Obj-C

[occasional_dabbler]

I grew up with Fortran, C was a revelation and obj-C was an epiphany. C++ was, of course, a heresy...

Re:Obj-C

[taharvey]

Anyone who says 'X' language is crap, can safely be ignored.

Unlike our previous poster, though My opinion is that Java, is actually one of the least useful languages out there. It doesn't provide a higher level syntax than objC or C++, like the "better languages" Ruby, Python, etc. Nor does it provide the performance or memory footprint of systems languages like C, C++ or objC. It is bound by a runtime, that is meant to make it run-anywhere. Yet ironically the universal crown is going to javascript+HTML5, not java. Java in many ways is the new pascal, it is largely an educational language with a strong base in corporate intra-net applications.

You can use c, objC & C++ for decades to come. However Swift is very exciting (and I'm a embedded guy). It is the first serious language to come along that can challenge the C family of systems languages that I can remember. It has all of the native performance of C, the memory footprint advantages of reference counting, all of the syntactical goodness of ruby or python, the inherent parallelism of groovy and haskell, yet can morph into a JIT language in development with a very enticing hot-coding environment. With Chris Lattner & Apple backing it, it will be successful. I can't wait till it filters down to the open source space so I can use it in embedded systems.

Re:Obj-C

[dottrap]

Agreed. And for the op, Obj-C is the best language to use right now. Being well versed in C means he can learn Obj-C in a day. Obj-C is a very small superset of C.

The hard part is learning Cocoa, but that is true of any framework whether that is Swing, Android, MFC, GNOME, Qt.

Swift is so new, you will have to learn Obj-C anyway to learn Cocoa.

The best bet is for the op to write model/cross-platform code in C, and then use Obj-C for the native UI layer. Then repeat for Android/Java (via JNI) and Windows Phone/C++CX.

Re:Obj-C

[maccodemonkey]

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.

Re:Obj-C

[Jeeeb]

Unlike our previous poster, though My opinion is that Java, is actually one of the least useful languages out there. It doesn't provide a higher level syntax than objC or C++, like the "better languages" Ruby, Python, etc.

Java doesn't provide a higher level syntax than C++/Obj-C but it does provide a much more easily parsed syntax. The result is lightning fast compilation, sane compilation errors and excellent tooling support. Auto-completion, powerfull refactoring, background compilation and powerful lint tools make for a very productive programming environment. Even C# doesn't have full proper background compilation yet. Intellisense is close but there are whole classes of compile time errors that it doesn't pick up.

Similarly stability has done a lot for the language. Java is one of the few languages were I'm confident that I could build a project I wrote ten years ago with no issues. C++ on the other hand... ugh! Just last week I shifted a project from VS2012 to VS2013 and had spend an afternoon fixing random code breakage because MS broke their Chrono libraries and their retarded compiler gave errors in the template definition in their header file rather than the actual lines breaking compilation. Not to mention the ball of fun that was trying to get the latest versions of our dependencies to compile... Fun stuff like the 64bit build for some reason produced 32bit obj files... In Java land I add a line to Maven or for Android drop a library in the libs file and add it to the dependencies... Presto, nothing more to think about.

It's also a very readable proramming language imo. Packages=directories and one public class per file make navigating Java code very easy. Types are obvious and code is simple to follow. I've worked in C++,Java,C#,Javascript,Python and also on my own time in C and Haskell. Out of those I'd say Java and C# easily have the best readability. (For the record Haskell has the worst by far imo.)

It is bound by a runtime, that is meant to make it run-anywhere. Yet ironically the universal crown is going to javascript+HTML5, not java.

I'm not sure if that is ironic. The Java runtime brings other benefits than cross platform compatibility. If I dereference a null pointer or use an index outside of array bounds, the Java runtime will give me a nice error telling me exactly what the error was, which line of code in which class caused it and what the sequence of calls that lead to the error was. Try doing the same thing in C++/Obj-C. If you're lucky the code will be running on a developer machine and you can hook in the debugger and if the code isn't too heavily optimized maybe even get the line of code it occured on. If you're unlucky the code is on a production server/client system somewhere and your stuck trawling through a log to find the error. (For the record record Haskell easily takes the title of hardest to debug language thanks to lazy evaluation.)

Plus it's not like C++/ObjC have no runtime. For example, if you don't have the right VC++ redistributable installed, you'll get nowhere trying to run C++ application compiled in VC++. Their runtime just doesn't include a JIT compilation stage (for better or worse)

Anyway here's the tl;dr: Java doesn't have exciting language features but it does have excellent tooling, excellent readability and is one of the easiest languages out their to debug. That too me is way more valuable than exciting language features. I prefer C# but I'm happy to work in Java instead.

Re:Obj-C

[philip.paradis]

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World");
    }
}

Doesn't really matter!

[Anonymous Coward]

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.

Re: Doesn't really matter!

[dagamer34]

Ditto. Because learning the framework takes a LOT longer than learning the language and the fact that the framework was designed with Objective-C in mind, it is foolish to think that you will be able to write a pure Swift iOS app without knowing Objective-C anyway because there isn't enough Swift material out there for Google to find to solve your problems. And unless you *really* enjoy solving those problems on your own, you'd need to convert an Objective-C solution to a Swift one on your own, at which point you are basically learning both languages anyway. So I would say all new iOS developers need to learn Objective-C because writing a Swift-only app would be too painful otherwise. This all changes when The Big Nerd Ranch puts out a Swift book, but there's no indication that is anytime soon.

Five years of Swift minimum...

[Anonymous Coward]

I'm already getting barraged by headhunters asking for five years of Swift minimum for contracts now...

More help is available on Objective-C

[notthepainter]

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.

Objective-C, hands down

[tyme]

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.

Right now, Obj-C

[GrahamCox]

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.

Why are you in charge of the decision?

[BarbaraHudson]

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.

Re:They are wrong...

[dgatwood]

Don't listen to these ass clowns saying "Go with Obj-C". If they had any clue they would know that introducing Swift was the first step towards obsoleting Obj-C.

Here's why you should learn Objective-C first:

• There are billions of lines of production Objective-C code out there, and remarkably close to zero lines of production Swift code out there. If Swift is the first step towards obsoleting Objective-C, then the second step must be waiting fifty years for all the Objective-C code out there to get rewritten.
• Swift isn't finished. From what I've read, they expect to make syntax-incompatible changes. Although they plan to have translators to move old code forward, do you really trust automated translators enough to run them on huge chunks of production code?
• There's no assurance that Swift has staying power. Over the years, Apple has released bridges to many different programming languages over the years. Java? Check. Perl? Check. Ruby? Check. Python? Check. Now ask yourself how many of those bridges are still supported by Apple. If you only have time to learn one language, it should be the one that you know will still be popular in ten years.

• 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.