Two days ago, I released an update to my Halftone app for iOS that adds an oft-requested feature: the ability to open photos directly from Facebook, Flickr, and Instagram. The new image picker is the result of more than a month of design and development work, the same code base runs across all devices (with a tailored UI for each device), and it serves as a drop-in replacement for the native iOS image picker. I’m proud of the final product, so I was dismayed to read one of the first tweets about the new version:
One of my favorite apps (Halftone) just updated & added location services as a “key” to continue using the app … WTF?? DELETED!!
Shortly thereafter from another customer:
@juicybits requiring using location services to use app?? 1 star rating
But I’m getting ahead of myself.
Prior to this update, Halftone used the native, built-in UIImagePicker control that every iOS owner is familiar with. It’s the same control that you see when opening an image in most apps. From the app’s perspective, using the image picker is straightforward:
- The app asks iOS to display the image picker
- You interact with your albums and photos and select an image (or choose to cancel)
- The selected image is handed to the app for its use
Note that the app has no direct access to any of the images, and in fact, it doesn’t even know how many albums or images are on your device. All it knows about is the single image that you picked, and when that image is handed to the app, almost none of its metadata is included (like the date and time the photo was taken, exposure information, and GPS coordinates).
For apps that need access to a single image without metadata using the standard look-and-feel, the UIImagePicker control is a fantastic, familiar, and easy to use solution.
However, if an app requires a customized version of this workflow, if it wants to provide a different presentation, or if it needs access to any image metadata, it has to use the ALAssetsLibrary functionality that Apple introduced in iOS 4.0. While ALAssetsLibrary does not provide any standard user interface elements, it does enable an app to access all of the albums and photos on a device.
And—most importantly for this article—ALAssetsLibrary has access to all of the image metadata.
For Halftone, I wanted to build an image picker that would take full advantage of the available screen space, work in all orientations, and have a single codebase for all devices. Not only did it need to pick photos from the device, but it also needed to allow users to just-as-easily pick photos from Facebook, Flickr, and Instagram in a consistent way. So that’s what I built, and as you can now surmise, the new image picker relies on ALAssetsLibrary. Here’s an iPhone screenshot of the new image picker on the Facebook tab:
Many modern cameras and most smartphones (including the iPhone) can automatically embed GPS coordinates that record where a photo was taken. These coordinates are stored in the image metadata, and if you’ve ever used an app that places photos on a map, it’s easy to understand how this location information can be used. It’s likely that you have photos on your iPhone right now that contain these coordinates.
For apps that only use the built-in UIImagePicker to open images, none of the GPS metadata is handed to the app. Not even the date and time the photo was taken. Just the image itself.
For apps that use ALAssetsLibrary, though, all of the image metadata is available, including the GPS location. So, what do you think happens the first time any app tries to use ALAssetsLibrary? Bingo! Because the app could access the location where an image was taken, iOS displays this prompt:
If you’ve read this far, the prompt may not be surprising at all. In fact, if you’re not surprised, I’ll pat myself on the back for a job well done. Good job, Mike!
Well, if you’re among the one million+ casual Halftone users who will never (and should never) read this post, I can tell you that it’s baffling. Especially the misleading initial text: “Halftone” Would Like to Use Your Current Location. No it wouldn’t. It doesn’t do anything with your location. As a matter of fact, it doesn’t even want to see the location metadata in your photo!
Let’s remind ourselves of one user’s response to this prompt:
@juicybits requiring using location services to use app?? 1 star rating
Without any context, this unexpected prompt makes it sound like Halftone is trying to track your location. For users who have heard about the recent misappropriation of address book data by well-known apps, it’s no surprise that they choose “Don’t Allow.” I’d do the exact same thing.
The problem is that by disallowing this permission, Halftone can no longer use ALAssetsLibrary to read photos from the device…at all. From a user’s perspective, Halftone used to be a trusted app that allowed me to open my photos, but this “new and improved” update not only wants to track my location, but it won’t show me the photos on my own device! #epicfail!
To explain why Halftone is prompting for Location Services approval, the new version displays this pop-up just before the prompt:
Normally, I’d never try to explain a complex topic like this to a user who only wants to access their photo library. But, in this situation, it’s important that the user understands why they’re being asked, because the new functionality is dependent on approval. I loathe having to display this text.
Other well-known iOS apps that use ALAssetsLibrary have tried similar approaches. For example, here’s the screen that Dropbox shows just prior to the approval prompt:
For Dropbox users who notice the small little arrow after “Permission is needed to access your photos,” they are treated to a long explanation similar to the one that Halftone uses. They even go so far as to provide a link to the Apple developer documentation for ALAssetsLibrary, which contains this small snippet of text:
Special Considerations
This method will fail with error ALAssetsLibraryAccessGloballyDeniedError if the user has not enabled Location Services (in Settings > General).
Of course, the Dropbox app doesn’t depend on photo access, so denying this permission has no significant impact.
Another example is Mixel, an iPad app by Khoi Vinh that does depend on access to photos. It’s a very well-designed app that takes advantage of ALAssetsLibrary to provide an improved user experience. I envy the simplicity of Mixel’s approach in that there is no attempt to explain anything about Location Services. The permission prompt is displayed by iOS, and if the permission is denied, the following screen is displayed:
Basically, it instructs the user to go into the Settings app to enable Location Services. Until that happens, Mixel has no access to photos on the device.
Here’s a bug report by Sean Heber of Iconfactory explaining similar challenges. In this case, Twitterific uses ALAssetsLibrary to get the most-recent photo from the camera roll so it can easily be attached to a tweet. Based on what you’ve read in this post, you now understand why it’s necessary for Twitterific to use ALAssetsLibrary: it needs access to photos and their dates. From his report:
…after being deployed for only one day, the support issues involving the location services question are flooding in.
Many people reflexively deny location permissions…
We could present the user with an alert if they deny permission explaining what just happened, but that seems annoying, too, and we’re not sure it’d really help since it’d happen after they already denied it meaning that to undo the “Don’t Allow” damage, they’d have to told to leave the app and hunt through Settings to flip a switch back on!
I couldn’t agree more.
Here’s a post by Andreas Lindahl expressing a similar frustration with his recent app. He needed to use ALAssetsLibrary because the standard UIImagePicker control doesn’t support landscape orientation. He’s also seeing negative reviews, and his app has no interest in location metadata.
So, what can be done to improve this situation?
To start, let’s agree that ALAssetsLibrary provides functionality that the majority of photo apps (and other apps like Dropbox) can use to provide an improved user experience. It’s good for users, and it’s good for apps.
Let’s also agree that the current “App” Would Like to Use Your Current Location prompt is at least confusing, more likely misleading, and in some cases, even alarming to users.
For apps that have no interest or use for location metadata (and I would argue that this is the vast majority), there’s no need for this information to be passed to the app.
Here are two solutions that Apple could implement in a future version of iOS that would make the use of ALAssetsLibrary much more appealing to app developers. Only one of them would need to be implemented.
The first option would be to add a parameter to ALAssetsLibrary during initialization that allows the app to request access to location metadata. In Halftone’s case, it would never ask for this permission, and as a result, there would be no Location Services prompt from iOS, there would be no “why are we asking for Location Services approval” explanation, and the new functionality would just work.
The second option would be to continue to prompt for permission for ALAssetsLibrary but with a more appropriate message (e.g. “Halftone would like to use the location information in your photos”). If a user denies this permission, ALAssetsLibrary would still allow access to images, but it would also strip away any location metadata before handing the images to the app.
Of these two options, I personally prefer the first, because it more accurately reflects the intentions of the app. Based on my experience, accurately codifying an app’s intentions will provide Apple with more architectural flexibility as ALAssetsLibrary continues to evolve in future releases.
In the end, either of these improvements will make life better for users, app developers, and Apple. I think we all agree that protecting sensitive and private user information is a requirement, and I support proposals like the iOS permission dialogs that Marco Arment of Instapaper has outlined in his post. However, in the case of ALAssetsLibrary, the current heavy-handed approach is not only confusing users, but it is also preventing developers from providing an improved user experience in their apps.
Leave a Reply