Multitasking.  The iPhone doesn’t let apps do it. OS X, which is the operating system on the iPhone, is a multitasking operating system, so in principle the iPhone must be technically capable of it.  Apple is actively preventing it for some reason, except applications for which it is clearly necessary, like the phone function.  I’ve read several ideas about why.  One opinion is that multitasking would reduce battery life.  Hmm. I’m writing this on a macbook using battery power.  I’m running several programs.  You think my battery will last longer if I quit all the programs but one?  Of course some programmers don’t just want their apps to run at the same time as others, but want it to run when the iPhone is asleep.  That’s something different.  That would truly kill battery life.  I definitely don’t want stuff to run when I put my phone to sleep.  But just multitasking is different. 

    There are only two real good reasons I can think of for preventing multitasking:  One is that the processor is not fast enough to keep up with more than one program.  The other is that the memory is not big enough to hold several programs resident at the same time.  That can’t be true for my iPhone, right? I have the 16 Gig version.  And in some sense, all the apps are in memory, because there’s not disk.  Right?

    Programs that are memory resident don’t have to be running.  They can just be in memory waiting for a chance to run.  A good example is the difference between Switcher and Multifinder, back in the day.  Switcher allowed us to load more than one program into memory and switch quickly between them.  On the old mac, that read programs and data in from a slow, whirring Sony microDisk, this was very helpful. Often, we wanted to copy some data from one program into another, and it took a long time to quit our current program (saving changes to disk) and start the next one, then read it's data in from disk, and then paste, save, quit and go back to the first program.  Once we had enough memory for more than one program, Switcher made that fast and easy by keeping several programs and their associated data resident in memory at the same time.  It also gave us a good way to navigate between the screens belonging to the various programs.  Some people thought that Switcher was multitasking, but it wasn't.  Only one program got to run.  Execution of all the others was suspended.  Multifinder, like desk accessories, did real multitasking.  Not because they showed you all the windows at the same time, but because each of the memory-loaded programs got its periodic turn to run, even if it was not in the foreground (i.e. even the ones whose windows did not have the keyboard focus).  Of course it was cooperative multitasking, not preemptive, but for this it doesn’t matter.

It may not be multitasking, but it’s close

    Real multitasking makes for great demos, of balls bouncing in background windows while the front window is being used for some real work.  In a powerful-enough machine it can also be incredibly convenient for the user.  For example, the Time Machine can be backing up the hard disk on your iMac without you even noticing it while you continue to work on your annual report in Pages.  Try it using  the Multifinder on a Mac Plus.  A big file copy in the Finder can be done while you continue to type your annual report in WriteNow, but typing will be severely degraded.  What I appreciated most about the Multifinder (and Switcher too) wasn't multitasking, but the improvement in workflow achieved by having more than one program and it's data loaded into memory at the same time.

    The early Mac OS was really focused on improving workflow.  The premise is that no program is enough by itself, and that most creative work requires that data be moved from one program to another in some sequence.  The primary mechanism for doing that, of course, is the file system stored on disks.  In a orderly workflow, each program will be used once on each file in a sequence.  At each step, a program is launched, a data file is read into memory by the program, some modification of the data file is made, the result is written to disk, the program is terminated, and a new one is launched for the next step.  The archetypal model for this is compiling a program.  A source file is created in a text editor, compiled by a compiler, assembled by an assembler, linked in a linker, and resources are added in a resource editor. The editor, compiler and linker in the original 68000 Macintosh Development System and the Consular Mac C system were built with a Transfer menu that allowed the user to switch to a new program using the same data file without going to through the Finder.  As convenient as this was (and it was copied on other programs), it only works with a file-based linear workflow. 

    Not everything is like that.  Well actually, most things aren’t like that. Sometimes, it is just one small thing at a time that needs to go from one program to another.  Say a calculation done on a calculator, then cut and pasted into a text file.  For things like this, the ancient clipboard is perfect. Back when, if you had Switcher or Multifinder going, you could put some data into the clipboard by copying or cutting it, and switch to another program, where you would find it in the clipboard of the new program, and could just immediately paste it.  Sometimes it was an impediment that the clipboard could hold only one item.  In that case you could use the Scrapbook. The Scrapbook could hold a sequence of clippings and it too was shared among all applications (it started out as a desk accessory).  You could copy and paste things into the scrapbook, and then switch programs and copy them out into the other program's data.  In both the clipboard and the Scrapbook, there is a very cool side effect.  The file system requires you to name your data (give the file a unique name) and remember the name and not get it confused with some other data's name.  The clipboard and Scrapbook could actually show you your data (or play it if it was a sound), and you could be sure you were moving the right data, because you could see (or hear) it.  No naming required, or even possible.  Of course both the clipboard and the scrapbook stored your data in a file.  It was just a file you never had to name, remember, open, or even know where it was located.  If only everything could be like that.  Most of what makes the computer complicated and difficult is the damn filesystem, and the task of organizing your files in it.  Still, computer work is mainly about workflow, and data have to be stored somehow and programs have to get access to the data created by other programs. 

The Truly Revolutionary Newton

    The Newton was a truly magical and revolutionary product that transformed computing.  You don’t think this is true?  You think that the Newton was a failure?  You must be in sales, or marketing, so you think that the success of a product can be seen in its sales.  The success of the Newton was in its engineering, and we feel its impact every day.  It offered a new model that is the future of computing.  It created a new user interface, that we see every day on our iPhones.  It also created a new programming model, which so far has not caught on.  In the Newton, all programs were loaded in memory all the time.  They all got a regular opportunity to run.  But the user didn't have to look at them all at the same time, as in the Multifinder and our current Mac OS.  It had a series of screens covered with icons that represented all the loaded programs, and when you picked one, you went there, and that one owned the whole screen.  It was like a true multitasking version of the Switcher.  Moving from one program to the next was very fast.  When you opened a program you did not get a splash screen to look at while you waited for the program to be functional.  It was just there and ready to go, right then.  And there really was no file system.  All programs had access to all data stored on the computer.  If one program needed and knew how to interpret data created in another, it could just access it immediately.  All programs shared a common memory space, and all programs and all data were in memory all the time.  There was a clipboard and cut and paste, but really, all data on the machine was effectively in every program's memory.  Because it had a small screen, you wouldn't have wanted to try to get all the programs’ images on screen at the same time.  Imagine that you loaded a bunch of programs on a Mac, and put the window for each one into a different workspace in Spaces, and could just switch between them in Spaces.  This would cut the clutter on the desktop.  That's how the Newton did it.

The Magical (but maybe not so revolutionary) iPhone

    The iPhone is heavily influenced by the Newton.  It is often repeated that Steve Jobs terminated the Newton project, and that he made some disdainful statements about the Newton. But he also brought the Newton spin-off back into Apple before he terminated the project, insuring that all the technology and the staff (those who wanted to) were retained by Apple.  And whether he intended it or not, the iPhone is profoundly influenced by the Newton.  Just look at it. The iPhone looks and works like a color Newton with a finger for a stylus.  And it even has no file system, right?

    I am not an iPhone developer, and I don't know everything about it, but I write cocoa programs on Macs, and I have read the iPhone developer documentation.  I can tell you that the iPhone is nowhere near as revolutionary as the Newton.  But it is also clear that the goal is to create a Newton-like user experience, and in some important ways it succeeds.   But not in every important way.  If you use an iPhone, you know that it only keeps one program in memory at a time (except for the Phone and iPod apps, and some notification stuff, etc.).  I use a couple of great calculator programs on the iPhone (PCalc and i41CX) a lot.  But every time I start either one of them, I have to wait for it to go through an annoyingly long initialization.  These programs have to be loaded into memory, they have to read in their resources, and they have to initialize all their data structures.  Every time.  Even if you only want to calculate a tip.  Starting with version 3 of the iPhone OS, I can copy the result of a calculation in PCalc to the clipboard, quit PCalc, start SimpleNote, wait for it to initialize, and paste the result into a note.  Sometimes I do this kind of thing, just because it reminds me of the good old days on the Mac 512K.  I'm glad I don't have to do it very often though.  Anyway, it is clear that programs have to be loaded into memory from a file system, even though there is no Finder and users can’t browse through files.  How about data?

    I use an iPhone app called PhotoForge.  It's an image editor -- like a tiny version of Acorn, and I like it a lot. Image editors are used as part of a workflow.  I was thinking that the iPhone isn’t built for workflow, and maybe an image editor wouldn’t work on the iPhone (iPad?) platform. When I first got it, I wondered how I would get access to an image to edit. There was a little icon shaped like a folder in a button bar at the bottom of the screen.  I think it's a folder.  It looks like one.  But what could a folder represent, in a computer with no file system?  I punch the little folder, and up pops some button-choices.  One is a button called Open, which sounds like something that could access a file.  What else could I open?  I punch it, and whoa, there is my photo library.  Just like I'm in the Photos app. I select a photo of the Ray Wylie Hubbard band playing at Casbeers in San Antonio.  Not from a list of file names, mind you, but from a screen full of thumbnails.  They’re small, but I can easily recognize the one I want.  I recall that have never named a picture on my iPhone, or had to remember its name.  And then my picture is just there, in the image editor. So I sharpen it up and adjust the levels and crop it, mostly just to learn the program's controls.  When I'm done with that, I wonder what I can do with my altered image.  I make a sarcastic joke to myself that probably the only thing I can do with it is to email it to myself.  Disgusted in advance, I go looking for a way to do that, and I see this little image of a Sony microDisk in the same button bar that had the folder.  Come on, a Sony 3.5” microDisk? No doubt that's what it is. I'm an old mac user, and I sure as hell know what that means.  I punch the disk.  Now it gives me a couple of button-choices.  Cancel, of course, and another called “Save and Email”.  Having just been proven right that this freak of a computer can communicate with the world only by sending email, I laugh my Doctor Evil laugh.  But "Save and Email"?  Save to where?  And that's when I see the third button.  It just said "Save".  If I save it, where will it go? Only one way to find out, so I punch it.  It says "Saving" and gives me a progress bar.  Then it's done.  Where did it go?  I guess the right place for it to go would be back from whence it came.  The Photos application.  I look, and there it is. The Photos application is apparently the steward of photos, and apparently other applications can read and write files that it controls.

The iPhone File System

    According to the iPhone Application Programming Guide, each iPhone app owns a single directory in the file system of the iPhone. Yes, the iPhone definitely has a file system.  Files can be written and read there just as they are on a Mac.  In fact, the file system of an application is laid out about like a home directory in OS X, but instead of users, it's organized by applications.  That is, an application has a home directory, within which the program's bundle (its executable code and associated resources) resides, as well as a subdirectory called Documents, one called Library that includes preference files and caches, and a directory called tmp that of course holds temporary files.  The application, documents and library directories are backed up when an iPhone app is backed up in iTunes. The iPhone Programming Guide mostly describes the methods a program can use to access its own directory, but I guess there must be a way to read and write to the directory owned by another app.  Ok.  The iPhone has a regular file system, just as implied by PhotoForge's little folder and disk buttons.  There might be some privilege issues to be overcome, but fundamentally someone could write a Finder for the iPhone, and you could look into the directories owned by all the applications.  Of course, that's not the correct user-illusion for iPhone apps, but it is the underlying architecture. The iPhone has a regular file system, and programs and data are stored there.  When a program is launched, it has to be loaded from there into RAM.  Programs can only run when loaded in RAM, so there is a significant loading time for a program.  Not like a Newton, in which all programs were always loaded into memory.  And data are located in the file system as well, and have to be loaded into memory to be used at runtime.  And they are organized in a file system, not in a shared database.  Inside, the iPhone is more like the original Mac than it is like the Newton.  And we still want to create and process documents stored as files.

My Recommendation

    So here is my suggestion to Apple:  Don’t worry about multitasking.  Just give us the Switcher.  Let us load a subset of our apps into memory.  Maybe the last 3 program we launched.  Maybe 4. They don’t all need to be running.  Just keep them resident in memory so we can switch back and forth really fast.  Surely in my iPhone 3G, with 128 MBytes of memory (500 times that of the old Mac 512), there’s room for that.  What’s that you say?  The behemoth operating system of the iPhone takes up almost all that space, and so the phone has enough RAM for only one of these tiny programs that run on that machine?  And those tiny programs also are actually huge because all cocoa programs are huge, even ones that don’t do very much? Ok, maybe the Switcher could be put on some future iPhone, that has more memory.  Instead, try this:

    Just make one more memory-resident program.  Name it Scrapbook.

-- BG (basalgangster@macGUI.com)