“I finally got the iPhone/iPad port [of Dali Clock] working. It was ridiculously difficult, because I refused to fork the Mac OS X code base: the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right? Oh ho ho ho. I think it’s safe to say that MacOS is more source-code-compatible with NextStep than the iPhone is with MacOS.”
I think this link > http://jwz.livejournal.com/1224702.html has bin forgotten.
IANAiPD (I am not an iPhone developer), but it has always been my understanding that the GUI framework in iPhone OS is completely different from the Cocoa AppKit. It should not come as a surprise that one needs to rewrite the user interface part of a program when porting from OS X to iPhone, this is actually by design.
That being said, I agree that they could have reused some classes, such as NSColor, and kept APIs consistent with NS methods where possible even when replacing the classes.
Indeed, Apple did do that entirely by design, for the GUI part of the system: this is why iPhoneOS is better for its task of GUI apps with a touchscreen interface than Windows Mobile (or whatever name before Windows Phone 7) for creating user interfaces.
NS=old stuff, likely not going to stay around forever: Apple might as well do a clean break on new hardware that’s not got room for all the legacy APIs that the MacOS has, because, let’s face it: phones are a lot tighter platforms than a desktop system. When I read the article and saw the guy whining about OpenGL ES, it’s clear: this guy hasn’t paid attention to what’s going on in the mobile realm with modern systems, because no recent phone I’m aware of has the older full OpenGL (and not ES) support, if there’s even that on a platform, and he acted all surprised.
Seems, based on observations, Apple has been trying to make the functionality of the iPhoneOS be RAM-conservative as much as possible, while still providing an expensive composited GUI, which proceeds to eat up a lot of system resources, but at least it’s made easy to use, which is a darn good thing, because the original iPhones before the 3GS only have 128 MB total DRAM, leaving about 40 MB for user apps after all the Apple-provided apps that use memory in the background have eaten their fill. Quite a few apps on the AppStore mention rebooting the phone before starting, to clear out as much RAM as possible: I wonder if that’s changed with OS updates… games are the most likely apps to hit memory issues, it seems, if they’re very graphical in nature.
I would contest that the API rewrite had at its primary goals a goal to ‘trim’ the API down because the devices couldn’t handle it. It’s not too long ago that I was running OPENSTEP 4.2 on a 200MHz Pentium with 64MB of RAM (recommended were at least 32MB, minimum 8MB). It ran well, as snappy as any modern OS, and all that despite the fact that it ran a “slow” microkernel with drivers written in “slow” Objective-C and the whole graphics layer being a “slow” Display PostScript client-server architecture.
OPENSTEP is an implementation of NeXTStep, and OSX Cocoa and the frameworks is a hopped-up superset of NeXTStep, combined with the fact that Cocoa uses a compositing GUI and APIs to handle that. On top of that, another major difference is this: desktop/workstation/server systems optimistically allocate RAM, meaning they go on the assumption that not all of it will actually be used, but a process is told they’ve got some amount they asked for, even if it isn’t really there, combined with it being backed up by swap, and that optimistic allocation combined with running with swap combined with the fact that the iPhoneOS is a composited GUI (OPENSTEP/NeXTStep is not, IIRC: definitely not NeXTStep, as such things didn’t exist in release then, if anywhere) and iPhoneOS likely overall has a larger API than OPENSTEP for all it does, well, you combine all that and realize Apple put a lot of stuff into a relatively small system. I haven’t tried modern versions of Windows, or of Linux, but when you turn off swap (for those that allow you to do so) things go splat rather readily, even without a composited GUI that eats up memory like there’s no tomorrow. A phone OS needs to run more an embedded system: only promise what’s actually there, and can’t rely on paging. Yes, iPhoneOS has mmap, but, seriously, would you want to be constantly updating flash memory, both for speed as well as flash wear? Using mmap is most likely valuable for read-only data.
OPENSTEP isn’t an implementation, it’s a full OS with an implementation of the OpenStep spec, as well as all the old NeXT APIs (old pre-OpenStep APIs, DriverKit, MusicKit, whateverKit), plus the full Unix goodness (manpages, BSD Unix APIs, etc.). However, there’s little meaning in arguing which platform has more libraries (in terms of binary volume), because that’s not what I meant to say. I meant to emphasize that the reason the iPhone OS APIs were redesigned and rewritten most likely has little to do with fitting the APIs on a “small” device, as compared with a 1996 computer, the iPhone’s performance is stellar. If it were just that, Apple could just as well have dumped half of Cocoa (AppKit part) and created a subset with just a few classes and features added for multi-touch and window handling on small-screen devices. My suspicion is that they tried that, and concluded that the it was just way too hard to do, as the design logic in AppKit is quite big-screen-WIMP centric.