Ask HN: If learning to develop for iOS- start with Obj C or Swift?
It seems like it's an awkward time when Swift will definitely take over, but the environment around it may not be mature. My ios friends seem split on the matter.
Swift is way more complicated than Objective-C, even if the syntax may seem a lot more familiar if you're used to certain other languages.
The reasons for this complexity are manifold: static type-systems of the sophistication that Swift is attempting are complex. Even if Swift were stand-alone, had an all new class-library (or non-class library as it may be), there is quite a bit of complexity there.
However, Swift is not stand-alone. It has to interoperate with the existing Objective-C class libraries. That alone would also not be a problem, had Swift's designers not chosen to go in a completely different direction from Objective-C, both syntactically and semantically. So while they did an OK job in wrapping the libraries, there just is quite a bit of fundamental mismatch that's just waiting to bite you. A small example are force-unwrapped optionals that you get out of a lot of the library calls (because nil ptrs. are OK in ObjC and Cocoa), which will blow up when you use them, without the compiler warning you! (So much for safety).
As other posters have pointed out, you will need to learn Objective-C to make sense of things.
On the other hand, Apple will push on Swift hard, and with the faddishness of the industry being what it is, you might find Swift skills in much greater demand, even if it doesn't actually make sense from an objective standpoint.
Finally, while Swift currently is completely proprietary, Objective-C actually does have non-Apple implementations and users on Linux and Windows.
but it does from a swift standpoint ;)
It can be used to do more complex things if you want to do functional programming, but to do the same things in the same way, it is less complicated.
The weakest point is the lack of examples and documentation.
The lack of Linux and windows versions is irrelevant. Although there are open-source implementations of Objective-C, there is no open-source equivalent of Cocoa, so the experience is barely transferable.
You certainly will end up learning a lot about objective-c in order to work with Cocoa, but learning Objective-C first will be a waste of time, since once you know Swift, you will barely ever touch Objective-C.
And sure you can whip together a simple app using all the documentation and tutorials out there for objective-c. But objective-c has a lot of gotchas that make it easy to do bad things as you start to build a larger app. Like retaining self implicitly because of an ivar in a block... Can't tell you how many times that is bitten us.
That being said, have you tried to use Swift with the core foundation framework? Yikes. I spent hours yesterday trying to understand how to simply pass a pointer to a function. The type was something like CMutablePointer<Unmanaged<SecKey>?>. Hopefully it'll get easier as the documentation improves though :)
Block syntax, a ludicrous proliferation of __keywords and @keywords, the verbosity of GCD calls, all of it makes modern, complex Obj-C apps harder and harder to write.
In a lot of ways Swift is a reset. It offers a lot of the things we want from Obj-C/Cocoa (e.g., more block-based everything) in a clean syntax that was designed from the get-go to support it.
One of the complex bits of Swift right now is that the APIs haven't been ported. UIButton still expects targets and selectors (ugh), and an innumerable number of API calls still rely on the only C-style way of passing error pointers into calls to see if they get filled (and necessitating the idiotic NSErrorPointer class). A lot of the complexity of building in Swift right now is shoehorning Obj-C style APIs into Swift code.
So I'd agree that a reset is a good idea. However, Swift pretty much represents the grafting-on approach. Even now, at the start, Swift is already more complex, with more special cases, than even grafted-upon-grafted Objective-C, let alone Objective-C as it started out.
That doesn't mean that there aren't a few things that are handled nicely, but overall it's a bit of a mess already, because of the insistence of stuffing everything into the language and compiler and having everything checked statically (except that it only pretends...).
"If you focus on just messaging - and realize that a good metasystem can late bind the various 2nd level architectures used in objects - then much of the language-, UI-, and OS based discussions on this thread are really quite moot."
-- Alan Kay (http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...)
This is not to say that it's correct because "Alan Kay", but to show a very different approach to language design that is, IMHO, much more powerful and durable than special-casing all the language-fads-du-jour into the compiler.
If you go back a bit and see where Objective-C came from, it was the desire to have Smalltalk, but with better performance and better C interoperability. So an obvious reboot of Objective-C would have been Smalltalk based, with C interop moved out of the base and better support for architectural interconnect. A real "Objective-C without the C", unlike Swift, which is more "Objective-C without the Objective-".
This is such an obvious thing to do that there have been several community projects, including, but not limited to StepTalk, FScript, Pragmatic Smalltalk and my own Objective-Smalltalk (http://objective.st).
In fact, Objective-Smalltalk was in part inspired by Alan Kay's work as expressed in that message: focus on the big things, get the right meta-system in-place, the rest will take care of itself. (here's my response: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-... ) As such, it Objective-Smalltalk isn't trying to be yet another Smalltalk implementation, but rather a new approach in the spirit of Smalltalk: identify the next bigger thing to handle (we now have the Web, for example) and then scale that down so it can handle everything else as well. I think I'm on a good road of achieving this, Higher Order Messaging and Polymorphic Identifiers in combination already handle a lot of what you need, in a user-extensible, late-bound fashion, governed by a very simple and powerful metasystem.
Starting with any of these Smalltalks (or a separate development along similar lines) would have been an easy road towards the goals that Swift aspires to, even considered by itself. When you add interop with the current class libraries, which are simply at odds with the Swift approach, it becomes a no-brainer.
Care to elaborate? I get that an ObjC method potentionally returning nil would result in an optional on the swift side, but I don't really get how the compiler doesn't warn you the same way it would with anything else with Optional semantics. (ie. it's nullable.)
var superview: NSView! { get }
var view = NSView( frame: NSRect(x: 10, y: 10, width: 300, height: 100)) -> NSView
view.superview -> nil
For example, some sample code to call a method (here, one named 'upCommand') whenever the user swipes in the 'up' direction looks like this:
let upSwipe = UISwipeGestureRecognizer(target: self, action: Selector("upCommand"))
upSwipe.numberOfTouchesRequired = 1
upSwipe.direction = UISwipeGestureRecognizerDirection.Up
self.addGestureRecognizer(upSwipe)
However, because of the way Objective-C and Cocoa works, you need to define the target of the action as a string literal describing the method name, encapsulated in a 'Selector' object. This is a fundamental Objective-C feature that shows up as a common idiom in the Cocoa APIs. If you didn't know what a selector was, you might have trouble translating this API into working Swift code, since Swift has no real equivalent construct (except the 'Selector()' class described above, there only for backwards compatibility).
To answer your question, it really depends on your goals. If you're looking to write your own apps, and you're not under any time pressure, I'd say start with swift. Apple will push the adoption curve _hard_, they always do.
If you're looking to get a job as an iOS developer in the next year or so, Objective-C isn't going anywhere. Big organizations in particular will not be rewriting their apps from the ground up, and there will be legacy code to maintain for years to come. I know of some big projects that were still avoiding ARC for quite a long time...
No matter what, I'd learn Swift _now_, but if you can spare the time I'd say do yourself a favor and learn both. Objective-C has a lot of great concepts, and they're totally worth learning. And it will make understanding the Cocoa and UIKit frameworks a bit easier as well.
Good luck!
Sure, Swift might be better. One day you'll probably learn it. But 99% of the effort in learning Objective C is learning all the frameworks and libraries, and the support to do that is much better in Objective C (at present).
If you already know Objective C, and a looking at starting a new project, Swift might be better. The lack of Swift-specific resources won't hurt, because you should be able to easily translate them from one to the other. But if you don't know either, I'd start with Obj-C.
I think that you should learn Swift because it is where most app development will be heading in the future and far easier to pick up than Objective-C. The main disadvantage currently is that the whole corpus of knowledge about iOS development is steeped in Objective-C. My advice is to learn Swift and develop in Swift, but know enough Objective-C to be able to translate it to Swift and read documentation written for Objective-C.
Eventually as the corpus of knowledge in iOS development grows for Swift, this won't be as much of an issue.
The Swift tools aren't mature yet - on Friday I managed to get llvm to segfault on multiple parts of my codebase. Rewriting the same thing in slightly different syntax fixed it.
The code highlight/autocompletion service also crashes frequently, as does Xcode in response to certain pieces of valid code.
Not only that, the amount of Googling you can do with regards to any kind of problem is roughly zero right now. People are still figuring things out, so the amount of help you can get is very, very limited.
Once Google/Stackoverflow fills up more, and llvm stops fucking crashing on perfectly valid syntax, you can switch to Swift.
Can you wait 6 months to start? How comfortable are you with functional programming and type theory? How comfortable are you with C/C++? How tolerant are you of buggy/constantly crashing software?
In 6 months time the answer will be Swift in my view. It is a better language and has nice strongly typed features to help make robust code.
However at the moment you have to put up with a buggy implementation and a development environment that is likely to crash every 30 minutes or so taking unsaved edits with it (this is not a complaint it is an Alpha/Beta release and the first release). It does make developing more of a chore. Plus the fact that the language may change itself in the coming months (and in places like the arrays I hope it does). Given all that I suggest waiting and doing something else in the meantime.
If you are familiar with C/C++ I would dive in with Obj-C and start getting to know the libraries you will need for your project and you can start adopting Swift when you are ready.
If you don't currently program or are used to dynamically/duck typed languages like Ruby and Python I would try some stuff in something like Haskell, ML or another strongly typed language that will get you used to type theory and how to programme in that sort of strongly typed environment within a stable environment. I think that would make it easy to pick up Swift when it is a little more stable.
If you already have a good background in functional programming but not so much in C/C++ it might be worth braving the instability to use Swift to learn the Cocoa touch libraries and explore. The Playgrounds are very cool but VERY unstable at the moment, maybe there will be a better release tomorrow.
I'm not an expert ObjC hacker, but if you already know C++ and have done a little UI work in something before then you shouldn't have much trouble.
Once I got over the hump (mostly weirdness with terminology and window manipulation), the XCode environment feels quite nice, comparable to Visual Studio with the Whole Tomato plugins.
Next up: Android. Hmmm.
I wouldn't say it's a simple transition, even if it is a superset. You can get away with writing a great deal of an iOS app without doing much in C proper at all.
Coming from a C/C++ background myself (and Java) I found it pretty straight-forward to learn. It wasn't free, but not too bad either. And I'd argue they've fixed most of the annoying things these days (synthesize was my biggest annoyance, never could understand why that couldn't be automated as it is now).
The documentation on Cocoa is still sparse, and you have to use a lot of Obj-C interfaces, so it feels like you're a level up too high; it's backwards, but better than not learning it at all.
On the other hand, if you are looking into doing it professionally, it doesn't seem possible to build complex iOS/OSX apps right now without knowledge of Objective-C.
3 years ago: Core data ordered sets looked perfect for my use case and then proved buggy. The kicker was a year later when iCloud managed document integration came along ordered sets were not supported (and they still aren't).
2 years ago: The above iCloud support was introduced and I was probably saved by the lack of support of ordered sets and their use in my code because for the first year iCloud was very buggy and problematic (see numerous blog posts). The major iCloud announcement at WWDC the following year was basically "no new features but we've fixed the bugs and added some testing tools" and they got a big round of applause. Autolayout was introduced (I think) which again excited me but I think my experiments with it in interface builder basically failed so it didn't make it into my app.
1 year ago: iOS7 being introduced encouraged me to adopt Autolayout. At least up until the release of iOS7 and Xcode 5 there were some pretty major problems building Autolayout designs which caused me issues. Even the current release Xcode has some issues that I recently needed to hack the XML file to work around[0].
This year it remains to be seen what level of stability is reached by the release time. At least there is no need to release product with a new design like there was last year so maybe I should be waiting for a more final release before trying Swift but I'm giving it a go. I might even try to release some Swift code in my product before the final release (by creating a framework and including it from Xcode 5) but I'll have to test it well.
[0] http://blog.human-friendly.com/hacking-constraints-in-storyb...
Good luck and have fun!
That's what it'll feel like when you try Swift after learning Objective C.
Longer answer: Swift is the future, so if you have to pick exactly one of the two, pick Swift only. But Swift is, along some axes, an evolution of ObjC, and you will learn much by getting what you can from the wealth of ObjC/Cocoa/CocoaTouch material that's already out there, then applying it to Swift.
For shipping, prototyping or production work, you cannot live without some of the stuff from the community. Cocoapods, testing frameworks, AFnetworking, Reveal there's a lot. All those are obj-c and it will take some time for Swift to catch up.
But in the end you don't have to become an Objective-C pro. Once you feel comfortable using the language, you could start focusing on Swift.
Investing scant resources (and your time and mind-share are among the most precious you have) in a technology before it has developed a following, third-party support (tools and libraries), a viable user base, and the resources to educate yourself and others is a significant gamble. Sure, you might win. But you probably won't.
I personally think starting with one of the WebView wrappers is a better place to start, as it gets you used to the toolchain.
For me personally, I'd be more concerned about someone in your position trying to learn Swift now because it's an incredibly immature language. Core language-level changes IMO are the hardest to cope with, as they can have a severe impact on code written in a previous version of the language, not to forget how much of a mental cluster-f!#@ it can cause.
I also find it pretty easy to convert Objective C code (from tutorials/StackOverflow) to swift, in particular with the help of auto-completion. So in my opinion (from someone who just started, so take with a grain of salt), I would definitely suggest Swift
That said, Swift isn't production-ready yet, and there's not a wealth of books and documentation, but it's very, very likely the future of iOS and OS X application development.
* be safer and reduce bugs * be more concise to increase productivity * be easier for the compiler to optimize * introduce functional programming constructs to make algorithm development easier
Objective-C is weak in all of these areas.
Give the Swift book a quick read in a month or so, so you are familiar with the differences. Perhaps start thinking of Swift in August.
0) easily very cross-platform (but you will have to pay), mainstream in mobile games via Unity3D;
1) not locked to one company: .NET by Microsoft, Mono by Xamarin;
2) open-source and welcoming feedback;
3) modern and innovative (not like Swift, but for real - introducing stuff like async/await, mixed dynamic/static typing etc.);
4) allows building mobile, web, desktop, butt software today;
5) first-class IDE, that will get an extensible compiler-as-a-service in 2015;
6) best in class automated refactoring via ReSharper.