what I'm talking about

In a previous post I discussed the possibility of using an iPad as a Mac peripheral, and stated that I believed there were already iPad apps which made this possible, speculating that they probably paired with specific Mac apps.

Now, Macworld has found one that augments the Mac's Finder. Remote Conductor comes in two parts, the iPad app and a free Mac server application with which the iPad app cooperates, communicating via wifi. With this setup established, Remote Conductor offers three modes, one which turns the iPad into a large, multitouch trackpad, another which turns it into something resembling a grid display of your Applications folder from the Dock, and the third allows you to navigate through open windows by application (scrolling left/right) and by open windows belonging to an application (scrolling up/down).

I didn't see a price listed anywhere on the company's website, but a quick trip to the App Store shows that it sells for $9.99, which is a little steep, unless you'll be using it a lot, which, if it works as advertised, I'm sure many will. (Oh, and they're working on a Windows version of the server software.)

Very interesting, but not quite what I was talking about. What I'd really like to see would be a more general iPad app (or mode) that works with either a server or, preferably, with any app that includes and makes use of a framework for remotely controlling the iPad's display and directing input received from it. This is the easier option from a developer's standpoint, since making use of a separate server program would involve making use of services it presented by sending script-level messages to it, much as Automator does, something fewer developers know how to do.

Even better would be to do both. Since at least a minimal server process would be necessary, it might as well be owned by the operating system, and present applications with a choice of either passing low level data, generated by and targeted to code compiled using a framework designed for this purpose, or else interacting with the iPad via scripting. Those scripting hooks could actually be included in Automator, making them accessible to a much larger audience.

For security reasons, the part of this combo running on the iPad should be sandboxed at least to the same extent as other iPad apps, so that it had no more access than they do to data stored on the iPad. Because Mac apps aren't necessarily subjected to review, it might be better if it were even more isolated, as a service provided by iOS running in a special, locked-down mode. It could be enabled via a second button, like the one on the lock screen that puts the iPad into slideshow mode, and interrupted at any time by pressing the Home button (or as determined in Settings).

However the implementation were to be handled, the end result should be to make it possible for a Mac app to run part of itself on an iPad, taking advantage of not only the iPad's touchscreen but also the lion's share of its cpu/gpu time and RAM, as as much nonvolatile memory as any app is allowed, with Mac UI elements compiled using AppKit and iPad UI elements compiled using UIKit.

Unless and until Apple decides to make such a framework (and/or script server) available, it's still possible, right now, to create iOS apps which communicate and cooperate with Mac (Windows, etc.) applications, providing those applications with what amounts to a smart touchscreen peripheral.

If you're having trouble imagining how this might be useful, imagine an emergency call center with a highly integrated computing environment, with operators sitting at workstations and the shift supervisor walking around behind them carrying an iPad that's displaying an overview of all the traffic passing through the call center, with additional information (the history of calls from a particular number) just a quick tap away.