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.
Anecdotal evidence in favor of Objective-C (Swift wasn't around back then): at an early WWDC, a dev. who was completely unfamiliar with Objective-C finished his first Cocoa application during the "Intro to Cocoa" session, and spoke about his amazement during the feedback.
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.
Swift is strictly less complicated than objective-c for implementing Cocoa apps.
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.
Idk if I agree that objective-c is simpler to learn. I have been working as a full-time ios developer for almost 2 years now and I still have to consult fuckingblocksyntax.com on a weekly basis. And fully understanding objective-c's "message passing" idea is hard because it's so radically different from other languages.
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 :)
Yeah, this is one of the reasons why Swift exists. The base Obj-C that we started with was pretty simple and reasonably elegant, but over the years we've been grafted pieces onto it in decidedly inelegant ways.
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.
Yes, definitely. Objective-C was a lot more elegant before the odd grafting started, with everything hard-baked into the compiler and special cases added on top of special cases after the first special cases were found to be too special.
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."
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.
> 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).
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.)
I would suggest going with Swift, but learning enough about Objective-C concepts to use the Cocoa APIs. There is a guide to interoperability between the two languages on the developer site.
For example, some sample code to call a method (here, one named 'upCommand') whenever the user swipes in the 'up' direction looks like this:
A more idiomatic way in Swift to create a gesture recognizer might be to assign a closure to execute whenever the swipe is recognized.
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).
I've been writing Objective-C for a long time now, and have shipped a fair number of iOS apps. It's a beautiful language in my opinion, if you can get passed the syntax (harder for those who lack a "beginners mind" and are used to a certain way of doing things.)
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.
Objective C. When you need to figure something out, and Google returns 1,000 tutorials on how to do it on Objective C and nothing for Swift, you'll know why.
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.
Yes, I've just started down the iOS road and of course I'm sticking with ObjC for now; all the Stack Overflow questions and tutorials are for ObjC at present and I can't just adopt a brand new language. Eventually, I will, though; Swift looks pretty cool!
I used to help teach the iOS Development class at NYU - I was having this conversation with the professor who's teaching it again next year and we talked about this specifically for new students.
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.
Objective-C, though approach knowing that you'll switch to Swift.
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 learned Objective C in about a week (two days of reading, then three more days of trying stuff out).
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.
Boy, I considered myself pretty well-versed in C++ (and pretty good at C proper) and looked at Objective C like it was Delphi or something the first time.
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.
Curious what you found difficult? Maybe memory management and synthesize? The dynamic nature of Obj-C?
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).
I can offer anecdotal evidence in favor of Swift: I attempted to learn Obj-C in the past and gave up more than once, whereas this week I downloaded the XCode 6 beta and in an hour had my first app running.
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.
A +10 times WWDC veteran said to me that it usually makes sense to really start using new dev tools and APIs 1 year after their announcement in WWDC. Dev tools have matured enough and the latest OS version has had enough installs to make it worthwhile.
There is probably quite a lot of truth in this if the new features aren't things your product needs. I've only been doing iOS development for 3 years and while I haven't been to WWDC yet I have followed the videos. I've been bitten by things each year having gotten excited.
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.
Both. Swift should be your focus, but you need to know enough Obj-C to translate doc (hopefully a short-term problem) and you need to interop with Obj-C. Swift will be the more productive language, but will have a bigger learning curve (it is a bigger language, more concepts). Obj-C is not that hard to learn these days, a lot of the annoyances are taken care of for you (ARC, synthesize, etc.)
I know you asked a closed question, but would you consider Xamarin? This way you would earn more transferable skills (C#, multi-platform toolkit, etc.) and not lock yourself in one platform. You could also develop in raw C++ and have only a thin ObjC wrapper over it.
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.
I don't think that it really matters that much, they are not THAT different. The harder part about learning Cocoa is learning the how to structure the application and the APIs. You might have an easier time starting with Obj-C since there will be more learning material and more sample code that you can learn from.
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.
I think you do have to learn a bit of the basics of Objective-C. The sole reason being that most of Apple's frameworks are currently written in Objective-C, as well as most tutorials and example material. You'd have an easier time converting Objective-C code to Swift code if you understand the basics of Objective-C. You'd also have an easier time finding solutions to problems on sites like StackOverflow, which already has a wealth of Obj-C questions and answers.
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.
I, having been burned many times, have developed an allergy to the latest new shiny thing, especially if heavily promoted. The number of such things that have been successful are lost in the mass of those that have not. For every C#, there's a hundred Microsoft Bobs.
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.
Swift. All the code will move to Swift eventually, I predict that new APIs won't even be callable anymore from Objective-C in the future. I'm going to write all my code in Swift from now on.
I highly doubt that actually. Swift is not a replacement. There will always be glue between Swift and platform and system APIs. Swift only interoperates with Objective-C and (to a limited extent) C and not C++ (and a lot of APIs in Apple world are exposed as C++ especially on the Mac). Swift uses ObjC blocks and can't even handle function pointers. Unless there is a dramatic shift in the design of Swift, I don't see the writing on the wall that Swift is out to kill Objective-C, only complement it.
Learning a language is more than learning the official syntax. It's solving real problems, finding a community, looking up answers on blogs and Stack Overflow. To that end, I think the answer is definitely Obj-C, but it's not mutually exclusive. I think Swift is where C# was circa 2002 - it might be the language of the future, but back then there was still plenty of VB being written, and ditto for Obj-C.
I personally think starting with one of the WebView wrappers is a better place to start, as it gets you used to the toolchain.
I'd agree with some of the other commentors' sentiments voicing that you should start out with Objective-C, but less so because of immature tooling.
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've just started looking at swift since it was launched, and making really good progress so far. Having coded in Ruby, C#, C++, and C, I really enjoy and "get" swift as it's leveraging the strength from all these languages.
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
It doesn't really matter, in my opinion, because the major learning hurdle generally isn't the languages, it's the Cocoa frameworks. Experienced programmers can pick up Swift or Obj-C in 2-3 days. The frameworks will take you considerably longer to feel comfortable with.
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.
Actually you don't have to learn Objective-C or Swift.(http://www.smartface.io/ios8/) With "Cross-Platform tools" you can develop cross-platform apps only using one code. The Studio Which i use is Smartface App Studio. It uses %100 JavaScript and lets you build %100 native applications. In my opinion you should take a look.
* 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
There is this nature of software tools to grow in backwards-compatible ways inevitably becoming evolutionary dead-ends. Apple tried hard with features such as Automated Reference Counting (ARC) but inevitably it is still C glued with a hard-to-optimize object system.
Most of what you need to learn is Cocoa Touch and whatever other frameworks you want to use. If you need to start today, use the production Xcode and Objective-C -- it will be far less frustrating.
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.
If you plan to work in the industry in the next few years. Then definitely Objective-C. No serious company is going to rewrite an existing app in Swift just because it's a cool language.
Pragmatic : Objective C. Swift is too "young" and unproven - there's still lot of rough edge, it's a beta. But start learning Swift in the same time.
Future looking : Objective C, to be able to understand the interop still needed for Swift... but using Swift right now for most stuff.
This is a tough one. Swift is going to be the future of iOS development and very important. But at the same time I think Obj-C will allow you to explore all the existing source code that is out there without any problems. I'd say go with Obj-C and learn Swift in the future.
Not knowing either, I would say Objective-C. Way more tutorials, SO answers and you don't want to be dealing with compiler bugs when you're trying to learn. In a year the answer will be Swift.
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.