At Apple's media event introducing the iPad (see Hands-on Impressions of the iPad, 29 January 2010), Glenn Fleishman and I wanted to know what the experience of creating a Keynote presentation would be like. Inspired by a blog post from Fraser Speirs ("iPad Fallacy #1: 'It's not for content creation'"), I created a short video of Glenn manipulating objects (resizing, repositioning, rotating) and activating the annotation controls (including a laser pointer) in Keynote's presentation mode. (You can also click the video to view a high-definition version at YouTube.)
Read and post comments about this article | Tweet this article
Do you use screen sharing? We do, all the time. As an editor, I use screen sharing to collaborate with my authors, since it's convenient to discuss the same document in real time, even if the people having the discussion are on different continents. It's also a great teaching and tech support tool that lets me control an author's Mac and show what I'm doing while I explain some odd behavior in Microsoft Word.
But the king of remote control is Glenn Fleishman, who uses screen sharing for these and many other tasks, including remote server administration. Glenn's enthusiasm for the topic has caused him to check out all the latest options while updating two screen-sharing-related ebooks - "Take Control of Screen Sharing in Snow Leopard" and "Take Control of Back to My Mac." They're available separately for $10 or together for $15 (look in the left margin of either book's Web page for the discount link):
The books work together as a pair if you want to take control of the entire Mac OS X screen-sharing enchilada, and they're available independently. If you buy either one and then realize you want the other, you can use the Check for Updates button on the cover of each ebook to access a generous discount on the other.
(Those who have older versions of these ebooks should be sure to check their email - or click the Check for Updates button on page 1 of the ebook - to find out about upgrades. "Back to My Mac" is free to all who own an earlier version; "Screen Sharing" has an upgrade discount.)
Not surprisingly, our focus this week was on the iPad, with links to a podcast with Adam, Tonya, and Andy Ihnatko; an interesting article from Macworld's Chris Breen suggesting how the iPad will be used in everyday scenarios; and the news that Amazon is looking to add touch capabilities to the Kindle. Plus, AT&T is relaxing its limitations on what can be transferred over 3G, and will be allowing both streaming video and voice-over-IP calls. Finally, Apple has added iPhone apps to the iTunes Preview Web site, a security firm has identified a theoretical vulnerability in the iPhone OS, and it turns out that Macs control the market for $1,000 computers.
Podcast Discussion of the iPad, Amazon, and Ebooks -- In this two-part MacNotables podcast, Adam, Tonya, and the inimitable Andy Ihnatko joined host Chuck Joiner to discuss the dust-up between Amazon and Macmillan. They segued from there into a discussion of the Kindle, the ebook market, and the iPad in general. Well worth putting on your iPod for the evening commute.
Read/post comments
Apple Enables Web-Based App Store Previews -- Apple's iTunes Preview Web site has enabled Web-based previews of many titles in the App Store, such as Tap Tap Revenge 2.6, linked here. Aside from making it easier for users to check out apps without having to leave their browsers and launch iTunes, Apple undoubtedly wants to encourage Web search engines to link into the App Store. Given that, it's not surprising that the iTunes Preview site still pushes you to iTunes whenever it gets the chance.
Stay Alert for iPhone Phishing Attacks -- Security research group Cryptopath has discovered a vulnerability in the way the iPhone OS handles authentication certificates that could enable potential attackers to gain access to user data. To take advantage of this flaw, an attacker would have to trick users into downloading a malicious file under the guise of a legitimate update. While there are no reports of this security flaw currently being exploited in the wild, be extra careful when opening unverified links or files until an official security update is released.
Slingbox for iPhone Will Work over 3G -- AT&T and Sling Media have worked out a deal where SlingPlayer Mobile app for iPhone will be able to stream content from an individual's SlingPlayer digital video recorder over a 3G network. AT&T also said it has worked out streaming video guidelines for 3G, which other developers will have access to in the second quarter of 2010. The updated version hasn't yet been approved and posted by Apple, but it's unlikely to hit other snags.
Amazon Looking to Add Touch to the Kindle -- The New York Times reports that Amazon has purchased the tiny startup Touchco, which was working on a next-generation touch-screen technology that could be used to create full-color touch-screen displays that would be significantly cheaper than current touch screens. Gee, do you think Amazon may be acknowledging that slow E Ink screens aren't going to be sufficient to compete with the iPad?
Skype Plans VoIP in 3G in Next iPhone Release -- Skype said in a blog post (with a brief video interview) that Apple's iPhone OS 3.2 update, currently available for testing with developers, provides the changes necessary to allow voice-over-IP calls using a 3G connection. Apple had previously not allowed this, but U.S. regulators pressed for a change, which Apple has made. Skype says the new release will come when it is confident of its software's capability to make high-quality calls.
Chris Breen Ponders the iPad's Potential -- So where does the iPad fit in the world of gizmos and gadgets? Macworld's Chris Breen shares some thoughts regarding the iPad's potential uses in every room of your house, as well as when you're on the road or in the air. His visions suggest that third party accessories will be essential for integrating the iPad into our lives, much more so than the iPhone or the MacBook.
90 Percent of $1,000 Computers Are Macs -- Joe Wilcox on Betanews reports on numbers gathered from research firm NPD showing that 9 out of every 10 computers priced at over $1,000 sold in Q4 2009 were Macs. This is evidence of Apple's success in positioning the Mac as a premium brand, but NPD also points out that most of the growth in the PC market is at the under-$500 price point. With Apple posting record sales and profits quarter after quarter, we don't see the company worrying about the low end of the market.
FontExplorer X Pro 2.5 -- Linotype has released a major update to its professional font management tool FontExplorer Pro. The user interface has been updated and streamlined, a new widescreen mode enables the user to set the Preview area off to the right, a new transparency mode can be used to overlay and preview fonts in a working document, and printing is now enabled. Also, users can now tag their fonts for easier organization. Finally, several bugs related to the Apple font panel have been resolved, support for Adobe InDesign CS3 and CS4 has been improved, and various unspecified crashing bugs have been fixed. Full release notes are available on Linotype's Web site. ($79 new, free update, 28 MB)
Read/post comments about FontExplorer X Pro 2.5 .
Espresso 1.1.1 -- MacRabbit has updated its Web authoring application Espresso with a handful of minor tweaks and fixes. Version 1.1.1 adds pixel dimensions to Image Preview, the capability to show hidden files in project listings, and support for some JavaScript commands in previews. Also, regular expression searches are now supported in Find in Project, Sugars now load faster, window sizing is improved when dragging multiple tabs out of the workspace, and a crashing bug related to SFTP publishing has been fixed. A full list of changes is available on MacRabbit's Web site. ($79.95 new, free update, 10.3 MB)
Read/post comments about Espresso 1.1.1.
iPhone OS 3.1.3 -- Apple has released iPhone OS 3.1.3 to provide a couple of performance improvements and address several security threats. Changes include improved accuracy on the iPhone 3GS's battery level display, a fix for a bug that prevented some third party programs from launching, and a fix for an issue that caused application crashes when using the Japanese Kana keyboard.
Also eliminated are three security vulnerabilities that could lead to application crashes and arbitrary code execution after playing maliciously crafted audio files, viewing maliciously crafted TIFF files, or visiting a maliciously configured FTP server. Another fix prevents remote image or video content being loaded in Mail even when remote image loading is turned off. And finally, the update blocks a vulnerability that could enable an attacker with physical access to a locked iPhone or iPod touch to gain control of personal data via the recovery mode. The update is available only via iTunes. (Free, 291 MB)
Read/post comments about iPhone OS 3.1.3.
iTunes 9.0.3 -- Apple has released a small but helpful bug-fix update for iTunes. Version 9.0.3 fixes an issue that prevented the "Remember password for purchases" setting from being enabled, addresses problems with syncing certain smart playlists and podcasts with unspecified iPod models, and resolves a bug that caused problems in recognizing connections with some iPods. Apple says the update also improves general stability and performance. The update is available via Software Update or from Apple's Web site. (Free, 90.82 MB)
Read/post comments about iTunes 9.0.3.
27-inch iMac Display Firmware Update 1.0 -- If you own a 27-inch iMac that's afflicted with the cursed screen-flickering problem, Apple's 27-inch iMac Display Firmware Update 1.0 will come as very good news. The update claims to correct the iMac's firmware to ensure proper display performance, eliminating the widespread flickering issue marring the displays of many 27-inch iMacs (see "New iMac Screens Cracking and Flickering," 10 December 2009). Be sure to follow Apple's warning not to turn your computer off during installation. More information regarding installation is also available on Apple's Web site. The update is available via Software Update or the Apple Support Downloads page. (Free, 294 KB)
Read/post comments about 27-inch iMac Display Firmware Update 1.0.
A continuing complaint about the iPhone OS has been that Apple doesn't allow multitasking, a staple of the Mac OS since System 5 first added MultiFinder in 1988. Apple's stance is that allowing apps to run in the background would significantly hurt performance and battery life, but in iPhone OS 3.0, Apple added push notification, which addressed some - but by no means all - of the desires of those who were asking for multitasking.
For the most part, requests for multitasking capabilities had died down to a dull roar since the release of iPhone OS 3.0 and its push notifications. It wasn't that the desire had disappeared, but more that the debate was at a standstill.
The announcement of the iPad changes everything, because it includes a faster CPU (though how much faster is as yet unknown), 10-hour battery life in comparison with the iPhone's 5-to-9-hour battery life rating, and a screen with 1024-by-768 resolution that's far more spacious than the 480-by-320 resolution of the iPhone and iPod touch. The longer battery life could reduce Apple's concern that multiple apps running simultaneously would hurt battery life, and the larger screen raises the possibility of running apps side-by-side.
More generally, whereas the iPhone is aimed at short, focused tasks, the iPad is more likely to lend itself to longer, more general tasks that involve using multiple apps, just as we're used to on the Mac. It's easy to imagine wanting to use an iPad to read text in Mobile Safari, copy some text to a Pages document, and send that document to a colleague via Mail. That specific example may turn out to be possible with the current iPhone OS, but it points toward needing more ways for iPad apps to work together in the future.
Plus, if I'm on the right track with my suggestion that Apple's long-term plans involve even larger iPhone OS-based devices (see "iPhone Developer License Points to New Devices?," 28 January 2010), multitasking will be key - it's hard even to imagine what using a large-screen Mac would be like if you could run only one application at a time.
But what do we mean when we say that the iPhone OS should support multitasking? If we define what we're looking for more carefully, it might be easier to lobby Apple for support in iPhone OS 4.0 and beyond.
Push Notification -- The simplest form of multitasking is the one that Apple has already made available to developers, push notifications. In essence, applications register with a push notification service that runs at the system level, such that when a notification arrives, the iPhone OS presents the notification as though it had come from the app.
Notifications are one of the primary things that people want from multitasking - for one program to be able to notify the user of an event even when the notifying app isn't in active use. On the Mac, think about iCal - you want event alerts to pop up no matter what application you're using, and that can happen only if another process is paying attention in the background and can interrupt the frontmost application.
The problem with push notifications with regard to multitasking is that they are all responses to some external change in a cloud-based service like AIM or Twitter, not an example of a background app notifying you of some change. That is possible in the iPhone OS, of course, such as with calendar or timer alarms that presumably schedule internal notifications for specific times, but Apple hasn't opened that capability up to developers in any way that I'm aware of. It would be nice, though, and wouldn't seem difficult to add.
Background State Updates -- Another way we think about multitasking comes down to updating remote state in the background. This too is possible in the iPhone OS now, but only for Apple's apps. If you have Fetch New Data in the Mail, Contacts, Calendars settings screen set to Push, new email messages and changes to your contacts and calendars appear automatically. That's why you don't have to refresh Contacts or Calendar to make sure you have the latest changes; with Mail, you still need to check for new messages (or wait for the timer to trigger another mail check) for accounts without push. (You can of course make calendar and contact updating a manual process by syncing only via iTunes.)
While Apple's apps can make sure their state is always up to date by bringing data in while in the background, Apple hasn't opened that capability up to developers. Twitter apps, for instance, and RSS news readers, could benefit from being able to update state in the background.
I do want to distinguish between scheduled updates for something like Twitter or RSS, and continuous background execution, which I'll discuss later. You don't care if a Twitter client or RSS news reader checks every second, since each refresh can bring in old messages as well, whereas an instant messaging app might miss messages entirely if they arrived at the wrong time (and the server didn't maintain state with the client). That's why a chat app, or a GPS tracking app, might want to run all the time, since scheduled updates wouldn't be sufficiently fast or complete.
It would seem that updating background state on a schedule would be the sort of thing Apple could make available to developers, just as it's available for a few of Apple's own apps. Apps would have to register with the iPhone OS, which would mediate how often data was fetched, but that shouldn't be either terribly hard or excessively demanding on battery life.
Inter-application Communication -- On the Mac, we're accustomed to applications talking with one another in a wide variety of ways, such as Entourage sending a double-clicked URL to Firefox, Twitterrific asking Growl to display a notification, an iTunes controller displaying the current song, or even the Finder telling BBEdit to open a document.
A few of these behaviors are available on the iPhone, such as following a URL from an email message in Safari, creating an email message with a photo, and displaying an address in Maps. But for the most part, apps can only ask Apple's apps to do things; the main counter-example on my iPhone is Boxcar, which can open a variety of Twitter apps in response to a tweet notification. But Boxcar is extremely limited; it can open a Twitter app, but it can't control that app in any useful way, such as to display the specific tweet in question, for instance.
The reason for this is that the main way apps can communicate with one another now is via URLs, and the width of that channel of communication depends on how robust the URL handler API of one app is, and how much of it is used by the developers of other apps. But this approach is limited - the information must fit completely within a URL, and it's unidirectional - the receiving app can't send any information back. Plus, in the current iPhone OS, files are private to each app, so one app cannot send a file reference to another app.
I could see a future version of the iPhone OS extend URL handling with the capability to send file references to documents in a shared space, and perhaps to return another URL to the sending app. Such communication without requiring both apps to be active wouldn't hurt battery life or performance much, and might be better than the user flipping between apps manually now. But it would still be a clumsy way for apps to communicate, unlike the Apple Event system built into the Mac OS that enables applications to communicate with one another.
Apple Events can work only if the destination app is running, however, so it's much harder to imagine a similar system in the iPhone OS, given its significantly more limited CPU and RAM resources. I wouldn't expect to see this in the near future..
Of course, the other way to transfer arbitrary data from app to app is via copy and paste, a recent addition to the iPhone OS. Copy and paste solves many problems, but is entirely user-driven, unlike the URL approach or Apple Events on the Mac.
Quick Task Switching with Saved State -- The first glimpse of multitasking in the Mac OS came with Andy Hertzfeld's Switcher (from 1985), an application that almost made it possible to run two applications simultaneously, although under the hood it merely enabled switching between applications without quitting one and launching the other. Switcher was supplanted by MultiFinder in System 5 before System 7 made it a standard part of the operating system.
We've gone backwards with the iPhone OS, which forces you to quit one app (by pressing the Home button) before you can launch another (by tapping its icon on a home screen). It does so for two main reasons: consistency of user experience and to eliminate the RAM and CPU requirements necessary for keeping two apps active at the same time. Luckily, quitting and launching are generally quick, which is why Apple has been able to get away with it so far.
Still, it's frustrating to be forced back to the home screen constantly (especially for those of us who have lots of home screens to hold many apps), and Apple has even implicitly acknowledged that by providing a single shortcut action - a double click of the Home button - that you can set to display the home screen, the search screen, the Phone Favorites screen, the Camera app, or the iPod app. And even the fact that Apple allows four apps to be docked and thus appear on all home screens shows that they recognize users want to move among some apps more fluidly than others.
I'd suggest that two changes are necessary to meet most of the needs of quick task switching. First, the iPhone OS needs a faster way to switch between user-selected or recently used apps - the display of a shortcut screen could even be tied to a double or triple click of the Home button. Second, both the iPhone OS and individual apps need to work harder at saving the user's state, so every launch doesn't involve starting from scratch. It's not impossible; our TidBITS News app does it, so if you're reading an article when you leave the app, the app puts you right back where you were when you next launch it. Perhaps the iPhone OS could "freeze" the state of apps automatically, if developers so wished, without having to do extra work.
Neither of these suggestions requires apps to be active simultaneously, and should thus be the sort of thing Apple would consider in a future version of the iPhone OS.
Simultaneous Execution -- Here we come to the real nut of the problem - true simultaneous execution. But even here there are two actual scenarios: apps like iPod that need to run in the background, but which don't need to take up any (or hardly any) visible space in the interface, and the future possibility of multiple apps running side-by-side on an iPad.
Obviously, this first scenario is possible with the iPhone OS because the iPod app does it, so it should be possible for other apps like the Pandora music app or a GPS tracker app to do so as well.
Here's where we come back to Apple's claims that allowing background apps would hurt performance and battery life. Let's say you're playing a game on your iPhone, and it's taking most of the available CPU cycles. Running another app at the same time, like iPod, isn't going to hurt battery life significantly because all the CPU cycles are already in use, so if the game would have drained the battery in an hour, the game plus iPod would do so only slightly more quickly.
However, let's assume you're not using a game, and whatever app is active is using relatively few CPU cycles. In that case, adding another process like iPod would increase overall CPU usage and would undoubtedly drain the battery more quickly. That's not ideal, but it seems like the sort of thing that should be a user decision - much as Apple warns that fetching new data more frequently drains the battery more quickly.
A more serious problem revolves around performance. Let's say you're a passenger in a car, and you want to play a game, listen to iPod in the background, and have a GPS app tracking your location and speed, all while new message are pushed to Mail. Now the iPhone's CPU would have to share cycles among all the apps, and if it did so poorly, performance in the game might drop below acceptable levels. Tweaking how much CPU time to give to background tasks while keeping the foreground task responsive is a black art in all operating systems. And that assumes the iPhone's CPU is even up to the task at all - it may simply not have the power to keep the frontmost app responsive under the load of multiple apps. And that, I believe, is anathema to Apple - the magic of the iPhone OS's direct manipulation interface is that it's so responsive that it seems natural. Introduce lag or stuttering, and the illusion would fail.
Thus, the only way I can see Apple allowing background apps is if it could in some way control the percentage of CPU an app was allowed to use in the background, and the app would have to accept only occasional cycles if other things were going on. It's not inconceivable, but it feels like a hard problem that Apple is unlikely to solve soon.
A more serious problem may revolve around RAM limitations. Apple stays very quiet about how much is in each iPhone OS device, and it's entirely possible that there isn't enough for multiple simultaneous apps whose RAM requirements Apple doesn't control. Tweaking how much CPU time to allot to background apps may be difficult, but it's doable. Relying heavily on virtual memory (particularly if it's backed by relatively slow flash memory) instead of physical RAM could drastically hurt performance.
The second simultaneous execution scenario is more speculative, put possibly more easily answered. The iPad screen is large enough to display two (or even four, for that matter) classic iPhone apps simultaneously. Even with iPad-savvy apps, it would seem likely that if they were made to be resolution independent or could switch down to an iPhone-sized display when sharing a portion of the screen, it would be reasonable to run two side-by-side, with both being active at the same time. And, if the iPad's A4 processor is sufficiently fast and there's sufficient RAM, perhaps there would be enough resources to do that.
Here's where we start to move into the world of the Mac, because it's entirely commonplace to have two applications visible at the same time (and it's nearly impossible to avoid for those of us who prefer to work on dual-display systems). I constantly refer to a Web page while I'm writing an email message in Mailplane or working on an article in BBEdit. And if someone sends me email asking to schedule a meeting at Macworld Expo, I can show my calendar in BusyCal without obscuring the message or its reply. That's huge, and makes me more productive than I would be if I had to switch between them with Command-Tab. And the equivalent task on an iPhone OS device would be even worse, requiring me to quit Mail, launch Calendar, figure out what times I have available, quit Calendar, launch Mail, find the right message again, reply to it, and then try to remember which times were available.
Although allowing multiple apps to run side-by-side on an iPad seems like a stretch for Apple (I can imagine an interface a little like iPhoto's photo comparison approach), it would be a boon for anyone trying to use the iPad instead of a Mac for a lot of tasks that require visual access to data in multiple apps.
The main advantage this scenario has over the previous one, where the secondary apps are executing but not taking up interface space, is that with side-by-side apps, it may not be absolutely necessary that one continue processing while the other is active. The calendar could become essentially frozen in place while I'm replying to my email message, and activate only when I tap on it to switch to the next month, at which point the email app would freeze until I tapped back on it. That approach could address the performance problem, since only one app would actually be using CPU cycles at a time.
Putting It All Together -- Let's see where we are, now that we've broken down "the iPhone should have multitasking" into its component parts. Some are here today in only Apple's apps, others are purely speculative.
As always, the best (and only) way to submit feedback to Apple is via the Product Feedback page. The iPad isn't yet there, but I'd suggest making your wishes known for the iPhone or iPod touch, whichever you currently own.
And of course, tell us what you think in the comments!
