undefined

points

[-]

I tried this with an old iOS only game a few years ago. It is clearly not a heavily used library, but it seemed to work ok

- There was a bug or two I had to patch, but the code is readable, so it wasn't a big deal

- OFString, etc aren't intended to be 1:1 replacements for NSString, etc. This wasn't a real problem. They mostly match, and all I needed to do was write a few categories

- The runtime functions are not compatible at all, but most projects wouldn't touch those

- CoreFoundation and the other C APIs are not there at all, so you'll need replacements

- It is a replacement for Foundation framework, not AppKit, so if it is a GUI app you still have a lot of work to do

by rweichler6 hours ago|

parent|

[-]

This is why I went with GNUstep. All of the APIs are 1:1 with Apple's, including the runtime (which is very important imo). It has AppKit support as well; its AppKit implementation is kind of half-baked, but at least it exists. Also, a lot of the APIs are kind of old. But looking at how Swift evolved over the years, maybe that's not a bad thing.

My main complaint with GNUstep is the licensing. The runtime itself is MIT which is great, but its implementation of Foundation/AppKit is LGPL. ObjFW, including its runtime, is LGPL. At least with GNUstep one day I can create my own version of Foundation based on Cocotron or swift-corelibs-foundation or something, and not need to muck with rpaths + ship a bunch of .dll/.dylib/.so files with my app in order to comply with the license.