I think Swift is a great language, and that creating something new that incorporates some very good ideas into a package that works well with their existing and extensive runtime made a lot of sense, but that tying it to their platform is a damn shame (though not unsurprising).

I don't think the languages you list would have been a great fit, but D would have been a really good and interesting choice. Were it more mature, Rust could have also been a good fit.

One of the big things for Apple was Objective-C compatibility, which is surprisingly hard to get right. I know because I have been trying to wrap the APIs for Rust. Don't get me wrong: I still would prefer to use Rust on iOS, but Apple has too much invested in their Objective-C APIs to force a subpar experience and migration path onto their developers.

You certainly know more about this than me. Do you think Rust would have been fundamentally more difficult to make compatible with Objective-C than Swift was, assuming Apple had invested the same amount of time and effort? My sense is "no", but I really don't have any clue, and I'm genuinely curious.

None of the languages you listed are in the same space as Obj-C.

Compiled Ruby is not new to Apple. First there was RubyCocoa, then MacRuby and now RubyMotion. So I think RubyMotion fits into the same category.

I really wasn't trying to point to any particular language here though. As one commenter pointed out, maybe D would be a closer match up. I'm not trying to say any particular language is the right decision. I'm also not trying to point the finger at Apple.

I just wonder if some of this explosion of languages that is happening right now isn't harmful in the long run.

I'm not sure what exactly you mean by "compiled Ruby". AFAIK at no point is RubyCocoa, MacRuby or RubyMotion compiled, it's still an interpreter with the Cocoa APIs exposed to Ruby.

> I just wonder if some of this explosion of languages that is happening right now isn't harmful in the long run.

I'm not sure how that would happen. I'm also guessing that someone said something similar back when say COBOL was THE programming language.

> I'm not sure what exactly you mean by "compiled Ruby". AFAIK at no point is RubyCocoa, MacRuby or RubyMotion compiled, it's still an interpreter with the Cocoa APIs exposed to Ruby.

MacRuby and RubyMotion are absolutely compiled.

Seems like you are right. TIL I guess.

None of the languages you listed have Objective-C interoperability, which is pretty crucial for their purposes.

RubyMotion is compiled, benchmarks similarly to Objective-C, is interoperable and already running in production apps for both iOS and Mac OSX.

Laurent Sansonetti also has extensive history with Apple.

I get this argument for any other company.

But at this point Apple has gone to great lengths to control the entire toolchain from the OS to the compiler to the chips that run the instructions the compiler produces.

It’d seem odd if they didn’t go with something home-grown as their language of choice.

But it would be better for a lot of developers who don't want to spend a lot of time learning ObjC just for iPhones. It might also have been a safer choice for Apple since they now are in a bit of a danger if iPhone and iPad sales goes down. Then the number of developer learning their languages might fall fast and then the app ecosystem might start to fall too.

ObjC is about as homegrown as it gets. There are few major uses of ObjC outside of Apple/NextSteps's ecosystem.