Posts tagged with "iOS"

“Universal Save” for iOS Apps

Ted Landau at The Mac Observer covers an issue I’ve mentioned several times in the past, which Apple has partially fixed with the last releases of iOS: saving documents and moving them across apps. Specifically, Landau notes that the lack of a “universal save” option for documents that can be read by third-party apps (PDFs, text files, images) leads to an annoying and pretty much useless duplication of content. Apple has implemented an “Open In…” menu to send files to other apps, but the file that’s being sent is a copy. iOS apps can’t read and modify a source file from a single location.

Currently, iOS does not come close to matching the advantages of Mac OS X here. There is no way to have a unifying folder in iOS that contains related documents from different apps. There is no way to have a document easily opened in different apps, where any changes you make in one app are instantly accessible by all the compatible apps. You can come closer with Dropbox, but closer is not good enough here.

That’s annoying for me, too, as I constantly switch between apps to get my work done, and it’s not like I don’t enjoy trying new ones. This typically leads to some sort of geek frustration – why can’t Apple build an invisible layer that lets Elements edit a text document from Evernote and Pages access the same file?

For Ted and me, yes, being able to avoid file duplication and tedious exporting processes would be nice. But I do wonder how much does Apple care about such functionalities considering the underlying paradigms of iOS and the upcoming iCloud functionalities of iOS 5. For one, Apple really cares about application sandboxing: each app has its own controlled data environment and only a few items can be shared between multiple apps. Apple cares about sandboxing so much that they’re bringing it to the Mac App Store. Would iOS sandboxing allow for a source file to be edited and “saved” by multiple apps? Where does that file belong to, technically? Would iOS apps be able to write specific metadata to it? And what happens if, hypothetically, this “shared” file needs to be pushed back and forth with iCloud?

I’m no iOS developer, but I can see this proposed “universal save” model becoming an issue when on iOS, unlike the Mac, there’s no visible, centralized Finder location to write and read files from. In fact, Ted is right when he says that the convenience of a Mac is being able to create “a folder that will contain all the assorted files needed to put his column together”. That’s made easy by the Finder – but on iOS? Apple allows third-party developers to plug into the Music library or Camera Roll, yet there’s no Apple app to “create text file here” or “save webpage from Safari here”. Again, the lack of an iOS Finder would require “universal save” to work inside any app. iDisk could have been a centralized location for files – it could have even been Apple’s “answer to Dropbox” – but it’s not going to be supported by iCloud.

And then there’s the conceptual issue of an iOS device being the app that you’re using. When you use Pages on an iPad, the iPad is a word processor. When you browse the web with Safari, you’re holding the web in your hands. On a technical level, this app console model is represented by sandboxing and one-way “Open In” menus, and soon iCloud-based documents that allow multiple versions of the same app to access files. Would a “universal save” option somehow break the illusion that you’re holding an app, reminding us that we’re using a device with multiple layers of abstractions including a filesystem?

I don’t know. I believe I’d like this feature in theory, but I wonder if there would also be a considerable trade-off to accept.

Labeling iOS’ Back Button→

Labeling iOS’ Back Button

Neven Mrgan shares a solid piece of advice for iOS app designers and developers: A Back button labeled “Back” is never a good option.

As he notes, Apple never labels the “Back” button – the left-pointing arrow at the top of most iOS apps – “Back”. They provide context as to how a parent view (the previous screen) should be shown in the button’s label.

This is a widespread issue, present in many extremely popular apps.

This is redundant and it provides no context. Note that Apple never does this, not in any app. Instead, they provide either the full title of the previous view, or an abbreviated/truncated version of it.

He offers some do/don’t examples in his blog post. Here’s a series of screenshots from my iPhone, showing apps that correctly use the “Back” button:

One of my favorite examples, the Rdio app for iPhone:

And here’s Apple in the Apple Store app:

The button itself means “back”, so the additional “Back” label is not an option. These are the minor details that make great apps, well, great.

Permalink

In-App Purchase Revenue Growing as Developers Adopt “Freemium” Model

Many developers build iOS software hoping that their app will be the next Angry Birds, but they struggle at what price to sell it. A free app can bring downloads but your pockets are still empty. Maybe you should consider adding in-app purchases to your app, no matter the base price. Distimo has released a new report that suggests that in-app purchases are the way to go if you want to make money in the App Store. In-app purchases account for 72% of revenue, improving from 28% at this time last year. Here’s another stunning number, only 4% of apps in the App Store even offer in-app purchases.

Freemium apps (free to download, but require an in-app purchase to expand the app) are growing particularly faster in the in-app purchasing paradise. Free app downloads have increased by 34% since 2010 while paid downloads only grew 7% in the same time frame. Distimo’s research only covered the Top 200 in each category, but that’s a strong selection of the App Store’s money makers.

Freemium apps made up 48% of total App Store revenue while paid apps with in-app purchases accounted for 24%; the remaining 28% came from paid apps. If you look at the top grossing apps for the iPhone (iPod Touch) and iPad App Stores, freemium games take up several spots. Freemium apps also account for 65% of the Top 100 grossing games in the US App Store.

Besides games offering in-app purchases, comic apps are also making waves, especially in the iPad App Store. Magazines are one more category that is taking advantage of the freemium pricing model.

GigaOM didn’t envision this exactly back in February when Apple let in-app subscriptions into the stores. “Essentially, it looks like more and more developers are embracing the idea that making recurring payments an attractive option for App Store shoppers is the key to coming up with a sustainable business model. Apple’s isn’t the only store where developers are figuring that out, either. In-app purchases are already in use by 68 percent of the 25 top grossing Android apps, despite only being introduced in March of this year.”

Could we possibly see the day when there aren’t “regular” paid apps in the Top 300 grossing list? What do you prefer as a user – a one-time fee to buy the entire app, or having to keep putting quarters into your Apple arcade machine? [via GigaOM]