- What Cocoa features does the application use? Something written for OS X 10.2 using "oldschool" APIs is much easier to port than a new app that perhaps makes extensive use of 10.5+ features, binding magic, Core Data, etc.
- What other frameworks does the app use? If it makes heavy use of something like Apple's media and animation APIs (Core Animation, Core Image, QTKit, etc.), it will be very difficult to port because GNUstep doesn't cover these.
(Edit: one important factor is the degree to which the port needs to integrate with the target platform. GNUstep doesn't look very native on Windows, for example. But if the port is something like a custom application targeting Linux, then the look of widgets and fonts may not matter at all.)
Would it be possible to use this in an iPhone app? I.e. extending NSObject's retain / release and having a NSGarbageCollector like thread run around and collect.
Bolting on garbage collection to system libraries that weren't made with it in mind probably wouldn't work well. Even in OS X, when the system had been designed for garbage collection and extensively tested, it still didn't work right (memory leaks, extreme slowness at times) in the first version.
I've found that you can write reasonably complex GUI applications using the current Apple API documents for reference and for the most part get the results you expect.
The trouble is the few times when it doesn't behave as expected. I tried porting a paint program I had once written for OS X to GNUstep. Everything was going swimmingly until I ran into a behaviour of the OS X NSImageRep caching mechanism that wasn't replicated. Unfortunately, the program more or less depended upon that behavior, so coding around it wouldn't have been trivial. I know where in GNUstep the issue lies but I just haven't had the time to have a go at fixing it, so for the time being, I remain stumped.
