Ted Landau on Apple, politics, evolution, movies & whatever
Apple Inc
Picturing an iPhone at an Exhibition
Dec 28th
Recently, I attended the “Van Gogh, Gauguin, Cézanne and Beyond: Post-Impressionist Masterpieces from the Musée d’Orsay” exhibit at the De Young Museum in San Francisco. Unless you plan on visiting Paris after these artworks are returned, it’s a once in a lifetime opportunity to see some truly fabulous paintings, including Van Gogh’s Starry Night. If you live in the Bay Area, don’t miss it.
But this column is not about my museum recommendations. Rather, it’s about iPhones.
As at many museums, the De Young offers an audio tour of its exhibits. You rent an audio-only playback device and headset. For the Post-Impressionist guided tour, it costs $7.
But wait? Wouldn’t it be great if the Museum offered an Exhibit Tour iPhone app? It could be a win-win. The museum would save the cost of purchasing and maintaining hundreds of audio playback devices and headsets. Attendees (at least those with iPhones) would be saved the hassle of having to carry around an additional piece of equipment. As a bonus, an iPhone app could be far superior to the audio-only guides that now exist. It could include supplementary graphics and video in addition to the audio. It would have an easier-to-navigate touchscreen interface.
Depending upon the museum’s policies, the app could serve as a permanent souvenir of your visit — or it could be set to expire after your visit is over.
For all this to work smoothly, two critical details would need to be worked out:
1. How would you get the app on your iPhone?
The simplest way would be for the Museum to submit the app to the App Store and, assuming it gets accepted, have it available for you to download. As one especially relevant example, you can already get a Tour app for the Orsay Museum.
But what if you arrive at the museum without the app pre-purchased? Assuming the Museum has decent 3G coverage (for iPhones and iPad 3Gs) or free Wi-Fi (for all iOS devices), you could download it on the spot.
Still, I believe the best solution would be if the Museum could directly and locally transfer the app to your iOS device. In theory, this could work by connecting your iPhone to a Mac server containing the app. Or it could be done wirelessly via a local Wi-Fi or Bluetooth connection (perhaps similar to how Bump works, if the app is not too large).
2. How would you pay for the app?
If the app is available via the App Store, there’s no problem. You pay for it as you would with any other app.
If the app is directly transferred locally at the Museum, you could pay for it via cash or credit card, just as you would have done to rent the separate audio device.
As many of you have probably realized by now, there’s one big problem with the entire local transfer and payment scenario: It’s impossible to do. Why? Because Apple won’t permit it.
The only way to install apps on your iPhone is via the App Store. There is no sanctioned pathway for the museum to directly transfer an app locally. [OK. Technically, this is not entirely true. As one example, there are ways for developers to permit users to load beta versions of an app for testing. However, such methods are cumbersome and not designed for the type of large-scale quick transactions that museums would need.]
Which is all too bad. This is a huge missed opportunity. It’s yet another example of how Apple’s restrictive policies prevent using iOS devices in ways that would enhance its functionality.
Apple could create a special section of the iOS for locally-transferred apps. It could include a check to make sure that you are not illegally copying apps obtained from the App Store or otherwise copy-protected. And Apple would have to give up its 30% cut of the sale of such “local apps.” In return, amateur developers could use this to create apps to share among friends. Various institutions, from retail stores to museums, could use it to provide apps at the point-of-sale. But it will only happen if Apple loosens its grip on iOS access. I expect it will happen someday. But it won’t be this year. Or next.
Printing in iOS 4.2: Now We Know
Sep 15th
Now we know how printing will work in iOS 4.2.
At the Apple Event on September 1, Steve Jobs focused on new iPods. However, he also made mention of the forthcoming iOS 4.2 (due out in November), especially noting that it would support wireless printing via a Print Center app. Beyond that, he offered no details as to how exactly it might work.
This, of course, led to speculation among the Mac media regarding the different possibilities.
One faction suggested that needed printer drivers would be downloaded to the iPhone on demand, similar to how things work in Mac OS X. You could then print to any driver-matched printer on the Wi-Fi network to which your iOS device was connected. I thought that this was an unlikely solution, as the size of driver software is quite large — and could quickly lead to iOS devices (especially 8GB ones) running out of free space.
A second possibility was that printing would work only via printers that have the needed driver software built-in. The prime example here is Hewlett-Packard’s line of ePrint enabled printers. This would be a fine solution except that it would severely limit the range of printers that an iOS device could access.
A third possibility was that there would be no true direct iOS device-to-printer printing. Rather, you would print to printers accessible via Printer Sharing on a Mac. This would allow for the widest range of printer compatibility but has the downside of requiring that a Mac (or PC) be active and accessible as an intermediary between the iOS device and the printer. If your Mac is asleep, for example, you can’t print.
Today, Apple posted a press release that offered details as to how the new AirPrint feature would work in iOS 4.2 — largely resolving the debate among these three alternatives. So…which of the three options turned out to be correct?
The answer is two answers: iOS 4.2 will use both the second and third methods.
Devices running iOS 4.2 will be able to directly print to “HP Photosmart, Officejet, Officejet Pro and LaserJet Pro series ePrint enabled printers.” Apparently, this includes some HP printers not yet on the market — as I could not find reference to ePrint versions of all of these printers on the HP site.
In addition, “iOS 4.2 devices can print to printers shared through a Mac or a PC.”
The one thing that you won’t need to do to print from an iOS device is download printer software to the device.
A beta version of the iOS 4.2 software is available right now, but only for members of Apple’s iOS developer program. Developers report that, for printer sharing via a Mac, an update to Mac OS X 10.6.5 (currently in beta) is also required.
If you are an iOS developer, you’ll want to get the new “Drawing and Printing Guide for iOS.” It contains complete details on how printing will work, including screenshots of the new Print Center app in action.
One oddity: The press release states that printing will work with “iPad, iPhone 4, iPhone 3GS and iPod touch (second generation and later).” Based on what I have seen thus far, the printing feature requires multitasking — but multi-tasking is not available on the second generation iPod touch. Is this an error in the press release?
Update: Yes, the press release is in error. According to an iOS Developer page (login may be required): “Printing is available only on iOS devices that support multitasking.” The iPod touch 2nd generation is not listed as compatible.
Apple Patent to Kill Jailbroken Devices? Nope!
Aug 25th
For better or worse, Apple likes to keep the iOS as closed as possible. But calm down folks. There are limits beyond which even Apple won’t venture. Killing your jailbroken iPhone, without your permission, is one of them.
A few days ago, the Web was buzzing about an Apple patent, filed back in February 2009 but just now revealed, that describes new security measures that may someday (assuming the patent is ever implemented) appear in iOS devices.
Of particular interest, the language of the patent contained several references to jailbreaking, such as: “…an unauthorized user can be detected by noting particular activities that can indicate suspicious behavior. For example, activities such as…jailbreaking of the electronic device, unlocking of the electronic device, removing a SIM card from the electronic device,…can be used to detect an unauthorized user.”
It further stated: “When an unauthorized user is detected, various functions of the electronic device can be restricted.”
Numerous Web postings (such as this one from CNET) suggested that this could mean that, if Apple detects that you have jailbroken your device, it could remotely wipe your iPhone — or otherwise “kill” or “brick” it (the exact verb varies among different postings). Most ominously, Apple could do so without advance warning and without the permission of the owner of the device.
In other words, whatever else the new security measures might be able to accomplish — they would be yet another means by which Apple blocks jailbreaking.
I remain extremely skeptical that Apple has any such intent here. The truth is almost certainly more benign. This can be discerned via several phrases of the patent text, such as:
“The owner may desire to find out where the lost electronic device is located or who may have gained possession of or stolen the electronic device.”
“In some embodiments, an alert notification can be sent to a responsible party when an unauthorized user is detected. The ‘responsible party’ can be any persons suitable to receive the alert notification, such as, for example, the owner of the electronic device, proper authorities or police, persons listed in a contact book in the electronic device, or any combination of the above.”
In other words, the intent here is a system designed to help the owner (authorized user) protect the data on their iOS device, should that device be stolen. In this sense, it is an extension of what you can already do via Find My iPhone and Remote Wipe.
The logic is that an attempt to jailbreak your iPhone might indicate that someone is attempting to gain unauthorized access to your (confidential and protected) data. In this instance, and with your permission, certain security measures could be taken to prevent the unauthorized access.
The suggestions that the measures described in the patent would be used by Apple as a sort of virtual neutron bomb, killing any and all jailbroken iPhones (even if the jailbreaking had been done by the owner of the device and even if the owner would object to such “killing”), are simply ridiculous.
I have certainly been critical of many instances of Apple’s behavior in this arena over the years, especially as regards Apple’s restrictive App Store policies. But the current speculation assumes that Apple would go well beyond anything it has done this far. I don’t buy it. Actually (with the usual caveat that I am not a lawyer), it seems doubtful that Apple would have the legal authority to do so.
It’s one thing to try to prevent jailbreaking methods from working or to refuse to offer support for jailbroken iPhones. But, especially considering that jailbreaking is legal, to delete personal data from your iPhone without your permission? I don’t think so.
Let’s all take a deep breath. It’s time to calm down.
The Limits of Text Editing on an iPad
Aug 11th
As soon as Apple announced the availability of iWork apps for the iPad, I began imagining a time when I could sell my MacBook Pro and depend entirely on my iPad for getting work done when on the road. To be clear, I am talking about using the iPad for the limited subset of work-related tasks I need to do when traveling — not as a complete replacement for a Mac. The primary such task is writing online articles (such as this one!).
I recently returned home from a 10 day trip. I had both my MacBook Pro and iPad with me. As an experiment, I began the trip by attempting to get by with just my iPad. The iPad was superb for a wide variety of tasks: Web surfing, checking email, keeping up with Twitter, viewing photos, playing games, reading an ebook, and staying current with news, stocks, and weather. If these were all I needed to do, I would gladly sell my MacBook Pro tomorrow.
However, I also wanted to use the iPad to write a couple of articles. For this task, it was an almost complete failure. In less than an hour, I gave up in frustration and switched back to the MacBook.
I knew that the current version of the iPad might not make it in this regard. But I had been hopeful that, as the software and hardware inevitably improved, my imagined future might become a reality. I am no longer confident that this day is coming — at least not any time soon. Several of the problems I had did not seem easily surmountable:
• Hassles with the touchscreen interface. Even though I had a Bluetooth keyboard, I still had to use the touchscreen for frequently needed tasks such as repositioning the cursor. This proved to be a pain — slowing me down to a frustrating pace. A cursor controlled by a mouse or trackpad — or even the arrow keys on a keyboard — are far superior to my index finger trying to bring up the iOS’s loupe.
In one odd glitch, after opening a document in Documents To Go, I had to tap the touchscreen at least once before input from the Bluetooth keyboard started showing up on the screen. It took me several minutes to figure this out. At first I thought the keyboard was not working.
When I tried to type with the virtual keyboard, my frustration level soared higher. In this instance, I was trying to type with all fingers, as I would with a physical keyboard — rather than with the one finger typing I typically do when entering something brief like a Twitter post. The result was that my fingers too often touched the screen in such a way as to cause some unintended effect. The cursor might reposition, so that the next text I typed incorrectly appeared in a random part of the article. In other cases, I wound up deleting an entire paragraph of text (thanks goodness for Undo) or closing a document entirely. It was impossible for me to type for more than a minute without some error interrupting my workflow.
• No multiple windows. Having to switch back and forth between apps for something as simple as copying a URL in Safari and pasting it in a text document proved much more arduous to do on an iPad than on a MacBook. Even when multitasking comes to the iPad, it will not be convenient enough to make such tasks as efficient as they should be. It can take considerable effort just to get a URL successfully selected and copied.
• Weak text editors on iOS devices. Even If I could easily get a URL from Safari to a text-editing app, I’d still have the problem of what to do with it. As far as I know, there is no text editor for iOS devices that allows the creation of hypertext links for URLs. This is just one of several job-critical features that I cannot do with the current crop of iOS text-editing apps.
A partial solution here, at least for articles intended to be posted online, is to work directly in a web-based editor via Safari, rather than a text-editing app. These can be more full-featured than any iOS app. Still, I prefer to work offline until I am close to a final draft. The web solution also doesn’t work for those occasions when I have no Internet access (such as on a airplane).
Some of these problems seem almost inherent to the nature of a touchscreen device. Others seem likely to require more changes to the iOS than we are likely to see within the next couple of years. Similar issues affect other work-related tasks on the iPad, such as Keynote presentations. Perhaps the answer is to accept that the iPad is not intended to be a MacBook replacement — even in the limited sense I have described here — and never will be. Or perhaps I just need to wait longer than I anticipated. Regardless, at least for now, my imagined future of an iPad sufficient to get work done on the road has been put on indefinite hold. Don’t expect to see my MacBook Pro posted for sale any time soon.