Cocoa Environments
To get your your Cocoa (Touch) code running you need need an environment consisting of compiler, runtime and libraries. If you want to deploy to one of Apple's platforms you are all set because everything has been provided. For other target platforms or special use cases, have look below.
Complete Environments
These projects provide complete environments to get your Cocoa (Touch) code running.
Obviously Apple's Cocoa and Cocoa touch environment have everything you need. The two downsides (besides myriads of bugs) are that the libraries are not open-source and only Apple platforms are supported. Both Swift and Objective-C are officially supported.
GNUStep dates back to the mid-90s and has been providing a Cocoa-compatible environment since the times when Cocoa was actually called 'OpenStep'. Despite many issues, GNUStep is a viable option to deploy Objective-C based code to Linux or even Windows. ObjC only.
The Cocotron also provides a Cocoa-compatible environment, but in contrast to GNUStep its MIT- and not GPL-licensed and prefers Windows to Linux. ObjC only.
While GNUStep and Cocotron are Cocoa implementations and therefore helping to port your Mac apps, WinObjC is a Cocoa Touch implementation and lets your iOS apps run on Windows. Awesome. And its built by Microsoft itself. Wow.
Runtimes
The Objective-C runtime is at the heart of Objective-C and provides core functionality like message sending, introspection and more. The Objective-C runtime is also necessary for Swift on Apple platforms.
The reference implementation, and focused on Apple platforms.
libobjc2 is probably the best open-source runtime and provides support for blocks, properties and ARC.
The Cocotron project also comes with its own custom runtime, because of NIH. Luckily it can be made to work with libobjc2.
libobjc was the only open-source ObjC runtime for quite a while and has served its time well.
The Mulle runtime is at the heart of the "mulle-objc" project and community which is a "new" way to run Objective-C code and aims to #MakeObjCGreatAgain.
The ObjFW project also comes with its own, portable ObjC runtime. It even works on MorphOS, Haiku, QNX, PSP, 3DS and the Wii.
Foundations
The Foundation is the Core Library of Cocoa for everything not GUI-related. Its also common identically to all of macOS, iOS, tvOS and watchOS development. All of these projects below are ObjC only, except where noted.
Can be used from both ObjC and Swift. Unfortunately Apple's Foundation is not open-source and they only provide it own Apple platforms. Fortunately at least parts of its base, CoreFoundation are open-source under the name CFLite.
GNUstep Base is the name of GNUStep's Foundation implementation and its probably the most complete Foundation implementation outside of Apple.
Cocotron provides a quite complete Foundation implementation that works on Windows and Linux.
Swift.org has a project going to write a Foundation re-implementation based on CFLite. Aimed solely at Swift.
The MulleFoundation is quite new and there is little information about its compatibility and completeness.
The WinObjC Foundation is written by Microsoft and runs on Windows.
Another Foundation implementation based on Apple's CFLite. This is aimed at deployments to Android.
mySTEP characterises itself as "embedded GNUstep" and has a comprehensive Foundation implementation
mGSTEP was a OpenStep implementation aimed at embedded devices and included a Foundation implementation.
libFoundation provided "an almost complete implementation of the OpenStep specification", back in 2001.
AppKit
AppKit is Apple's GUI framework of choice on macOS.
Unfortunately Apple's AppKit frameworks are not open-source.
GNUstep GUI is a quite complete AppKit implementation, unfortunately it makes your apps look like OpenStep apps from 1994 by default.
Cocotron provides an adequately complete AppKit implementation, but you need to crawl through the different forks to find fixes for the issues you'll be experiencing.
UIKit is Apple's GUI framework of choice on iOS.
Unfortunately Apple's UIKit frameworks are not open-source.
WinObjC is a Cocoa Touch implementation and lets your iOS apps run on Windows. Awesome. And its built by Microsoft itself. Wow.
There seem to be quite a few projects to implement UIKit for Linux (1),
Android (2,
3,
4,
5,
6 ) or Mac (6, 7, 8 ),
but all of those seem to be incomplete and/or abandoned."
Compilers
To get Objective-C or Swift code running, you need to compile it first.
Clang, built on top of LLVM has been Apple's Objective-C compiler of choice for years, and it can also be used to deploy Objective-C to Windows and Linux.
GCC was the ObjC compiler of choice before Clang took over. GCC may still support some targets unavailable in Clang.
The Portable Object Compiler was a viable option in the 90s but doesn't implement ObjC like we know it today and lacks features like protocols and categories.
mulle-objc contains a clang-fork to accomodate the mulle-objc runtime and the mulle changes to Objective-C.
A "compiler for a subset of the Objective-C language".
The official Swift compiler built by Apple on top of LLVM. Its not only open-source but a real community project.
This is a fork of Swift providing Windows compatibility for the Cygwin or MinGW environments.
This is probably the only other Swift implementation and can be used to target Windows, Android and more.
Other
There are various other projects related to Swift and Objective-C.
Cappucino is basically a Cocoa implementation aimed at running Cocoa apps inside a web-browser. Its based around Objective-J instead of Objective-C, which basically takes ObjC's additions to C and places them upon JavaScript. This is probably the easiest way to write a web-app for a Cocoa developer.
While Cappucino can be used to port Cocoa applications to the web with minimal modifications, SproutCore is a web-framework that is inspired by Cocoa but does not aim for any form of compatibility. It was notably used to power Apple's iWork web-version.
Darling aims to make it possible to execute unmodified Mac app binaries on Linux. They will obviously need a re-implementation of every framework that exists on macOS, amongst other things. Good luck.
If you love coding in Objective-C but are not interested in Apple's OpenStep derived AppKit&Foundation, you could Étoilé a try which is basically a Linux distribution with a homegrown GUI and a lot of frameworks written in Objective-C. Some of them like CoreObject are even useful on macOS & iOS.
Another option if you don't want to base your Objective-C code upon the OpenStep derived AppKit&Foundation environment is OpenFW, which is mainly used for improved porting to other platforms, but may also be viable on its own.
Automagical is a transpiler which converts Objective-C to JavaScript. Possibly useful for bringing your Cocoa apps to the web.
J2ObjC is a transpiler which converts Java code to Objective-C. Possibly useful for sharing base code or converting apps between Android and iOS.
Automagical is a transpiler which converts Objective-C to C#. Possibly useful for sharing base code or converting apps between iOS and Windows Mobile.
Alternative Environments
There are various completely alternative development environments that are not based on the frameworks or languages usually used for macOS or iOS development, yet still promise 'native' integration and performance. The upside of these alternative environments is that they may offer cross-platform deployment out of the box - instead of trying to get your Cocoa code running elsewhere as-is.
The downsides are too diverse to list here.
Xamarin can be used to create native UIs for iOS, Android and Windows from a single, shared C# codebase through Xamarin.Forms.
Xojo, previously known under the name REALbasic, promises rapid cross-platform development using their Basic dialect
React Native allows to build native apps for iOS, Android using JavaScript and Web-technologies.
There are a bunch of frameworks like Electron, Meteor and AppJS that allow you to write 'native' cross-platform apps with Web-technologies like HTML, JavaScript and CSS. There is nothing 'native' about that though, these are basically double-clickable websites.
Of course the best way to solve the cross-platform native-development problem is by just re-defining what 'native' means.