For those that don’t know GNUstep is a project that started many years ago to help bring Objective-C to the masses using operating systems other than Mac OS X macOS. Actually, Objective-C already existed on any platform that had access to the GCC compiler suite but what GNUstep sought to do was bring the primary frameworks (libraries) that were being used on macOS to make porting Mac applications to other platforms a lot easier. In particular we’re talking about the Foundation and AppKit libraries.
For the most part they’ve nailed it on the head for simple applications and the Foundation library seems rock solid and fairly up-to-date with the Apple versions. In fact the Foundation library seems to be up-to-date with at least macOS 10.9 and some of 10.10.
That said, there are a couple of places where people, including me, are having serious problems with GNUstep. I have to add at this point that these are constructive criticisms! The GNUstep folks had a definite goal in mind when they started and I have to say that they hit the nail on the head with this. Also, like many open source projects, it’s an all volunteer army where people have day jobs and others simply lose interest for other projects. In fact, the introduction of Swift has definitely contributed to that last point – many people have given up on Objective-C and jumped on the Swift bandwagon.
1. They Keep Breaking It
This mainly applies to the AppKit libraries when trying to use Objective-C 2.0 features such as the non-fragile ABI and ARC. If you want to build your Objective-C 2.0 projects with the non-fragile ABI then you’re not going to be able to use the AppKit libraries. Otherwise you’re applications will crash with a notice about mismatched ABIs. The solution is to build without non-fragile ABI support. This is not always desirable.
2. Strict Adherence to macOS Paradigms
Apple’s operating systems (macOS, iOS, watchOS, tvOS, etc.) all have this paradigm where basically everything is a directory. Especially Frameworks and GUI Applications. GNUstep tries its best to replicate this paradigm on other platforms but the truth is that it just isn’t necessary and adds a huge amount of complexity to the build process and the resulting product. The paradigm works very well indeed on Apple’s operating systems because there is support for the paradigm built right into the operating systems. But on other operating systems such as Windows and Linux this paradigm doesn’t work so good. In my opinion, and I’m not alone, it would be best to simply follow the best practices of those other platforms rather than trying to hammer a square peg into a round hole. This applies to packaging too. The default package manager for each platform should be used. It’s less confusing for users of those platforms.
2.1. This Applies to GUI Applications Too
The GNUstep GUI applications ALL look like they were all written about 30 years ago. They use concepts and HID guidelines that harken back to the NeXT operating system from whence everything is modeled from. Even Apple has dropped most if not all of these old HID paradigms in favor of ones that are more modern and practical. I mean, honestly, who has main menus that just hover somewhere detached from the main window of the application. Really?
Yeah, okay, I know – GNUstep has this neat pluggable theme system and can be customized but 1) this is highly problematic (see point #1 above) and 2) it is not well documented – if at all. And if it is documented you can’t find it unless you spend years scouring the web and happen to stumble across it like I did when I found this some FOUR years after it was first posted. (scroll all the way to the end of the post to “Step 15: Making it Look like a Linux Application“)
3. Makefiles
Everything should be moved to CMake. ’nuff said.
4. Distribution
There is no support in GNUstep for packaging your applications for distribution to system that don’t already have the GNUstep libraries on them. I’ve seen ONE very outdated partial document describing one way to do it but that’s it.
How to Fix This
In an upcoming post that I’ll be sure to link to this one I’ll outline some steps for addressing these issues. At least a couple of them I have already started work on: https://github.com/GalenRhodes/Rubicon
There is much to not like about GNUStep. Breakage is probably the gravest sin. Honestly, you could write a book about what is wrong with GNUStep. Swift on Linux is looking to be far better.
Agreed, I’m just eager to see how good Swift becomes on other platforms and if the get the kinks worked out as far as building Swift and supporting libraries (such as dispatch) on non-Intel platforms such as ARM32 and ARM64.
I’ve built it on Linux and it works fine (no standardized GUI — but then GNUStep doesn’t work out of the box, so I guess it isn’t an issue?).
ATM, there is no “clean” cross-platform product (I’ve looked at Xamarin — uh, no).
I wish I could say “I couldn’t agree more”, because I probably would – but for me, I’ve just spent the last WEEK trying to compile a simple Hello World project with GNUstep. And failed! Granted, my command line compiler knowledge is very limited, but my Objective-C skills are relatively solid, so when I heard of GNUstep I thought what a great idea for cross-platform applications.
My main issue with the project is that if I have to spend a whole week on getting it going, and it doesn’t work, then perhaps GNUstep just doesn’t want to be used at all. And believe me, I’ve tried on THREE platforms (CentOS 7, Ubuntu 16 and Windows 10). I was especially disappointed with the Windows setup they give you: initially promising, all you have to do is install pre-compiled packages. What could go wrong? Well, the GUI tools didn’t even want to start and crept out with a Runtime Error. What? How can that happen? When has anybody checked those installers last?
Then of course there’s this whole “you must compile with clang, otherwise you’ll be limited to Objective-C 1.0 syntax” thing. I understand why, but would it kill anybody to mention this, in perhaps a documentation from sometime after 2007?
Don’t get me wrong, I love the idea, and I mean all this in a constructive way. The project needs support, especially in the documentation department. Because right now it looks like this thing is totally unusable.
Great to hear that you’ve at least got it going and you’re doing some development with it. Even better to hear that it’s more or less compatible with OS X / macOS 10.10ish, that’s very recent indeed (again, no mention of this on GNUstep.org).
I’ll check out your repo too, perhaps one day I can count myself to the handful of devs who can say “my app runs on GNUstep” 🙂
Thanks for the post!