But 3.7 million is big compared with the entire voting public. On average, only about 100 million U.S. residents actually vote in any given Presidential election, and even fewer in midterm elections.

There's a rule in politics that for every one person who complains about something, ten people dislike it, but didn't complain. So if 3.7 million people cared enough to complain about the lack of net neutrality, over 40 million people know enough to be strongly in favor of net neutrality. And most of those folks are likely to vote in the next election.

To put that into context, it is quite possible that net neutrality matters to 2.5 times as many likely voters as abortion.

May we all die in novel circumstances.

Do we at least get to choose which novel? I think I'd prefer almost any Sherlock Holmes novel over Soylent Green.

... iOS developers are used to constant change anyway ...

I certainly haven't seen "constant change" in iOS development. In many releases, Apple has made changes to their UI that require some minor redesign so that your app doesn't look dated, but that's mostly just piddly UI changes, most of which required few or no code changes. The core of most apps doesn't get rewritten unless something doesn't work or the developer adds major features that necessitate replacing bits to overcome limitations in the original design.

If an iOS developer is having to change his or her code constantly, that usually (but not always) indicates that he or she designed it wrong to begin with. And I think a big part of that is because so many inexperienced developers jumped on the iOS bandwagon early, hoping to make it big by writing apps for a hip new platform. The result was not only excessive amounts of rewriting, but also a proliferation of relatively simple apps that still manage to break with every new release somehow. I suppose it is possible that Swift will dominate the iOS landscape pretty quickly in terms of the number of apps, but only because such a high percentage of iOS apps have so little actual code behind them that you could rewrite them as a web app in a week or two.

But when it comes to any apps that are reasonably complex, I don't see that happening, nor do I see Swift dominating in terms of lines of code for many, many years. In particular, I'd expect most cross-platform game developers to strongly resist moving to Swift because of performance, difficulty integrating with underlying shared C code, etc. For example, good luck writing an OpenGL app in Swift. The function pointer headaches will knock decades off your life.

And that's assuming that developers decide that they care. There was a lot of interest as a result of the initial hype, but interest seems to have waned considerably since then. It's anybody's guess whether developers will actually decide to adopt it. Developers are a fickle bunch, particularly when it comes to programing languages, and iOS developers are no exception. For now, I think the sensible approach is to experiment with the language a bit and see if you like it. If you love it, adopt it. Otherwise, take a wait-and-see approach—wait and see if Apple fixes the initial performance and C compatibility limitations, wait and see if developers adopt it in significant numbers, and wait and see if Apple starts pushing people to adopt it in lieu of Objective-C.

What about the trolls who will say "hey this has been filed for X years and still nobody fucking fixes it!?? FAIL!!" Who needs that kind of drama in a bug db.

Better to have the complaining in a bug database than in a discussion forum where people who are looking for general information will see it. People are going to find a public forum where they can complain about bugs no matter what you do. If you have a bug tracking database, it will be there. If you don't, it will be in your general help forum. If you censor them there, they'll move it to Amazon's product reviews.

The best thing you can do is be open about the bugs and make a reasonable effort to fix bugs in a timely manner. And use bug aging policies that increase the priority of minor bugs if they go unfixed for too long. Then, when your competitors say that you're buggy because you show your bug lists, you can say, "Our bugs are few and minor. That's why we're willing to show our customers those bugs. What do you have to hide?" This will usually end any such silliness, but if your competitors continue down the path of claiming that your software is buggy, set up a public Bugzilla database for their product and watch the fun.

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.