[nooneelse]

But Safari being multitasking only solves the "browsing -> other -> back to browsing" case, right? "Something else -> Safari -> back to the first something else" needs the something else to be multitasking enabled or good at storing its state.

Trying to predict what the users will and won't ever need to switch to and from and back to again is a crap shoot in general. Sure one can get it right much of the time, but why not just suck it up and make the overall solution better so there aren't those cases where one guesses wrong.

From the outside, this feels like a bizarre, "accept no criticisms of an Apple product as valid" kind of thing. Stuff like Browser Duo and mini apps make it clear that the longer Apple doesn't solve this in general, the more other developers will put together "do x and y at the same time" applications. Does it really seem better to have these kludges than a general solution?

[0x44]

"something else" -> "web browsing" -> back is handled by the application wrapping the Safari web browser using the included browser control in the API.

[nooneelse]

Good point. I was just doing an inversion in the example to simplify the argument mechanics a bit.

But doesn't that wrapping rely on something else's developers realizing that the user might want to go off to the browser and back? What if it wasn't Safari in the middle but any one (or three) of the numerous other programs the user might want to take a side trip through. It gets back to the crap shoot of trying to guess every multi-application use case that will be wanted. All this to defend not putting together the general solution which is entirely doable to begin with.