will Apple sandbox Mac apps?

You know, most Window's users would hardly notice if they weren't able to use software other than Office to manipulate their Office-generated documents. They already behave very much as though Windows were a sandboxed environment, with one big sandbox and a handful of smaller ones.

That's a far cry from the experience of most Mac users. Aside from iTunes, which must be used to connect to Apple's online content and app stores, to a lesser extent Safari, which is the best browser for use with all Apple websites, including MobileMe, and Xcode for programming for the Mac and iOS, there's no one Mac application or suite of applications that dominates any use category. For whatever you might want to do, there's a choice, and it's common for Mac users to first use one software tool, then another, then another, in a workflow that makes use of the best characteristics of several programs.

This is harder to do in a sandboxed environment, like iOS was originally and still is, except as developers take advantage of provisions for file sharing between applications.

Would Apple similarly cramp multi-app workflows on the Mac?

There's probably two answers to this question, "no" and "yes".

No, we're not going to find that some major update to Mac OS X comes at the price of the inability to save a file with one app and open it in another. Not tomorrow, probably not ever.

On the other hand, Apple probably will find a way to provide some of the security that iOS gains from sandboxing, without actually imposing sandboxes, for the most part.

One way in which they've already done this is their use of property list files, which use a small set of basic object types to wrap data, and make it extremely unlikely that data will be run as code by accident, or by any program other than the one that saved it. Property list support is ubiquitous in Apple's frameworks, and they're very simple for the application programmer to use.

Something else Apple might do is to verify that saved files conform to the type they claim to be, that a JPEG is actually organized as a JPEG and not concealing something that doesn't belong. Developers that provide executable definitions for their custom file types might be given more elbow room than those who don't go to the trouble, and developers who don't go to the trouble might be presented with a choice between using standard file types and property lists exclusively or having their applications sandboxed, prompting some to cry "foul" and others to characterize them as whiners for doing so. Does the operating system have a right to know, in general terms, the content of every file? Of course it does; end of subject.

That's a plausible scenario for how Mac OS X might evolve in the wake of the advent of iOS, far more plausible than the scarecrow that Mac owners might look up from some software update to find their machines locked down. Sure, some apps might be sandboxed, until and unless their developers get with the program, but not the system as a whole, and, most likely, not anything distributed by a reputable company, for which the user paid real money; such apps would already have been updated by the time the deadline arrives.

So quit worrying and enjoy the ride, and think twice before using a custom file type that you aren't prepared to nail down with a schema, or something similar.