Reading Between the iPhone OS 4.0 Lines
daringfireball.net
daringfireball.net
I remember an Apple where I felt a certain pride in owning their products because they were superior options for me. A company that was gaining marketshare and mindshare through excellent products that just blew away the competition.
This new Apple is spiteful and highly defensive. I'm embarrassed to be typing this on a Mac and to have had an iPhone (switched to a Nexus One recently). If Google's moral motto is "Don't be evil", it seems like Apple's is now "Fuck you. punch".
What the hell happened?
Now, I get a notification when there's an update, roll it down, click the notification and click the clear and accurate "download" button.
And then I get notified when it's finished. It's really quite nice. (the glowing trackball is fantastic, too: so many times I'd miss an SMS or a call on my phone and not realize it until minutes or hours later)
The store should let you update all apps at once--when you open the app it goes and checks if there are updates available and if so you'll see them in the bottom right. There's an option for update all.
They're a disaster compared to Apple's desktop HCI guidelines that insist on verbed dialogs and disdain "Cancel | Ok"
The end of the desktop may be here in 5-10 years, but surely there are still interesting things left to do there?
Perhaps the ultimate simplification of computing (iPad and derivatives) is the only thing on Jobs' agenda now, innovation-wise.
OS X is incredibly mature now, while there are still warts (Spotlight is relational with fixed indexes, mobile.me sucks and isn't freemium, etc.), the iPhone OS has those warts too, it's more important to fix them there than on the desktop, and there's tons of incomplete/missing features on top of that that need iterating on.
I certainly wouldn't want to see the kinds of consumer-facing features they'd have to pull out of their ass to justify a 10.7 release in the next year or two.
I'd rather they spent their efforts iterating on their mobile products. They have a ton of challenges still ahead of them there, like whatever they're going to try to replace the hierarchical filesystem UI with, synchronization, their mobile ads platform, fixing their notifications UI, integrating browser tabs into the app-switching UI (like WebOS and ChromeOS), etc.
I suppose some jailbreaked iPhone users can comment on whether older iPhone's really can handle multitasking on 128MB of RAM. Considering that most devices have handled "true" multitasking with much less RAM than that over the years I'm not convinced it's truly a problem. They might not be able to hold as many apps in memory at once but that's what you get for having an older device. It'll be slower. But it should still be slightly faster than launching and closing every app all the time.
I also think that the Apple system varies pretty significantly from Android. Android has the concept of 'bundles' and 'servers'. Bundles work similarly to what Apple is doing, but having servers (which multi-task in a more traditional model) enables more consistent background processing.
For instance, an alarm clock on Android is often implemented with the GUI 'bundle' on the front-end and a server on the back-end that manages the actual 'when should I sound the alarm?' part of the task.'
That's one thing that just isn't possible in the iPhone model.
Having to graciously deal with being shutdown (and restore your state on relaunch) is pretty much the same model as the iPhone OS 4.
Flash as a swap drive is still problematic.
16 * 1024 * 1024 / 128 * n = 131,072n seconds
~= 1.52n days
~= 0.0042n years
They could implement some VM magic, but they would much rather you wrote your app to serialize its few kilobytes of state when it's told to be ready to die, and instantiate that state on launch. They've encouraged you to do this and provided APIs to help for a long time.
It's a lot more elegant and functional than keeping processes around indefinitely -- then they'd need a task manager UI for discarding fucked serialized processes!
Let's break this down by chopping memory into roughly three bins:
a) File-backed pages from executables, libraries (i.e. typically shared)
b) Non-shared essential memory - the state of the application
c) Non-shared discardable memory - state which can be recomputed if necessary, e.g. caches, frame buffers etc.
What's the actual upshot difference between the OS doing the serialization (in the form of bulk paging, as opposed to on-demand paging), and asking applications to do it?
Memory written out:
* OS wants to write out (b) and (c), because it's tricky to express your discardable preferences in memory allocations - not only are the pages discardable, but references into the pages need to be zeroed out. (A GC would help a lot here.)
* App can write out (b), but it needs to work quite hard to get there. Likely it will write out a fraction of (b) but do a lot of execution on loading; there may also be bugs or design flaws which lead to less than perfect resumption.
Upshot: There should be little to no difference in random access for writing: both should be sequential writes; but less written for the App model. But the OS model has a different advantage: it can lazily be writing out less frequently written pages to disk, so come suspend time, it has less work to do.
Memory read in:
* OS will read in (a), (b) and (assuming we don't have that GC etc.) (c). (a) will be random reads, while (b) and (c) will be a bulk sequential read.
* App will read in (a) and (b). (a) will be random reads, while (b) should be a bulk sequential read.
Upshot: There should be little to no difference in random reads, while the App should have a little less sequential reading.
So as regards to FS access, I don't see necessarily significant differences in between these two models.
A different matter is resources. Things like sockets, open files, events - or god forbid, system-wide synchronization primitives, etc. Some form of managed memory with opaque handles that understand serialization events would help out in the OS front here. But it shouldn't be intractable; Smalltalk systems and the like have been working with persistent images for a long time.
I actually think a bigger problem is the dynamically available persistent storage space. Having a device that's supposed to have 8GB or 16GB of memory but finding it only has 6.5 or 13 or so, owing to GiB/etc., formatting and OS installation, is galling enough. But having potential 6x chunks of 0.1 or 0.25 going missing has got to hurt. Compression may help; but it's independent of strategy.
What I do think is that an OS and cooperative runtime / GC would do a lot better job of this in terms of user experience than the app writer, who has to balance this requirement with getting all the rest of their app right. The easiest way to do it for the app writer is something along the lines of a save game or a saved document - i.e. persist relevant state, but go through the normal loading cycle at startup before restoring state. Thing is, reinitializing everything is dog slow - many apps take too long to start up, no matter what platform they're running on, desktop or phone.
This sort of system doesn't work on a desktop because you can view/use more than one app at a time. However, it's more than reasonable on a system where you interact with apps one at a time.
This is pretty much how all mobile platforms have done it since forever.
Of course since Apple has outlawed innovation in those areas targeting the iPhone, they may never find that out...
Apple hasn't yet backed themselves into a corner where they can't rip it off, but to do it right would require them to not be their usual bossy selves.
In an ideal card-based iPhone world, apps would have the option of being document-centric and be able to register for URL-handlers and file-types (both just like on OS X). Unfortunately the new Apple would probably never let them become the default in place of built-in apps (no registering http://, no owning image/jpeg, etc.).
I think they'll have to do it eventually, but it might take a while. They might try to let the new multitasking API percolate in the wild first, and develop their replacement for the hierarchical filesystem UI and maybe OTA syncing in the meantime.
btw, RIM acquired QNX. =)