Lion/iOS 5 APIs included in latest GNUStep Objective-C Runtime release | Hacker News Reader

Lion/iOS 5 APIs included in latest GNUStep Objective-C Runtime release

lists.gnu.org

60 pointsmvzink27 comments

This sounds very cool, but note that this talks about the Objective-C Runtime, which is the plumbing underlying Objective C.

Implementing all Mac OS X ObjC runtime APIs is great, but it's far from implementing the ObjC framework APIs (Foundation / AppKit). In fact, most Cocoa code does not even use the runtime APIs explicitly (though the compiled code certainly does).

This is very true, and may have seemed misleading.

Although I should note that the frameworks are not "ObjC frameworks" per se, but rather the Cocoa/OPENSTEP frameworks—which are mirrored, for example, in Objective-C++, making them not exactly ObjC specific, philosophically. But you're absolutely right that this is the difference between being able to use Objective-C on Linux and being able to use Cocoa on Linux :P

This is cool -- I've long had a dream of using Obj-C as a system programming language on non-Mac platforms. To be productive you need a lot of things, like NSString and NSDictionary, however. There is GNUStep; is it sufficiently up to date? Has anyone done this?

For system programming, that's probably feasible. GNUStep's implementations of NSString, NSDictionary, and other Foundation types are pretty solid (to my limited knowledge). That is to say, if you don't want to use anything beyond core Foundation classes (not CoreFoundation), GNUStep is probably sufficiently up to date to build cross platform system software. Conditional compilation makes this particularly feasible for lower level programming. Most people, of course, just want GNUStep to let them port their OS X apps etc. to other platforms.

Any idea why Apple hasn't open sourced anything beyond CFLite? Without multiplatform, objc's ecosystem doesn't get a real chance to flourish, so efforts like this one are great; but I don't get why Apple is making this so hard. Their open-source approach to webkit has proven so successful, yet they show no interest in applying the same pragmatism to objc.

Woah. What? The iOS market is a 2.5 billion per year and growing. It is not unusual to only have one type of build system[1] supported per industry (major product line)[2].

[1] Mac with OS X 10.7 with XCode 3 or 4 using iOS API's

[2] The industry is considered the iPhone/iPod/iPad app store only because the other markets, Android and Blackberry, have non interchangeable binaries.

Woah. What? The iOS market is a 2.5 billion per year and growing.

No shit. I'm talking about Objective-C. If more developers could use it and more often, we'd have better libraries, better developers, a better community. Look at the momentum that C++ has despite its flaws.

If you doubt that ObjC developers would be interested in using ObjC but don't because using it on other platforms is too exotic, check this thread: http://news.ycombinator.com/item?id=3205372

It is not unusual to only have one type of build system[1] supported per industry

So what? Doing things because it's the usual thing to do is not Apple's way of doing things and it's worked for them. That's also why I'm surprised with this.

I'm curious about the significance of this. I don't know anything about OS X or iOS development (or mobile development generally). Does this provide a relatively simple way to port apps to non-Apple platforms? Or is more needed than just a compatible Objective-C runtime? If, say, Android shipped with this library, would that make it pretty trivial to produce native apps for both iPhone and Android from a single codebase?

From the announcement: Julian Mayer for providing a demonstration of the capabilities of the runtime by using it for the Linux port of Core Breach, a game written for Apple systems, which makes extensive use of Objective-C 2 features, including blocks.

How typical is Core Breach as a Mac application?

It would be trivial if the libraries ("frameworks") were the same; their sources are not shared openly by Apple. GNUstep was however based on the same open specification as earlier NeXTStep / OpenStep libraries, which was the same foundation for Apple's current libraries. And porting is a popular use case, so compatibility can clearly be beneficial.

This announcement is about the inclusion of Objective-C language runtime features that appear in 10.7 and iOS 5 in GNUStep. The runtime is responsible for providing basic language level features like message sending, reflection, IMP lookups, blocks, etc.

It doesn't involve or include any of the actual API Frameworks that are used when developing OS X or iOS applications, however. So while this will simplify porting in the sense that you won't find that there are language features that are missing in GNUStep, porting still potentially involves significant changes to your code base, depending on what APIs you were relying on and what the equivalents available in GNUStep are like.

Has anyone or can you even create an iPhone app or Mac os X app using this software instead of using the standard XCode development suite?

I think you'd eventually need to compile with the apple toolchain to get the code signing but other than that if the APIs are there you should be able to do a lot of the dev with GNUstep.

Off-topic but I thought it worth mentioning that Microsoft's Autheticode code signing (used to digitally sign executables) works just fine with the gcc/g++ tool chain. Maybe Apple's can too?

Code signing can be done from the command line using [codesign(1)](http://developer.apple.com/library/mac/#documentation/Darwin...)

This is technically, true, but...

> if the APIs are there ...

The APIs are exactly what aren't there. That is, the runtime APIs are now there, but the framework APIs aren't.

GNUstep's runtime just gained some language/runtime APIs, that is very low level features that appeared in Apple's recent updates to their implementation of the Objective-C language & runtime. This is a very different matter from the gargantuan frameworks (Cocoa, AppKit, UIKit) which Apple has built atop Objective-C. These frameworks are the APIs that should be "there" to allow doing "a lot of the dev with GNUstep"— an they are a long way from being implemented by GNUstep, but some are indeed being worked on.

I thought the announcement meant that UIKit, etc was now available via GNUStep.

Nope. It's about the support of new language features like blocks in the GNUStep Objective-C runtime.

It would be essentially impossible, they've essentially gotten the latest version of Obj.C. working (which is awesome!), but they don't have any of the frameworks from iOS/OS X reimplemented. The frameworks make the language, so you wouldn't be able to port any code at all, really.

Here's some info about CoreBreach's Linux port being enabled by these changes: http://www.phoronix.com/scan.php?page=news_item&px=MTAxN...

I thought Apple's Objective-C runtime was open sourced.. I guess I was conflating LLVM/clang with the runtime itself.

No, you're right.

http://opensource.apple.com/source/objc4/

I can't speculate about why Apple's runtime would or wouldn't be suitable for use in GNUstep though.

Licensing most likely. Apple's runtime is under their own custom license (APSL) which is GPL-incompatible.

I was about to correct you, but, in looking over the FSF opinion on APSL 2.0, I noticed that while APSL 2.0 is considered a free software license, I had forgotten that the APSL 2.0 license is still incompatible with GPL.

http://www.gnu.org/philosophy/apsl.html

Huh. I was pleasantly surprised by the sentence: "Apple's lawyers worked with the FSF to produce a license that could qualify."

Yes. RMS was highly critical of APSL 1.0

http://www.linuxtoday.com/mailprint.php3?action=pv&ltsn=...

So Apple revised the APSL to address some of his concerns.

What are object planes?

This doesn't support ARC, does it?

Reply on news.ycombinator.com