Neither are "inherently tied" to OSX or iOS. They may be practically tied due to who drives them and their competitors lack of incentive to ever invest in them, but from a pure language point of view they are agnostic.

Almost the entire OSX API is built on the Objective-C object dispatch model. Swift and Objective-C are built for this model specifically.

It doesn't make sense to run Swift (or Objective-C) without the underlying platform API. You can do it (and Apple does; iTunes for Windows is built with such a shim) but it's not practical.

The only reason Swift even exists is that no other language (other than Objective-C) fit with the object model of the OSX API. So they had to make their own. As much as other languages don't interface well with OSX is as much as Swift doesn't interface well with every other platform.

> Almost the entire OSX API is built on the Objective-C object dispatch model.

False. Cocoa is a significant part of OSX, but there are C api's for most of the frameworks.

> Swift and Objective-C are built for this model specifically.

False.

Swift supports the Objective-C dispatch model only in a special legacy mode for compatibility that must be enabled on a class by class basis. Swift's default dispatch model is static, just like most other compiled languages and has no impedance mismatch with other OSs.

The rest of your argument is based on these false statements and is simply wrong.

You're wrong on all accounts. The Objective-C dispatch model is based on Smalltalk.

Most OSX apps and services still aren't even written in Objective-C and many (most actually) platform APIs are still in C.

You can compile Objective-C using the gnu compiler and have been able to for ages.

Swift is an amalgam of many different programming languages and styles, including Rust. None of which have anything specific to do with OSX/iOS about them.

> The Objective-C dispatch model is based on Smalltalk.

I meant the low-level dispatch of methods; the application binary interface that Objective-C uses to communicate with the APIs that make up almost the entire OS X GUI API. You can't mix that with the ABI for Windows API or any Linux toolkit (except GNUStep).

> Most OSX apps and services still aren't even written in Objective-C

Most OS-X apps aren't written in Objective-C? Really? Come on. If it was written specifically for OS X or iOS then it's almost guaranteed to be in Objective-C.

> You can compile Objective-C using the gnu compiler and have been able to for ages.

Nobody says you can't. But the only real useful thing you can with that is link to GNUStep.

> Swift is an amalgam of many different programming languages and styles, including Rust. None of which have anything specific to do with OSX/iOS about them.

At the high-level you are right but on the low-level it's specifically designed to interface with Objective-C APIs which exist in OSes from only one manufacturer. You can't separate Swift from that. The fact that it's an amalgam of OS X specific technology makes it unsuitable for other OSes. It doesn't really have that much in common with Rust either.

> So they had to make their own (again).

Objective-C wasn't created by Apple or NeXT.

Fair point but it doesn't change the argument.

Well then: Ruby integrates very nicely with Cocoa and UIKit via RubyMotion, so they didn't need to develop their own language.

MacRuby (which RubyMotion uses on OS X) is a custom version of Ruby with some significant changes under the hood and a lot of compatibility shims:

https://github.com/MacRuby/MacRuby/wiki/How-Does-MacRuby-Wor...

And MacRuby itself is written using Objective-C.

Objective-C (and now Swift) is OS X's system language and they are not applicable as a system language for any other platform.

You've moved the goalposts so far I'm not sure you're even in the same stadium anymore.

I'm not sure that's fair since you brought up MacRuby which is completely irrelevant to how well Swift would work for non-Apple platforms.

It completely undermines it. You have the direction of your dependency arrows mixed up.

Objective-C doesn't play nicely with other operating system APIs. Literally the only OS it plays nicely with is the one written for it specifically. It has found no success anywhere else. The direction doesn't even matter; both the language and the platform have evolved together.

Objective C plays nicely with any C and C++

Totally false. Not only is there no such tie, Apple is preparing a Linux open source release.

You can compile Objective-C on Linux but nobody does.

That just goes to prove that there is no tie.

Nobody does because it's tied to Objective-C runtime, Cocoa etc. which don't work well either in Windows or Linux - due to different dispatch model. GNUstep is essentially a compatibility library, works sort of meh and is incomplete. See the other leg of the thread.

It's tied to the objective-c runtime to the same extent that other dynamic languages e.g. Ruby, are tied to their runtimes. That hasn't stopped them.

I agree that the poor state of GNUStep and indeed the fact that it even tries to be a compatibility layer discourages users.

However objective-c is not tied to GNUStep. And this line of reasoning is irrelevant to swift.

Neither swift nor its standard library are tied to OSX at all. Moreover the applications for which a Linux versions will be useful, i.e. servers, will not be handicapped by the lack of access to Cocoa.