While you're busy learning obj-C, the rest of the ios developers will be learning Swift. In 5 years, by the time Apple has retired Obj-C, you'll be left with another out of date skillset. In 5 years companies will be looking for Swift developers, and you won't be ready, and you will once again find yourself behind everyone else.

It's a new language, not a new platform. It uses the same frameworks as Objective-C. So the five years you spent learning iOS development in Objective-C simultaneously taught you iOS development in Swift, aside from some syntactic sugar. If it takes you five years to learn the language itself, you should seriously consider a different career and leave programming to people who don't get hopelessly distracted by syntax.

Documentation is just the beginning. There's also also sample code, plus all the open source code out there, plus snippets on Stack Overflow, etc. It will take many years for Swift to catch up with all of that.

You don't know Apple, or iOS developers. Dominant over ObjC within two years ...

From what I've read, Swift is not positioned as an Objective-C replacement. It's positioned more as a Ruby–Objective-C bridge replacement. It will be completely dominant over Ruby for OS X development purposes within two years. It will slowly gain traction among iOS developers, and some will use it for new code, but that doesn't mean it will be dominant by any means.

The fact remains that there are billions of lines of Objective-C code out there. If you honestly think that developers are going to rewrite all those billions of lines of code in another programming language within two years, or write an equivalent amount of Swift code in that time, then you don't know developers. Yes, maybe the fart apps will be predominantly Swift in two years, but not the nontrivial apps. The longer a language has been around, the longer it will take for another language to take its place.

In the best-case scenario for Swift, even if every developer stopped writing Objective-C code cold turkey today, assuming the lines of code written by iOS developers per year is mostly constant (I realize that isn't quite true, but it's nowhere near exponential growth), it should take close to seven years before iOS Swift code lines outnumber iOS Objective-C code lines. And it could take fourteen years to reach the balancing point for OS X. And that's the best-case scenario. The reality is, most developers will phase it in over a period of time, initially using it only for new projects (if that). So the real-world balancing points are even farther out.

Now if Apple were to release an Objective-C to Swift translator, that would change the situation pretty significantly, for two reasons: first, because it would mean that Apple considers Swift to be enough better than Objective-C to make it worth porting your old code, and second, because it would make it possible to quickly replace Objective-C code with machine-translated Swift code. At that point, Swift might be the language to learn first, depending in large part on how developers react. But unless and until that happens, although it's a good idea to learn Swift, it shouldn't be the language you learn first unless you just enjoy suffering from a lack of adequate code snippets and sample code.

... and by the end of next year that prediction will probably seem ridiculously conservative ...

My predictions are rarely conservative. If anything, they're usually not cynical enough to adequately model developer apathy and resistance to change....

Now take that compiled code and turn it back into Objective-C.

Remember how long it took to lay Carbon to rest.

Very different situation. I work with a lot of companies that develop iOS applications, and it's extremely rare for them to be more than a couple of years behind the cutting edge.

Staying close to the cutting edge is easy when it's an incremental change. It's a very different thing when it means throwing out all of your your code. With the Carbon transition, you had to throw out and rewrite all of your code. Transitioning Objective-C code to Swift would have the same implication, because the language syntax is different.

Mind you, the effort in moving to Swift is lower, because the frameworks you're using are the same. On the other hand, the benefit is also lower, because the frameworks you're using are the same, and because the languages are designed to interact almost seamlessly, which largely eliminates any incentive to move existing code.

I expect most developers (and by that, I mean anybody not doing it as a hobby) to keep all of their existing code in Objective-C, but add new code in Swift, assuming they decide to adopt it at all. I could be wrong, but I really, truly don't see anything about the new language that makes me want to start rewriting those billions of lines of existing code in a new language. If I were starting a new app from scratch... well, I just did, and I chose Objective-C, because I don't think Swift is ready yet. Maybe in two or three years, I might start writing new from-scratch apps in Swift.

Modern Apple does it very infrequently, and usually, when they do, it's because they've got something newer to replace it. In this case, Swift is the newer thing.

I disagree. IMO, it's telling that Apple has never given even the slightest hint that Objective-C will ever be anything less than a first-class language. Instead, Apple is positioning this not as a replacement for Objective-C, but as a replacement for the Ruby/Python/Perl bridges—as a first-class, truly Apple-supported scripting language—something that Apple has never had before.

The only major uproot in Apple's history (no, the CPU architecture changes weren't major unless you were writing a lot of code in assembly language) was when they deprecated Carbon. The big difference here is that Carbon was always intended to be temporary. Initially, it wasn't even going to exist, but pressure from a few large developers convinced them to make a classic-Mac-compatible API available as a stopgap so that they could transition their code more gradually to OS X and Cocoa. Carbon was always going away from the day it first became available in OS X, yet even still, it took the better part of a decade before they released the first major feature (64-bit support) that was incompatible with Carbon. More to the point, Carbon code still works to this day, fourteen years later, and lots of apps still contain some vestigial Carbon code, albeit mostly non-UI code, much of which still works even in 64-bit apps.

Given the glacial pace at which Apple removed an API that was always supposed to be temporary, tell me why in the world you think that Apple won't take even longer to replace a non-temporary language that Apple says isn't going away with a language that Apple says isn't replacing it!?!

Finally, I'd add that for the moment, there's another very strong reason to not move to Swift: Preliminary third-party analysis of Swift shows that for many simple operations, it is more than an order of magnitude slower than Objective-C. Assuming their testing methodology does not prove to be invalid for some reason, I would consider Swift to be a good choice for the same sorts of hobby apps that you might write using the Objective-C–Ruby bridge. However, if you're thinking about writing a major app in Swift, you should probably think twice, at least for now. Presumably, the performance will continue to improve over time.

Like I said, start with Objective-C. That will let you get started working with real-world code now, rather than getting you started with code in a language that almost nobody is using yet. Wait at least a year or two, then look at how much traction Swift has, and reevaluate your direction at that point. The vast majority of what you learn—the frameworks themselves—won't change if you later decide to switch to Swift. Only the syntax changes. And if you know C, you already know much of the syntax for both Swift and Objective-C (though the former has a few hints of Pascal mixed in). So even in the worst-case scenario (a bizarro world in which every developer in the world wets themselves and decides to rewrite every single line of their code in Swift), you still won't have wasted your time.

Hmm. Maybe your Apple ID is associated with some magic sentinel value, like NULL. :-D

File a bug report at bugreport.apple.com.

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.

I didn't think it was "legal" to target an App Store-bound iOS App in anything but Obj-C and now, Swift. Could I hypothetically write an iOS App in ARM Assembly?

I don't see why not. AFAIK, Apple removed the restrictions on developers' choice of programming languages just five months after they added them—probably in response to developers with pitchforks....

I'm not sure what the DOJ did over the past few months, but whatever it was must have been seriously heinous to get Apple and Google to work together against them. I mean, we've only been demanding encrypted email communication for what, twenty years? And all of a sudden, Apple's DOJ abuse canary comes down, and Apple and Google are scrambling to encrypt everything.

Why do I have a feeling that Eric Holder's resignation is just the tip of the iceberg?

I live in the U.S. When I go to Check Order Status in my Apple on-line account (store.apple.com), I find hundreds of orders, none of which are mine, coming from all over Western Europe, dating back to July of this year. I see the items ordered, order numbers, mailing and shipping addresses and e-mail information for them all. I can track shipments, but I can't cancel orders.

Somebody with a volume purchase plan account probably made a typo when adding administrator email addresses or something.

Go here and see if it lets you sign in. If so, contact Apple Store support from within the VPP site and let them know that your Apple ID is incorrectly associated with a VPP plan.

smh

By that standard, asking why the universe exists is equivalent to asking, "What information would have enabled me to predict that the universe exists without being in it." So even if we accept your meaning of "why" (which IMO stretches the actual meaning of "why" considerably), asking why the universe exists does posit the existence of the person asking the question (which goes without saying anyway unless you're in a philosophy class), but it does not posit the existence of a creator, as you seem to be claiming.

Q.E.D.

The timing of this BusinessWeek story is quite amusing. It tells about a startup founder who is hiring mostly women because they're cheaper.

So there you go.

Perhaps the GP meant 2000. (The Cube and the early iMacs were fanless.)

Or perhaps the GP meant that (by default) the first MacBook Air's fans ran too slowly to keep the machine from overheating and throttling the CPU when under significant load.

I think you missed the GP's point. Big corporations exhibit almost insatiable greed, and will do just about anything to save money, from H1Bs to outsourcing. Yet they don't hire women more than men. There are two possible explanations:

• They're ignoring their primary driving force—profit—in favor of hiring more men because they incorrectly believe that men are cheaper, when in fact women are.
• Men really are cheaper, in spite of the higher base wages.

In theory, they are both equally plausible. And in practice, that's also true, at least up until the first study was published. But these days, given the sheer number of studies that all say that women are cheaper, you'd expect a significant number of the more forward-thinking execs to take it to heart and hire mostly women as a cost-saving measure. If that is not happening, it suggests the possibility that they have studied those cost differences internally and have come to different conclusions based on more complete information.

The only way to know for sure would be to find an exec willing to disclose a company's own internal studies on the subject, and that's not likely to happen. With that said, the longer we go without corporations deciding to hire more women, the greater the chances that those studies are flawed. After all, the alternative requires us to believe that something matters more to a corporation than money, which for most companies would require an almost unimaginable suspension of disbelief.

Counterexample: Why is the sky blue?