That article would be more credible if it didn't give two examples of dual-core tablets (Dell and Motorola) that shipped "in volume" that actually flopped. Which raises the question of just what kind of volume they were shipping in - probably orders of magnitude lower than the kind of volume the iPad 2 ships in.

I dunno, but you could always call the C libraries from Objective-C, and call the Objective-C from Swift.

Less ambiguity, allowing the compiler to optimize more?

"(And as for Java, it was my understanding that Apple had hobbled it by refusing to release updates on a timely basis.)"

That's a different, later issue.

Early on in the life of OS X, Apple offered a Java interface to the Cocoa class frameworks. In theory, you could write OS X applications using Java, calling into the Apple frameworks instead of using Swing or whatever Java frameworks.

This wasn't all that well supported, didn't perform well, and wasn't popular.

I learned Objective-C before I learned C, back in the early 90s. Before that I'd learned Basic and Pascal. Objective-C clicked with my brain pretty easily.

Some of the new docs I've seen let you select Objective-C, Swift, or both.

Doesn't look like "Start Developing iOS Apps Today" has an option to switch to Swift.

You can mix Objective-C and Swift code in a project, so it would be easy to progressively port code one class at a time.

Porting NSView subclasses first would give you a win, because if you use Swift the classes can draw themselves at design time in Interface Builder. (Objective-C view subclasses just draw a white rectangle in IB.)

Probably because they wanted one that integrated well with their existing frameworks, and which really took advantage of their investment in LLVM.

That's how I always felt. I liked the clear differentiation between C function calls and method calls on objects.