As we approach the last few months of the year, the holiday season looms large — not just because decorations start to appear early in stores, but because companies like Apple need to release the products they hope people will buy in vast quantities as gifts. Unlike last year, where the iPhone was the last push for the calendar, Apple is following up the iPhone 5 release with a media event on Tuesday, 23 October 2012, where a smaller “iPad mini” is expected to be announced.
We don’t focus on rumors at TidBITS, but the murmurs of a new iPad model have been hard to miss over the past several weeks. My guess is that we’ll see a 7-inch or 8-inch iPad that’s designed to compete with devices such as Amazon’s Kindle models and most Android tablets, emphasizing a lightweight design and Apple’s app and media ecosystem. Other rumors also suggest revisions to the Mac mini and possibly the introduction of a 13-inch MacBook Pro with a Retina display.
We’ll know for sure on Tuesday. I’m flying down for the event and will offer hands-on impressions, while the rest of the TidBITS staff will follow various liveblogs and write up the news as it happens.
Read and post comments about this article | Tweet this article
Don’t show this article to your boss if you’re trying to get approval to attend MacTech Conference 2013 next year (6 November 2013 through 8 November 2013). Simply put, if it’s anything like this year’s conference, the bean counters may cast a jaundiced eye on your request to travel to Los Angeles. Don’t get me wrong, if you’re in IT, or you’re a Mac or iOS developer, the days are packed with high-quality technical talks by a host of experts in the community.
What’s different from any other conference I’ve attended was the evening entertainment, most notably a post-dinner trip to Disney Animation Studios for behind-the-scenes discussions of how Disney’s animated movies are made and a pre-release screening of the upcoming film “Wreck-It Ralph.” This wasn’t a canned tour — the Disney employees who donated their evening to chatting with conference-goers were the actual people who worked on the animation, did the storyboards, ran the servers (I heard snatches of conversation about 1000 cores and 5 petabytes of spinning disk storage!), and more. No photography was allowed, and cell phones were confiscated temporarily before the screening, so I did the adult thing and left my iPhone in the hotel — I had to keep reminding myself that the lack of the iPhone’s weight in my pocket wasn’t reason to panic. And yes, if you remember the 1980s video games fondly, go see “Wreck-It Ralph” — it’s great even if you don’t get an introduction to it by Disney Animation’s director of IT. With his encyclopedic pop culture memory, my buddy Andy Ihnatko has written the definitive description of the evening.
The second evening’s after-dinner entertainment was less structured — the entire conference traipsed up the hill to Jillian’s in Universal City. Here I wasn’t much of a social butterfly, opting to play pool and old video games (the wonderfully abstracted Space Invaders and Asteroids and Donkey Kong in original cabinets) with Andy, with whom I seldom have a chance to spend time at larger shows like Macworld Expo.
But don’t assume that there was anything but full mingling among the speakers and the attendees. MacTech Conference included eight catered meals, and at each one I ended up sitting with a different group and discussing everything from the importance of interpersonal skills in IT to the effectiveness of iPad trials in K-12 education to doping in world-class cyclists and triathletes (Mac users are nothing if not eclectic!). Equally interesting and useful were the hallway conversations in between the sessions.
In short, much as with the late lamented MacHack and C4 conferences (which were focused solely on developers), Neil Ticktin and his MacTech crew went to astonishing lengths to organize the kind of events that build a sense of community among the attendees.
The sessions themselves were a bit harder for me to evaluate, given that I’m neither a developer nor an IT guy, so I have to admit to glazing over slightly during a detailed discussion by Ben Levy, Phil Goodman, and Steve Leebove about how to use Apple’s iPhone Configuration Utility, Apple Configurator, and Profile Manager in OS X Server. But I thoroughly enjoyed the IT Labs discussion on scripting led by Ben Waldie and Armin Briegel (who was kind enough to whip up a simple AppleScript script for Calendar that solved a problem I’ve had). Also, Andy Ihnatko gave an inspired talk exhorting developers not to ignore edge cases, pointing out that if the developer of an iOS app ignores even 1 percent of the potential audience as an edge case, that could be millions of potential customers lost. For the truly geeky, Sandy Krasner of NASA’s Jet Propulsion Laboratory shared all sorts of technical details about how JPL communicates with the Curiosity rover on Mars — perhaps that’s not exactly useful to most of us, but it was a revealing look into what “rocket science” really involves today. And lastly, my own “Working with the Press” panel, with Andy, Victor Agreda and Kelly Guimont of TUAW, and Seth Weintraub of 9to5Mac, brought together great advice for developers trying to get coverage for their apps — as always, I wish we could have gone longer.
I’m writing this in the airport on the way home, and I’m both exhausted and exhilarated, since the conversations I had during the conference (plus pre- and post-conference visits with TidBITS and Take Control stalwarts Michael Cohen and Matt Neuburg) left my mind racing with possible TidBITS articles, Take Control ebooks, and other things we might be able to do. That’s the real win of a conference like MacTech — leaving the everyday routine for a few days of immersion with smart, interesting people opens all sorts of mental doors, regardless of what it is you normally spend your days doing.
Read and post comments about this article | Tweet this article
When Apple added AirTunes to the Mac in 2004, the feature made it child’s play to send “tunes” from iTunes over the “air” to any AirTunes-savvy device on your local network, most notably an AirPort Express that you had connected to a stereo system with a cable. Times changed, as did the name of the feature, redubbed AirPlay in 2010. In its most feature-rich mode before the release of OS X 10.8 Mountain Lion, AirPlay could output not only audio but also the entire screen from newer iOS devices (the iPad 2 and later, and the iPhone 4S, and now the iPhone 5) through a second- or third-generation Apple TV, a capability called AirPlay Mirroring.
(For those who want more flexibility with sending wireless audio between devices, Rogue Amoeba’s Airfoil can send audio to any AirPlay-capable device or any device running the companion Airfoil Speakers app for Mac OS X, iOS, Windows, or Android. For basic, if old, details, see “Airfoil Plays Home Audio Wirelessly,” 10 March 2008)
With the release of OS X 10.8 Mountain Lion, Apple has brought AirPlay Mirroring to the Mac, enabling you to output audio or video via AirPlay from sources other than iTunes. Specifically, you can now make AirPlay your default sound output destination for system audio and send your entire screen to an Apple TV. Audio output can be directed to any appropriate AirPlay-savvy device, with third-party speaker systems joining Apple’s own AirPort Express and Apple TV. For details, read on, and also be sure to check Apple’s support article on using AirPlay.
Stream Audio -- To stream audio from your Mountain Lion Mac, simply select your desired AirPlay device in the Sound pane of System Preferences, in the Output view. To test your settings, select a sound file in the Finder and press the Spacebar to start playing it via Quick Look.
While you’re in the Sound preference pane, you may wish to select the “Show volume in menu bar” checkbox, if it’s not already enabled. That’s because — once the Sound icon appears — you can Option-click it in the menu bar to choose an output device (whether an AirPlay device or not). If you have more than one AirPlay device, however, note that your Sound menu currently shows only the most recently selected AirPlay device.
Mirror Your Mac’s Screen -- This feature has added fun and function in my home with our Apple TV/TV combo. We’ve used it for group HTML-editing sessions, following along with online videos of stretching routines, and sharing photos straight from iPhoto with visiting family.
(The fine print on this feature eliminates certain Macs that can run Mountain Lion but can’t offer AirPlay Mirroring. You need an iMac [Mid 2011 or newer], Mac mini [Mid 2011 or newer], MacBook Air [Mid 2011 or newer], or a MacBook Pro [Early 2011 or newer].)
To enable AirPlay Mirroring, click the AirPlay icon on the menu bar and choose Apple TV. If you don’t see the AirPlay icon, open the Displays preference pane and select “Show mirroring options in the menu bar when available.” Once you are mirroring, notice that the Display view of the Displays preference pane now shows more mirroring options. You can try each option to see if it improves your mirroring experience.
Missing the Old Display Menu Bar Menu? -- The AirPlay menu bar menu in Mountain Lion has displaced the Displays menu bar menu found in older versions of Mac OS X. Some people are understandably unhappy about this, because they liked being able to quickly switch certain display characteristics, such as resolution, from this convenient menu instead of working from the Displays preference pane. Fortunately, help is at hand in the form of Display Menu, a free utility by Thorsten Karrer. I haven’t used it in any real way, but it does basically work with my two-monitor Mac setup.
AirPlay into the Future -- Keep an eye on AirPlay — I believe it’s a more important technology than might be evident at first glance. In essence, AirPlay lets us redirect audio and video from one device to another, which could enable some interesting possibilities, particularly if input methods were added. Perhaps a future version of AirPlay could enable you to move fluidly between using an iPhone’s screen and other interactive displays, much as is imagined in this example in Corning’s “A Day Made of Glass” concept video (the link takes you 1:45 in).
Read and post comments about this article | Tweet this article
So much happens behind the scenes on our computers that at times technology can seem magical. For example, when a new email message arrives, Notification Center alerts me simultaneously on both my Mac and iPad. As with most daily technological magic, I didn’t think much of it until I was editing Joe Kissell’s immensely helpful “Take Control of Apple Mail in Mountain Lion”, when Joe and I had an enlightening discussion that took place in the manuscript’s margin comments.
At issue was Notification Center in OS X 10.8 Mountain Lion and how mail notifications would work with it. I proffered the suggestion that Notification Center in Mountain Lion would hook up with the same push service that iOS devices used, and was surprised when the manuscript came back to me with a comment from Joe saying that Apple Mail on the Mac did not use push services in earlier versions of Mac OS X and, more importantly, would not be using them in Mountain Lion. I was doubly surprised because, just as I was reading his comment, I heard the new mail sound simultaneously from both my Mac (running 10.7 Lion) but also from my nearby iPad. I knew my iPad was using push services, but what was Apple Mail on my Mac using that could account for the simultaneous new mail sound? It may not have been push email on my Mac, but it sure seemed to act the same as push email on my iPad to me!
A little bit of research provided the answer: Apple Mail in Mac OS X uses an optional bit of the IMAP (Internet Message Access Protocol) specification — the IDLE command. The clue that quickly led me to the answer was an option in the Advanced pane of Mail’s Account preferences: “Use IDLE command if the server supports it.” For my iCloud email account, this option was checked by default.
A Little IMAP Background -- IMAP is an advance over POP (Post Office Protocol), which was the way email used to work in the deep dark past of the Internet, and which, to the dismay of some, still is used by many email services today.
With POP, incoming messages arrive at the mail server and remain there until the client (that is, your email program), fetches them from the server and, optionally, removes them from the server. The mail server only keeps track of the messages on it; it doesn’t record whether you have actually read or downloaded the messages. Those tasks are the responsibility of the mail client. Thus, you can fetch messages from a POP server with your mail client, and, if that client doesn’t delete the messages from the server, you can fetch them again using another mail client (on the same computer or a different one), and those messages appear in that client as brand-new unread messages.
With IMAP, the mail client displays the messages as they exist on the server. The client may or may not download the messages to the local device — that’s not important. What is important is that the IMAP server knows when the client reads a message. This means that when you read your IMAP mail with one mail client, and then connect to your account with a different client (on any device or computer), you can see which messages you have already read, regardless of the client with which you read them. If you use multiple devices, IMAP’s advantage is synchronization of which messages have been read or deleted. For example, you can read a message on your iPhone and later find it marked as read on your Mac. This discussion intentionally scratches only the surface of IMAP, but the takeaway is that IMAP mail clients and servers can have much more complex “conversations” than those allowed by the more basic POP protocol.
Back to IDLE -- What does all this have to do with arriving email notifications? After all, whether the protocol is POP or IMAP, the mail client still has to connect to a mail server and send a request to it asking for mail. Except, that is, for when an IMAP server supports the IDLE command.
When a mail server lets a mail client know that it can respond to the IDLE command (Apple’s iCloud servers do, though many others don’t), the client can send the IDLE command to the server with the following result: the server maintains an open connection between it and the client so that, when new mail arrives, the server can immediately let the client know about it. Then the client can inform the user that new mail is available. (This description of how clients and servers use the IDLE command, of course, is almost criminally over-simplified; you can read all the geeky details in RFC 2177.)
So, the reason I know that I have new mail available on my Mac is because Apple Mail and the iCloud server are in constant contact with one another. The iCloud server says, “You have mail,” and Apple Mail says, “Oh, goodie, let me see it.” Plus, in Mountain Lion, Mail lets Notification Center know about it, too.
What about Push? -- IDLE in IMAP is relatively old: it was first specified late in the last century, a decade before the iPhone saw the light of day. IMAP IDLE assumes that the mail client is running and can maintain an open network connection to the mail server. That’s great for devices plugged into a power source and an Ethernet network, but not so good for a pocket-sized device with a tiny battery and a potentially expensive connection to a cellular data network. That’s where push comes in.
In iOS, there isn’t a whole lot of memory to support simultaneously running apps, nor enough battery power to keep a bunch of them active at any one time. There is, however, enough of each to keep a small program semi-awake and aware in the background so it can listen to the mobile network. That’s how Apple’s push system works.
With push, an iOS app registers with that small background program in iOS, informing it that the app expects to receive network notification messages — even when the app isn’t running! That small background program in iOS listens to the network and fields incoming communications, sending the appropriate notifications to the apps that have requested them.
On the other end, remote applications, such as mail servers, can register with an Apple Push Notification (APN) server, passing that server a token that identifies which device out there on the Internet is interested in receiving notification messages. It’s Apple’s APN servers that send the notification messages to the iOS device from the remote application.
The path is something like this: the mail server receives new mail for you and sends a notification message and a device token to the APN server. The APN server then sends the appropriate data to the small background program running on your iOS device so you can hear the new mail sound, see the badge number change on the Mail app’s icon, and read a brief summary of the incoming mail’s content (the push system can send a notification payload of no more than 256 characters). When you open the Mail app on your iOS device, the Mail app then establishes a full IMAP connection with the remote mail server so you can read the entire message.
(There’s yet another push technology Apple devices can use: Microsoft’s ActiveSync; curious readers can find out more about how that works in the Microsoft article, “Understanding Direct Push.”)
Subtle Differences -- These two systems, IDLE and push, account for the multiple notifications I received simultaneously on my iPad and on my Mac when the new message arrived in my iCloud account. But there are subtle differences in behavior between the two systems.
On the Mac, you receive new mail notifications only when the Apple Mail application is running, because the conversation between Mail and the mail server is what enables notifications to be made. When Mail is not running, or your Mac is asleep (and isn’t using the Power Nap feature in Mountain Lion), your Mac has no way of knowing when new mail arrives, so you don’t get notifications.
On an iOS device, you always receive notifications as long as your device is turned on and has a network connection — even when the device is asleep, that little background program is awake enough to receive incoming push notifications. (By the way, that’s why you can eke out a little more battery life if you disable push on your iOS device: that little background program doesn’t use much power, but it uses some.)
However, the Apple push system provides for notifications that travel from the APN service to the iOS device; it doesn’t send messages back the other way. So, if you get a notification on your iOS device telling you that you have new mail, and you read that mail on a different device (like, say, your Mac), the iOS device won’t know you have read it (and won’t adjust the number in the badge on the Mail app icon) until you open the Mail app and establish the IMAP connection between your iOS device and the remote mail server.
If that seems slightly awkward, it is. As Joe Kissell has pointed out with regard to alerts in “An Alarming Abundance of Alerts” (13 May 2012) and as has become problematic with Messages, Apple needs to do something to reduce the duplication of events that currently happen simultaneously on multiple devices. In an ideal world, these notification systems would understand which device is in use and cascade appropriately to other devices as necessary.
So there you have it: Apple is using two completely different notification systems that produce very similar results. And all so you can get your singing cat emails as soon as possible, no matter what device you are using!
Read and post comments about this article | Tweet this article
Last year, although I already owned an iPhone 4, the greatly improved camera in the iPhone 4S convinced me to buy the new model — I may take most of my photos with a Nikon D90 DSLR, but since my iPhone is always with me, it gets plenty of use as a camera as well. This year, the iPhone 5’s A6 processor and camera hardware enhance the device’s photo capturing capabilities, providing improved video stabilization, faster capture, and better low-light sensitivity and noise reduction. For now, my iPhone 4S is still fine, so I’m holding off on upgrading (famous last words). Fortunately, I and other owners of the iPhone 4, iPhone 4S, and camera-enabled iPod touch models benefit from other photo improvements in iOS 6.
Panorama -- Not content to stick with “Makes pretty pictures” as a marketing point, Apple added a new feature to the built-in Photos app: Panorama. Instead of capturing one shot, the panorama feature stitches many images together as you pan across a scene to create a long (or tall) photo. Panorama works only on the iPhone 5, iPhone 4S, and fifth-generation iPod touch, and not on any iPad models or older iPhone and iPod touch models.
For example, here’s a single shot from my iPhone 4S:
And here’s the same location captured as a panorama:
To access the feature, open the Camera app and tap the Options button, and then tap the Panorama button. Holding the iPhone or iPod vertically, tap the shutter button and then pan the device left to right. An arrow indicates not only the direction and progress of the shot but also helps you maintain a level line while panning.
As you capture the image, the Camera app evaluates the scene and captures the image progressively; it’s not just taking sequential snapshots every second or so. The arrow also tells you if you’re moving too fast, too slow, or need to move the device up or down. You can tap the shutter button at any time to end the capture; you don’t have to move all the way to the end of the line.
Minor variations from the level line aren’t a problem: the app crops to fill the area with good pixels. If, on the other hand, a bee buzzes your head and you go way off-line, you’ll end up with blocky black areas where the image sensor couldn’t capture any pixels.
This gradual sampling approach has impressed me with how well it handles shifts in exposure across a scene. To test it out, I deliberately shot a panorama where I’d be facing the sun. The area to the right of my image is dark, but not completely dark as it would be if the sensor was exposing for direct sunlight.
Panorama images appear in your iCloud Photo Stream (if you’ve enabled the feature) just like any other photo captured with an iOS device. Our own Michael Cohen pointed out a neat tip: In iPhoto, when you view panoramas in a slideshow using the Ken Burns theme, the application smartly pans left and right across the image instead of zooming in and out.
Shared Photo Streams -- iCloud’s Photo Stream feature is a great way to demonstrate one way “the cloud” works: capture a photo on your iPhone and within minutes the picture appears on your other devices. But Photo Stream has been a single-user feature. You couldn’t easily publish images from your stream where others could see them, unless you count showing them to a room full of friends on a television via Apple TV.
The new Shared Photo Streams feature gives you the capability to publish collections of photos to other people or to the Web. But before you consider letting your Flickr subscription expire, you need to understand just what Shared Photo Streams do, and their current limitations.
Think of a service like Flickr as being like pinning a bunch of photos onto a corkboard where anyone walking by can see them. As long as you know the Flickr address for my account, for example, you can view all images I’ve made public.
By contrast, a Shared Photo Stream is like making prints of some photos and giving packets of them to select friends. When you create a Shared Photo Stream, the images you choose appear on your friends’ devices after they’ve confirmed they want to view them.
It is also possible to make a Shared Photo Stream public for people to view on the Web, but the address that’s generated (such as
http://www.icloud.com/photostream/#A35WXqd93p0tj) is machine gibberish. And, oddly, the links don’t seem to work in Safari, whereas they do work in Google Chrome, Firefox, and Camino (though the photos come in very slowly).
Here’s how to create a Shared Photo Stream:
In the Photos app on an iOS device, navigate to the Photos or Photo Stream view and tap the Edit button.
Tap to select the photos you want to share.
Tap the Share button and then tap the Photo Stream button.
In the dialog that appears, tap the New Photo Stream option. (This dialog appears only after you’ve created your first Shared Photo Stream; for the first one you’ll go immediately to Step 5.)
Type the names of people you want to share the photos with in the To field, or tap the Add (+) button and choose from your list of contacts. Note that you don’t need to include anyone to create a Shared Photo Stream, and you can leave this field blank (in case you want to add people later, for example). And, by the way, be prepared for when people accept your offer to subscribe to the set: the Notifications feature under OS X 10.8 Mountain Lion blares an alarm (it’s a nice tone, but still surprised the heck out of me the first time). You can disable this option in the Notifications preference pane by selecting Photo Stream in the sidebar and turning off “Play sound when receiving notifications.”
Give the stream a title in the Name field.
If you want to make the Shared Photo Stream available to anyone, switch the Public Website option to On.
Tap the Next button.
On the next screen, optionally enter a comment that people will see in the email that’s sent. The comment must be under 200 characters, although the field doesn’t offer a character count the way it does when sharing something to Twitter. And, oddly, the comment is attached to the last photo you added to the set. Tap the Post button to publish the stream.
The Shared Photo Stream appears in the Photo Stream view of the Photos app.
The appeal of Shared Photo Streams, of course, is that they also appear on your friends’ iOS 6-capable devices and third-generation Apple TVs. So when my mother wants to use her iPad to show off photos of her granddaughter when she’s with her friends, she doesn’t need to mess with iPhoto, syncing iTunes, or bringing up photos in Safari. The photos just appear. (They also show up for 10.8.2 users in iPhoto 9.4 or later or Aperture 3.4 or later, but not for those running iPhoto or Aperture under 10.7 Lion.)
In fact, I can add photos to an existing Shared Photo Stream at any time by selecting the image, tapping the Share button, choosing Photo Stream, and then specifying the stream I want. The sharing is unidirectional, though: a subscriber cannot add their own photos to a stream that you created.
One interface oddity crops up on the iPad, however. If you want to edit the details of a stream, such as add a new subscriber, there’s no obvious way to do it. You must tap the Edit button, and then tap the Shared Photo Stream — a new interface convention for the Photos app, I believe, that I had to stumble over accidentally to find. On the iPhone or iPod touch, a blue Details (>) button appears to the right of the stream name.
Shared Photo Streams also have one other addition that now seems like a prerequisite for any modern photo feature. Anyone subscribed to a set can comment and “like” photos. The comments show up superimposed over the bottom of an image when you tap the Comment button and are visible to anyone subscribing to the set.
Miscellaneous Photo Changes -- Panorama mode and Shared Photo Streams are the biggest updates to photos in iOS 6, but they aren’t the only changes.
As you would expect, the Places view in the Photos app now uses Apple’s new Maps data and interface. Any photo tagged with location coordinates shows up on the map, which presents just the default view, no satellite or hybrid views. (iPhoto and Aperture still use Google map information for their Places views, but I’m sure the next major revisions will switch to Apple’s service.)
Overcoming a long-suffered annoyance, the Mail app now lets you insert a photo or video into an outgoing message from within the app; previously, you had to first navigate to the Photos app (or any app that could access the device’s Camera Roll), choose a photo, and then share it to Mail. When you’re composing a message, press and hold for a second to bring up the toolbar of options, which now includes an Insert Photo or Video option.
One interesting side effect of this route can bite photographers if they’re not careful, though. If you imported photos that are in a raw format (such as .CR2 or .NEF) from a digital camera — using the iPad Camera Connection Kit, say — Mail grabs only the low-resolution preview. If you want to send the original raw file via email, you must share it from the Photos app.
I’ll wrap up with an annoyance that’s puzzled me since the first iPad and that remains unchanged. The Slideshow feature in the Photos app inexplicably plays just one song. When you tap the Slideshow button, you’re given the option to Play Music, but your only option is to locate and select a single tune. I can only assume that either no one actually uses the music feature of slideshows, or Apple engineers only have time to show each other three-minute slideshows.
Read and post comments about this article | Tweet this article
For ExtraBITS this week, we have links to an article by Glenn Fleishman about what it was like to be on Jeopardy (alas, the actual shows aren’t online) and to an interesting overview at MacStories of where in the world Apple sells its media properties.
What Is Apple’s Share of Worldwide Media Sales? -- Journalists and analysts in the United States often forget the impact that Apple’s worldwide presence has on the company’s success, but it’s significant. Graham Spencer at MacStories has put together an impressive overview of where Apple sells its media properties: music, movies, TV shows, ebooks, and apps. He also includes the same figures for Microsoft, Google, and Amazon.com as comparison, demonstrating that Apple maintains a sizeable head start on the rest.
TidBITS Editor Glenn Fleishman Appears on Jeopardy -- Watch TidBITS’s own Glenn Fleishman have his wits and reflexes challenged on the Jeopardy quiz show! (Sadly, the shows are not available as streaming media or after their initial broadcast.) In the linked article at the Economist, Glenn explains his cramming strategy.