| ▲ | steeleduncan 5 hours ago | |
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 | ||
| ▲ | rweichler 4 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. | ||