This Week's Sponsor:

1Blocker

A Cleaner, Faster, and More Private Web Experience

Posts in stories

The iOS Permission Dialog Dilemma

For anyone who used Windows Vista, you will be well aware of the frustration that UAC (User Account Control) caused. That permission dialog popped up far too frequently, constantly asking the user for permission to execute a particular task. In theory, it was a good idea: give the user more control over what was allowed to run. The problem was that because the dialog box popped up far too often, people quickly learned to ignore it and blindly click “Allow” whenever it appeared - nullifying any of the security benefits of UAC. Thankfully Microsoft relaxed the pervasiveness of UAC in Windows 7 and it is now a far more useful security tool.

Why did I just spend a paragraph talking about UAC? Because to a certain degree, Apple is facing a similar dilemma with iOS and its permission dialogs. It recently faced scrutiny after it was revealed that a number of apps were accessing a user’s entire address book and even uploading it to their servers - without any user approval. Apple has now pushed back and announced it will soon require user permission for apps to access a user’s Contacts. But will it resemble yet another blue dialog box, just like access to Location, Push Notifications and Twitter already do? If so a user will face a barrage of those dialog boxes, asking for permission, one on top of the other.

It’s after reading Marco Arment’s thoughts on this issue earlier today that I thought I would weigh into the discussion and suggest one idea that may (or may not) be a potential ‘solution’. While there can never be a single solution that will be perfect for everyone (what may be overly cautious for one user may be overly lenient for another) the goal as I see it is to arrive at a solution somewhere in the middle ground; one that achieves an acceptable mix of precaution and freedom.

Essentially, my suggestion is that rather than let users face a stacked barrage of blue permission dialogs, is to flatten them all out on one clear screen when they first launch an app after installation. Users would see a list of what the app would like permission to access and the user would be able to (with one tap) allow all, or individually deny permission for the various databases. Furthermore, with one tap, a user could see a short justification from the developer for why the app is requesting that particular access - giving a little bit more control and peace of mind to the user. If a developer lied on this page it would almost certainly be grounds for expulsion from the App Store. The one final goal of my proposal is that it would also inform the user that these options can be changed the Settings, something many users may not be aware of at the moment.

I myself am not sure this is the best option, because there is one critical weakness. With my design, an app would have to upfront ask for permissions for whatever it might want to access in the future - but as Marco points out, some apps (like Instapaper) require access to something like Location for a minor feature that not everyone would even use (in that case it is to determine if it’s night at the users location, in which case it can switch automatically to dark mode).

If I asked most careful people if Instapaper could have their location, they’d refuse, because there’s no obvious good reason. But if the app asks right when they enable a location-based setting from a screen that shows why it’s asking for their location, they can make a more educated decision. Similarly, if an app doesn’t seem to have a good reason when it asks for Contacts, a skeptical person can decline.

Although to counter that point, I would note that not only can a user choose to individually deny Instapaper access to their location, but if they were curious as to why Instapaper would need access to their location, they could quickly read Marco’s explanation with one tap. Furthermore, my suggestion wouldn’t entirely remove the blue permissions dialog, as an app could ask again for permission later on if access was initially denied but a user is trying to use a feature that requires permission – in that case, the app could trigger the dialog to ask the user permission again.

Accompanying my suggestion would be something similar to Rene Ritchie’s app permission sheet in Settings. It would list all apps that have asked for permissions and you could dive in and edit those original options from when you first installed the app. As for allowing an app to send push notifications, I would probably keep that separate, as its own blue dialog box. My permissions “screen” would be solely dedicated to access permissions, to information that is privately stored on your device. One big benefit of such a permissions screen of course is that Apple could theoretically add more things that require permission to be accessed by apps, without a user becoming too overwhelmed, because such a layout is far better than stacking dialog boxes. Think about access to NFC or perhaps your music library.

OS X Mountain Lion: The iOS-ification Continues This Summer

Earlier this morning Apple caught the Internet by surprise with a series of major announcements regarding the future of OS X. To put it simply, Apple officially unveiled OS X Mountain Lion, or version 10.8, the next major iteration of OS X that will become available later this year – the initial targeted release date is a vague “this summer” – through the Mac App Store. A preview of Mountain Lion was given to a few selected tech blogs, including The Verge, Macworld, Daring Fireball, and The Loop, which we are linking back to summarize the new features of Mountain Lion and reflect upon the changes previewed by Apple.

The basic theme of Mountain Lion is iOS-ification.

Apple took the best features of iOS, and in particular iOS 5, and brought them “back to the Mac”, giving them a desktop-class facelift to make applications and services suitable for the Mac environment. Mountain Lion will feature some familiar faces for iOS users: iChat has been renamed Messages and integrated with the iCloud/iMessage ecosystem from iOS; Notes and Reminders are now standalone apps; Notification Center, Game Center, AirPlay Mirroring, Share Sheets, and a new security system called GateKeeper are now part of OS X as well.

In this post we’ll provide a quick description of the new features, a Storify bundle that aggregates the most interesting links and tweets about Mountain Lion (which is available as developer beta today), and some thoughts on what Mountain Lion means for Apple and its users. Read more

Tweet Library 2.0 Review

The last time I wrote about Twitter clients, I noted how I’d rather settle with a single app for power users, and have other developers innovate on top of Twitter and the technologies offered by Apple to provide a unique take on the standard Twitter experience. Unfortunately, until today very few developers seem to have believed in the market potential for innovative Twitter clients that go beyond refreshing your timeline and catching DMs, with Riverfold Software’s Tweet Library being the best example of what’s possible to do by leveraging the Twitter API, focusing on another kind of experience.

I initially reviewed Tweet Library when it hit version 1.0 on iPad. I wrote:

Tweet Library is a searchable local archive of your Twitter activity, with promising online functionalities that show good room for improvement. At $9.99 in the App Store it might not be an app for everyone, but if Twitter curation is your thing, this is the best you can have on the iPad right now.

Released earlier today, Tweet Library 2.0 offers some fantastic improvements for those who began using the app on the iPad last year, adding a completely new iPhone interface as part of the free, universal update that will have Twitter curation nerds drooling in new functionalities. Read more

iCloud File Sharing

It is often said that Apple doesn’t offer a filesystem for iOS devices. Sure enough, it is indeed not possible to manage documents and folders on an iPhone or iPad as you can on OS X. Apple does, however, offer a very basic file management system that works with iOS apps, and you’ve haven’t probably used it too many times:

Introduced with iOS 3.2 and iTunes 9.1, iTunes File Sharing allows applications to import files copied from a Mac or PC using iTunes, and export to a computer. In iTunes, all you have to do is connect an iOS device, head over the Apps tab, and choose File Sharing below the Home screen app management interface. You can copy almost any kind of file into an app’s internal directory dedicated to file sharing, and several iOS apps use this method to import or backup files and documents such as bookmarks, videos, or spreadsheets. I’ve often used this feature to import .avi files to watch on my iPad.

iTunes File Sharing doesn’t seem to get the attention other iTunes functionalities do, and I believe there are a couple of reasons behind this. First off, it’s quite cumbersome: the interface for File Sharing is buried within an iOS device’s settings in iTunes, and there are no options to, say, automate the process of importing files or setting up favorite sources for documents. Second, iTunes File Sharing only solves a partial problem, in that the majority of iOS users don’t lament the lack of a proper Mac-to-iOS file management system as much as they’re asking for an iOS-to-iOS centralized file storage solution that would also happen to sync back to a Mac.

So, I had an idea. I think the same iTunes File Sharing feature would work a lot better as a dedicated, native iCloud app for iOS devices (and maybe the Mac too). After all, if Apple is providing an iTunes-based file management utility for Mac users, why couldn’t they build an app that enabled any third-party iOS app to save and import files from iCloud? This app would be built into the system and allow users to simply collect documents, like iTunes File Sharing. Developers could easily add options to their apps to import files from “iCloud File Sharing” and export files to it. Users would have the same feature set of the existing iTunes File Sharing, only with an interface they are already familiar with, because iCloud File Sharing would resemble the existing file management workflow of iWork for iOS or iCloud.com. The only difference is that it would be integrated on a system level, work with any iOS app, and basically be an extension of the “Open In” menu that already allows apps to communicate with each other through supported file types.

I wouldn’t call such an app “Dropbox from Apple”, as Dropbox is mainly developed as a solution to sync files between computers, running in the background all the time, whereas this would be more oriented towards giving apps a better file sharing system. In fact, I imagine Apple could go as far as indicating the apps that can receive an iCloud file as they currently do with iTunes File Sharing for better organization and to maintain the app-driven model. iCloud File Sharing would play well with this strategy, and it would offer a basic way for developers to integrate iCloud in their apps.

Apps like GoodReader have already implemented a similar system of iCloud-based file management, and some third-party developers are experimenting with providing standalone apps for file management purposes over iCloud. A default utility from Apple would have the obvious advantage of not requiring any additional download: it would be integrated as a system action in any app for iPhone, iPad (and even the Mac). Apps would still have their own iCloud libraries and synced data; the file sharing part would ditch iTunes and become iCloud-powered (iTunes File Sharing would be kept around as an option for transferring large files such as videos through USB).

You might argue that Apple is trying to eliminate the concept of the filesystem altogether by embracing the app model with data silos that are self-contained and user-friendly. As iTunes File Sharing seems to be suggest, though, I think that Apple knows the app model and iOS only solve so much when it comes to file management – Apple has to deal with the fact that many people still work with files and folders, export them, move them around, and manage them. I believe the real winning scenario for Apple would be to make the management process as lightweight and intuitive as simple by relying on iCloud. Thus, iCloud File Sharing would serve as a better solution than iTunes File Sharing, ans it would strengthen Apple’s offerings requiring no or little effort from developers, ultimately providing an accessible way to manage files atop of Apple’s existing free 5 GB of storage for every iCloud account.

Unfortunately, it doesn’t look like the upcoming iOS 5.1 will introduce such a feature, and I’m not holding my breath for a surprise announcement during the iPad 3 event. But for the next major version of iOS, if Apple doesn’t think a better way to let apps communicate with each other is needed, I believe an evolution of iTunes File Sharing towards iCloud would be a sweet stopgap solution in the PC-free era.

MacStories Reading List: February 5 - February 12

The past week has been an interesting one, for a couple of reasons. First, we’ve seen Kickstarter breaking records for its most funded campaign, a record that didn’t last long as a new game by Tim Schafer quickly pulled in $400,000 in 8 hours. Then Path, the cool kids’ alternative to the “evil” Facebook, found itself in the middle of a PR brouhaha as it was caught uploading a user’s Address Book email addresses to its servers. Ouch. Luckily, the company was smart enough to reverse its decision and issue an update in less than a day. There’s more: Apple has started warning developers against manipulating the App Store’s charts, and more people every week are considering using the iPad as their only work machine.

It’s this week’s Reading List, best served with a good cup of coffee. Enjoy. Read more

“Okay, I’ll Remind You”

A few minutes ago Apple uploaded two new iPhone 4S commercials on its website and official YouTube channel. The ads, as with previous iPhone 4S promotional videos, focus on Siri, and they might just be the best ones about the voice-based assistant yet.

The ads, called “Rock God” and “Road Trip”, share a common theme: people talking to their assistant using natural language and a friendly tone, not simply asking a piece of software to execute commands.

In Road Trip, a guy and his girlfriend are organizing a road trip to California. Look at the initial setting: it’s cold outside, they’re about the get in the car, and they want to get from the cold of East Coast in February to the sunny Santa Cruz in California. The guy asks Siri, and they’re on the road. Camera cuts to the guy’s face in the car. He’s looking for a barbecue in Kansas City. Camera cuts to girl’s face in the car. She’s looking for a rodeo. Camera changes again, this time the couple doesn’t know where they are, and the girl asks “Where are we?”, with the look of someone who knows Siri will have an answer. They’re in Santa Rosa. Change again. How big is the Grand Canyon? Sure enough, Siri can look that up on Wolfram Alpha or Wikipedia. But then the gas runs out: how about finding a station the guys can walk to? Finally, the ad reaches its climax when our two characters have seemingly reached their destination, or are fairly close, and are looking at the stars. She asks: “What does Orion look like?”. Siri displays sky data inline. The video closes with the opposite setting of how it began: sunny California, he’s wearing a t-shirt, looking at the horizon, and she’s telling Siri like you would do with an old friend – Remind me to do this again. Siri, with its human-like voice, replies: Okay, I’ll remind you.

The second commercial, Rock God, has a more “fun” approach. There’s this kid that “has to get a guitar”, and he’s so excited about it he needs to ask Siri now. Why is he so excited about getting a guitar? What’s the story here? Perhaps, I imagine, he has just decided with his friends that it’s time to put a band together and start playing. So, Siri gives him location info about stores selling musical instruments, and in the next scene our kid is learning how to play. How do I play London Calling? Whole Lotta Love? How about that chord? Siri displays information on screen. Fairly regular stuff for now. Then the ad changes – our character is sending a message to Julie and Kate about playing at the garage tonight. Apple’s music stops. The kids are playing – they’re doing rock ‘n’ roll! – and finish their song. “Call me Rock God”, the kid tells Siri, softly.

You see, these aren’t just ads. In 30 seconds, we’re told stories. In 30 seconds, we are not shown technical features and RAM specifications, we’re given real examples of real people we can relate to. We’re shown two young people in love with each other that just want to get to California and see the sunset together. We’re shown a young boy with a simple dream, playing guitar, yet a dream that’s important to him – something that makes his life worth living and enjoying even for those 30 minutes when he gets his band mates together and nothing else matters. Just music. Call me Rock God.

In 30 seconds, we’re shown how technology can make people’s lives better. We’re reminded, once again, that this industry, this love for the latest gadget, doesn’t necessarily have to be about tech specs – it’s the technology married with the liberal arts. It’s about playing London Calling with your friends. It’s about driving to California with the woman you love and watch the stars just for one night.

He would be proud.

Read more

Greed and Entitlements

Nate Boateng has published a very good explanation of why App Store users aren’t entitled to free, universal upgrades of iOS apps:

The thought that a small development team is expected to do months work for free is insane to me. Yes, there are tons of successful apps that are universal (see Instapaper, Due, and Twitteriffic), but the perception that we are entitled to that is not only selfish, it’s just plain wrong. Universal app updates that come for free should be considered a bonus, not a right. A while back Iconfactory developer Craig Hockenberry gave a ballpark on Twitteriffic’s development. He estimated that it cost around $250,000 to develop Twitterrific. Think about that for a second. Still think you’re entitled to free universal updates for the lifetime of an app? I sure don’t.

Today’s Tweetbot releases are just another example of a subset of users that think developers should keep on updating their apps, even adding completely new iPad versions, for free, forever. This kind of controversy seems to take place every time a major iPhone app is released as standalone on the iPad, or vice versa. So I’d like to formulate a quick thought on the subject.

I understand those who say “I would have preferred it to be universal”. Sure, sounds reasonable. I would have preferred my iPhone 4S to come for free in the mail, too, but it didn’t. Stuff isn’t free in this world (even when they give you the illusion of free, you’re the one being sold). What I can’t accept is people getting angry and offensive at third-party developers that decide, you know, to make people pay three bucks for an app that’s been in the works for months. Unfortunately, the App Store doesn’t allow for paid upgrades, so if these people’s rhetoric is that it’s not about the price, it’s about the convenience of a universal binary, well, there isn’t much developers can do about it. Ask Apple.

More importantly, I’m baffled when I see people really getting angry because of a standalone app that was always meant to be that way. So here’s a tip for these people: next time you’re about to send a tweet to a developer, claiming that he promised a free and universal update and he’s now “stealing your money”, do your homework. Because if I can’t argue on economics, I sure think I’m pretty good at Google Search, which brought me to this page (screenshot). From the old Tweetbot FAQ, when the iPhone app was first released in 2011:

Will there be an iPad/Mac version?

It’s a possibility, but we have no plans for it at this time. We are focusing on the iPhone version for now. If we do an iPad version, it will not be universal.

Don’t be greedy. Support indie developers and great software.

Path: Doing the Right Thing

Yesterday, personal social network/smart journal Path was hit by a wave of controversy as a user found out the iPhone app uploaded a device’s entire Address Book (your contacts’ names, emails, phone numbers, and addresses) to the company’s servers without any kind of user consent or notice. Whilst some people claimed this is actually common practice for several iOS apps as Apple doesn’t provide native Address Book access dialogs as they do for location, the fact that Path did it was unequivocally wrong, and in spite of the Path’s CEO quickly responding to comments, the company was still called out to make the right thing, apologize, and remove all user data.

And unlike many web companies nowadays, that’s exactly what Path did. With a blog post published earlier today, Path explains that what they did was simply functional to the service’s contact matching feature, but wrong nonetheless. Path is apologizing for the mistake, and has released a new version of the app that makes the functionality opt-in for all users; they have also removed all data from their servers as many asked today.

We believe you should have control when it comes to sharing your personal information. We also believe that actions speak louder than words. So, as a clear signal of our commitment to your privacy, we’ve deleted the entire collection of user uploaded contact information from our servers. Your trust matters to us and we want you to feel completely in control of your information on Path.

You may like Path or think it’s useless (I, for one, use it and enjoy it quite a bit), but you have to admit we don’t see companies be that honest and transparent to their users that often. In a world where we’re used to see companies hiding particular aspects of their services to their users (sometimes even paying users), it’s refreshing to see Path be an example of clarity and simplicity in communication.

What Path did was wrong, and they have paid (and will continue paying) the consequences for their mistake in bad PR. On the other hand though, Path has shown that there’s nothing wrong about admitting your errors, saying you’re sorry, and trying to turn a bad decision into a precious lesson for future endeavors.

Bravo, Path.

iOS Monitors (And Cursors)

Gabe Weatherhead has an interesting take on my iOS-ification of Apple’s Ecosystem piece:

But there is one feature missing from iOS that will prevent it from ever being effective with an external display: a cursor. I know this seems blasphemous but if you have ever tried to us an iPad with mirroring, you know that you must still look at the iPad to get anything done.

To use the iPad as a desktop replacement, mirroring is not enough. I need a cursor displayed where my finger touches the iPad (or iPhone) so that I have context on the external display. Every time I see iOS app demo videos they are accompanied by cursor representations for the touch interactions, and I think “that would be a great feature on the AppleTV.

I have used AirPlay Mirroring with my iPad 2, and I agree that it’s weird to be forced to look down at your iPad’s display if you want to get anything done that’s not sliding presentations and photos. Even games, in spite of their less complex on-screen controls and interfaces than, say, an app like OmniFocus, can be hard to be played without looking down sometimes.

What I’d like to see – and something that likely won’t happen anytime soon – is a series of “desktop accessories” to better take advantage of the iPad when mirrored or connected to an external display. For instance, imagine some sort of Magic Trackpad for iOS that would allow you to retain gestures and multitouch, but have a cursor when the iPad is mirrored to an Apple TV. Something I often hear (and find myself into as well) is that some apps are just better with a cursor in the current state of software offerings – for example, image editing and highlighting text. Imagine if Apple built an official accessory that, through APIs (much like iCade does), allowed developers to enhance their apps with direct support for “cursor mode” when the iPad’s screen is mirrored or even when the device is held by a stand (magnetic latches could inform the system of the current orientation of the device). If I had to put my two cents in it, I’d say this could be a way to market the iPad as a device capable of switching to a more precision control-oriented environment if needed. Video professionals woud sure welcome such a move.

I’m not saying Apple should produce a convertible tablet that switches between iOS and OS X (albeit Apple’s direction seems to be making switching between the two a seamless experience) – I’m arguing that some specific software and functions are better with a cursor in the current state of things. So unless we’ll see revolutionary new touch controls that will obviate the need for such idea, I think cursor controls on an app-by-app basis is something worth considering for the future of iOS’ mirroring and external display connections.

Perhaps Apple is fully committed to multi-touch and we’ll never see new cursor-based interfaces/hardware coming out of Cupertino again. But I think cursor-based controls are still superior for some kind of apps, especially for professional software such as video and image editing.