Rss

Archives for : appstore

One More Thing on App Store Sustainability

I had another thought about App Store sustainability this morning that I banged out as a pair of tweets, but that I wanted to post a little more prominently:

A thought: what good would upgrade pricing do on the iOS App Store, where the de facto maximum full price is $4.99?

Is anyone really going to be able to build a sustainable business off 99c annual upgrades?

My Unsustainable Productivity post despaired pretty badly for the future of one-time purchases in the iOS App Store, and I’ve only gotten more pessimistic in light of the evidence that Apple may release iWork for iOS for free with iOS 7. The polish and functionality of the iWork apps means they likely cost Apple several million dollars to develop… if they’re to be given away free, what does that do to user expectations? Basically it tells users they should expect to pay nothing for best-of-breed productivity apps.

I thought $10 each was too low for the iLife apps when they debuted, that it set a price ceiling that would make life difficult for other app makers. If Apple actually makes them free then — mark my words — it will mean the end of third-party productivity apps of any significance on iOS.

Set against this, what do we make of Apple’s release of Logic Pro X for the Mac, at $199? For starters, there’s the much-made point that they clearly don’t intend to offer an upgrade pricing system, when they’re demanding full price for the app on Mac, from new and current users alike.

But look at the contrast with the above, where iLife goes from cheap to (possibly) free on iOS, while Apple still thinks Mac software can demand a price in the hundreds of dollars. They’ve egged on and contributed to the Race To The Bottom on iOS, but not on the Mac. And that just means we’ll all need our “trucks” longer than we would otherwise, because the productivity apps we’d need to go iPad-only will never be written for iOS (or even ported), because it’s not viable for any third-party developer to do so, whereas Mac development remains as viable as it ever was.

Unsustainable productivity

Ben Thompson’s Stratechery blog had a recent series of posts on sustainability in App Store development, and the third part of the series focused particularly on productivity apps and how the nature of the App Store ecosystem has caused that category to implode.

I wrote a really long reply to him with some of my thoughts on the matter, something I’ve tweeted and blogged about before — and about part-way through the e-mail I realized it would be a pretty good blog on its own.

So I’m pasting it below in its e-mail form, with a few links and formatting added here and there.


Continue Reading >>

Can’t Buy a Thrill

MacWorld ran a story last week to remind readers that A $5 App Isn’t Expensive, and imploring readers to stop being such cheapskates for the sake of the App Store economy.

Earth to MacWorld: It’s already too late. The market has spoken, and it refuses to pay for apps, even when the toxic side-effects of that are manifest.

MacWorld’s piece comes in part as a response to Michael Jurewitz’s five-part series on app pricing, posted on the eve of his return to Apple (and, presumably, a lot more circumspection about his future blogging). Jury sees the app pricing race to the bottom as a self-inflicted wound and urges developers to charge what their apps are worth.

Great advice… for anyone still around to take it.

Continue Reading >>

Apple Should Get Out of the Manga Piracy Business

Sorry for another anime/manga-related post, but a thread on Twitter reminded me of some Apple misdeeds that need rectifying. It started with a pair of tweets, first from Zac Bertschy of Anime News Network:

I’m sure this has been asked a million times, but why are there so many goddamn bootleg manga apps on the iOS store?

And then a follow-up from social-media expert and publisher Erica Friedman of Yuricon:

@ANNZac I’ve tried to write Apple/Google about the links to bootleg sites. Neither has a reasonable way for reasonable people to complain

So let me back up a second… what we’re talking about are dedicated apps that read “scanlations”, which are comics (usually Japanese manga) that have been scanned, translated by fans into English, and posted for free to various websites or made available through channels like BitTorrent.

Zac righly calls this “bootlegging” because there is no question that copyright violation is involved. Entire works are being digitally redistributed with zero compensation to the original authors or publishers. What can make this a gray area is a question of whether or not any actual harm is done: if the work is unavailable in English, nor likely to ever be, then how can a scanlation eliminate a sale that could never be made? This is a fairly bogus defense because (as we’ll see), the untranslated works are just a minor part of the story. Moreover, we could apply the established tests of “Fair Use” under US copyright law, such as:

  • Is the new work “transformative”? In other words, are we using the original to create a fundamentally different thing?
  • How much of the original is being used?
  • Does the copying impede future sale of the original work? Does it harm the creator?
  • etc.

Guidelines like this permit use like, say, presenting few pages of a comic in the context of a critical review or an academic paper: fundamentally new work, small amount of copying, doesn’t replace the original (and might actually drive new interest and sales). And obviously, a scanlation fails every one of these tests: it’s a full-on copy that changes only the language, and fully replaces a translation the original publisher might provide. It’s also been pointed out that scanlations are harming the development of a legal digital manga industry in the US. Scanlations would have zero chance of surviving a legal challenge.

So why the hell is Apple in the business of distributing them on iOS?

Search for manga on the App Store and you’ll get dozens of hits. Most of them are apps for downloading and reading scanlations on your iPad or iPhone. For the purpose of this blog, I tried the free versions of:

Note: these are not affiliate links. I wouldn’t want a cut of their sales, since I consider them illegal and illicit.

Most of these apps get their contents from three scanlation websites: MangaFox, Mangareader.net, and MangaEden. Some of these sites play at supporting the source of their titles by slapping in pseudo-legal disclaimers and vague admonishments to somehow support artists as seen on this page of The Rose of Versailles:

Manga Storm page from Rose of Versailles, with disclaimer caption

This image is hosted at mangafox.com. We take no credit for the creation or editing of this image. All rights belong tot he original publisher and mangaka. While we hosted this for free at mangafox.com, please don’t forget to support the mangaka in any way that you can once his/her work becomes available for retail sale in your region!

Some of these sites also adhere to an ethic that they don’t host scanlations of titles that have been licensed in the US. In this screenshot, Manga BDR (which awkwardly makes you browse MangaFox rather than scraping its index) shows an notice that Fullmetal Alchemist is unavailable from MangaFox because it has been licensed in the US:

Manga BDR showing MangaFox notice that Fullmetal Alchemist is unavailable

Does this mean there’s honor among thieves? Hardly. The sites are still violating the original Japanese copyright of the titles they do offer. And they’re not living up to the implicit promise to make obscure titles available to a wider audience — the Rose of Versailles manga cited above has not been completely translated, despite being more than 30 years old. And wherever Manga Rock gets its data from, it has no compunction about offering up titles that have US publishers. Here’s Manga Rock 2 offering Fullmetal Alchemist in its entirety:

Fullmetal Alchemist manga on Manga Rock 2

Not only is this stuff illicit bootlegs, these apps are popular because they allow access to pirated manga. Every single one of these apps advertises itself on the App Store with screenshots of browsing popular titles that have US publishers: Manga Storm shows Fairy Tail, Manga Rock shows Fairy Tail, Air Gear, and Negima!, and Komik Connect shows Bleach and Naruto. And the users use these apps precisely because of their illegal nature: the one-star reviews on Manga Storm don’t complain about it ripping off artists, but because it lacks US-licensed titles (due to its dependence on MangaFox and friends), and because it’s a paid app.

And speaking of the paid versions…

Apple gets a 30% cut of every sale of the full versions of these apps. That makes Apple a direct beneficiary of copyright piracy.

Everyone who stood up to say Apple does more to support creators than Google and its cavalier attitude towards IP rights, you can sit down now. So long as these apps are available on the App Store, Apple is complicit in piracy.

It’s fair game to criticize Apple for these, when the company has such a stringent review process. When it’s so careful to consider what it will and won’t sell, approval of an app has to be considered an explicit endorsement, particularly considering Apple gets a cut of the sales.

And that’s what makes it all the more galling:

The last of these may be the most galling. Erica Friedman again:

I went on a rant about why is it okay with the those of you who like shiny things that Apple just told DMP to take their BL off the iPad app? WHY?!? If the TV hardware manufacturers told you what TV stations you could receive, you’d be enraged. When your work blocks sites, you find ways around it. So why the hell is it okay will all you Apple fans that Apple censors content? I cannot understand why you are not screaming at all, much less loudly? APPLE CENSORS CONTENT. Especially LGBTQ content. Why are you still giving money to a company like that? People boycott BP and Chik-Fil-A and Target…but are absolute sheep about Apple’s censorship of content. ARGGGGGHHHH.

It’s as if Apple is saying “we won’t let anyone sell you gay manga for your iPad, but we will sell you tools to help you steal the stuff.”

This has to stop.

If nothing else, these apps are in obvious violation of section 22.4 of the iOS App Store Review Guidelines:

22.4 Apps that enable illegal file sharing will be rejected

Apple apparently won’t listen to third-party criticism (people have been calling attention to these bootlegging apps since at least 2010: 1, 2, 3), but there are channels that aggrieved parties can use. Viz and Yen Press have legitimate iOS apps for their manga titles. Since Manga Rock 2 makes bootlegs of those titles available (I saw Viz’s Fullmetal Alchemist and Yen’s High School of the Dead), these companies could use Apple’s dispute policies to at least have Manga Rock 2 taken down.

Beyond this, it’s hard to see what will work. Via Twitter, Erica noted yesterday that most US manga publishers are too small and operating on margins too thin to follow up with DMCA takedowns, and Apple may be technically in the clear on DMCA because they’re not themselves hosting the offending content.

However, since Apple’s making money off the sale of the apps used to pirate this content — in clear and obvious violation of their own policy — another option is that the Japanese publishers might want to sue Apple directly. They would presumably have more legal resources to stick with a lawsuit, and with Apple deaf to criticism, maybe it would take a few subpoenas to call their attention to the fact that making money off piracy is an awfully dirty business for one of the world’s largest and most prestigious companies to be involved in.

For the sake of Apple and the creative community, these apps need to disappear forever.

Times Change, People Change, Hairstyles Change… Security Changes

I’m getting a lot of hits on Sunday’s App Rejections Are A Lousy Way to Communicate Policy Changes, courtesy of a link from Daring Fireball, which is pretty magnanimous considering I kind of slam Gruber halfway through. That blog argued that suddenly rejecting apps for accessing the UDID is a terrible way to handle a policy change, that Apple’s usually far better about controlling the message, and that developers shouldn’t hear about this stuff from Twitter and TechCrunch.

Unfortunately, a lot of the conversation here and elsewhere has been hijacked by a focus on the UDID specifically and privacy issues in general, largely by uninformed readers who are quick to blame everyone who didn’t see this coming.

I’m going to use this blog to explain what the UDID is and the problems around it, from the POV of a developer who’s both chosen to use it and inherited code that uses it.

Take this with the grain of salt that I Am Not A Security Expert (IANASE), or perhaps I Am Not Graham Lee (IANGL).

What Is the UDID?

The Unique Device Identifier is exactly what it says on the tin: a long string of characters that uniquely identifies one iOS device. It only identifies the device, not the person using it (I believe it stays the same after a device wipe, but I don’t feel like wiping my iPad to test that). Any user can find his or her UDID by connecting their device to iTunes and option-clicking the Serial Number.

Since the first public SDK in iPhone OS 2.0, the UDID has been available to developers by calling -[UIDevice uniqueIdentifier]. The reason you would want to do so is typically to identify one instance of your app running in the wild, or perhaps as a stub to create other unique IDs (for example, a document-creating app that IDs each document as UDID plus the time it was created).

Imagine you want to know how often your users use your app. You could set up a URL to log startups, and then hit it from your app. But if you got 30 hits, you wouldn’t know if that was 30 devices running your app once, or one device running it 30 times. If each call sends the UDID, then you’d be able to tell.

So What’s The Problem

Most of us would agree that this scenario is pretty benign. And in fact, many apps gather a lot more metrics than this — what features are used most, which ones are used together, etc.

Let’s set aside for the moment of whether gathering usage metrics is OK (with or without the user’s permission). So far, this doesn’t seem bad. In fact, we still don’t know who’s running the app — no matter how much information we collect on a given UDID, all we know is that one device exists that is being used in that way.

Let’s say we have 9 apps that collect metrics like this, each phoning home metrics to the developer or some third-party’s server. Now what if a 10th app does the same thing, but it for some reason is able to collect personal information (maybe it’s subscription based, maybe it uses a Facebook login, whatever). That app is clearly able to correlate metrics to a given user. But since it shares the same UDID with the other 9 apps, we can now associate the activities in those apps with a specific individual.

Can you say “unintended consequences”? This is, as I understand it, the problem with the UDID, and why Apple has deprecated its use.

They Should Have Known!

No, the issue is that no one should have thought it was ok to use information that could identify or otherwise compromise another person’s privacy. It should have been obvious that once this got out Apple would need to do something about it. It should have been obvious that you should not have been doing it at all.

Icouldseeitcoming, commenting on App Rejections Are A Lousy Way To Communicate Policy Changes

My point in the above story is that the potential for misuse of the UDID does not come from the string itself. Remember, it conveys no personally identifying information. The problem has arisen over time, in an unexpected way, based on many apps working together (not necessarily with their explicit intent or permission).

Was Apple negligent in offering access to the string in the first place? All indications are that they actually gave privacy some serious thought as they developed the iPhone SDK. Consider the Address Book. No, not the Path debacle (we’ll get to that). Over on Mac OS X, there is a method called -[ABAddressBook me] (also the C function ABGetMe()) that returns the user’s address book card. In the C-based iPhone Address Book API, there is no equivalent call to get the user’s record. Clearly, Apple did put some thought into what third-party developers should and shouldn’t have access to, and decided that being able to personally identify the user of the phone was a bad idea. Despite benign uses this prevents, many of us would consider this a good decision.

So given that, let’s consider this absolutist position that “no one” should have thought it OK to use the UDID. Let’s just use Occam’s Razor: do we really believe that Apple, all the ad networks and analytics companies, and the majority of iOS developers are just stupid and negligent? That’s a huge pill to swallow. The alternative hypothesis — that the sense of what is and isn’t acceptable privacy policy has changed over the last four years, particularly in light of how things have actually played out among 700,000 apps — is far more plausible.

To that end, let me tell you another story…

UUIDs

Apple’s guidance in the iOS 5 deprecation statement for the -[UIDevice uniqueIdentifier] call is to generate a CFUUID and persist that in the NSUserDefaults. I’d be inclined to use the Keychain so it survives app deletion and reinstalls, but same difference. The upshot is, the one app that just needs to log app launches still has what it needs: a unique identifier of one instance of the app. When each app creates its own CFUUID, the 10 apps in our above example phone home with 10 different unique identifiers, so one can’t be used to compromise the identity of another. So far, so good.

So what is a CFUUID? It’s Apple’s C API for working with Universally Unique Identifiers (UUIDs). From Apple’s docs:

UUIDs (Universally Unique Identifiers), also known as GUIDs (Globally Unique Identifiers) or IIDs (Interface Identifiers), are 128-bit values guaranteed to be unique. A UUID is made unique over both space and time by combining a value unique to the computer on which it was generated—usually the Ethernet hardware address—and a value representing the number of 100-nanosecond intervals since October 15, 1582 at 00:00:00.

So that’s good, we can’t trace the IDs back to the… hey, wait a minute, what was that? Combining the network hardware address (aka, the MAC address) with the time the UUID was created? Doesn’t that mean that a group of UUIDs created on the same device would all have the same MAC address? So if you can get that MAC address out of the UUID, then even though the 10 apps that phone home 10 different UUIDs, we could get the MAC address that’s common to all of them, identify the user and we’re right back where we started! What the hell? Rabble! Rabble!

Well, as it turns out, Apple’s documentation is wrong. Look back at the Wikipedia entry again and notice that UUIDs have versions. The description above is for version 1, which was abandoned for exactly this reason:

This scheme has been criticized in that it is not sufficiently “opaque”; it reveals both the identity of the computer that generated the UUID and the time at which it did so.

Read in and we find that there is a version digit in the UUID, the character after the second hyphen. Now click to enlarge the screenshot below, from a sample app I showed at CocoaConf Chicago, and which generates hundreds or thousands of UUIDs a second in a (futile) search for duplicates:

UUID Starfield app - shows that iOS/OSX UUIDs are all version 4 and never duplicate

Notice that the digit after the hyphen is always a 4, meaning these are version 4 UUIDs, which are just really huge pseudo-random numbers, and therefore don’t reveal anything about who or what created them. Problem solved.

The reason I bring this up is that it was not at all “obvious” that putting the MAC address in the UUID was a bad idea, at least not so bad that it held up ratification of the standard (or, alternately, it wasn’t a problem until UUIDs started being used for purposes where revealing the creator’s identity was an issue). Lots of smart people worked on this stuff; it wasn’t thought to be a problem until later.

Like bugs, security problems are not things people create on purpose, and it’s insulting to insinuate that. They show up later, after reconsideration, after systems evolve, after third-party attacks.

You Want Evil? I’ll Show You Evil!

Yeah, you guys are right. How could anyone have expected that something called a “unique device identifier” might be used to track people.

Icouldseeitcoming, commenting on App Rejections Are A Lousy Way To Communicate Policy Changes

The UDID is neither necessary nor sufficient to track users. An app could use a hand-rolled UUID to track a device, as is Apple’s recommendation, and is in a position to log every tap and keystroke and phone it home to the analytics server. Heck, I had an AV Foundation demo a few years ago that encoded screen-grabs to a QuickTime movie — it wouldn’t take much more to provide a live video stream of a user’s interaction with my app back to an IP address of my choice, all without the user’s knowledge or assent.

That’s assuming I’m being evil on purpose of course. What removing the UDID hopes to improve is cases where apps inadvertently provide a way to correlate activity in different apps, which in turn could be linked to a real person if any of the apps capture personally-identifying information. Even now, there are other ways this could be done: apps could share hand-rolled UUIDs via URLs, document exchange, or the Keychain (if the apps were all signed with the same credentials and share a bundle id stub), though this requires a far greater degree of deliberate cooperation than the inadvertent UDID case.

There are other APIs with privacy implications too, such as free access to the Address Book (as epitomized by the Path case a few weeks back, and Facebook years earlier). An app that incorporates a UIWebView could also be vulnerable to any known Safari or JavaScript attack vectors. And whole apps are based around using Core Location to rat out your current location.

So to make a big deal out of the UDID as this obvious privacy problem seems badly ignorant. Its problematic aspects come from unintended consequences, not the nature of what it is.

And since any app can itself collect any information on your interactions with it, UDID or not, and phone it home with a network connection, the only perfect way to avoid being tracked at all is to go to the Settings application, turn on Airplane Mode, and never turn it off.

App Rejections Are a Lousy Way to Communicate Policy Changes

Following Twitter reports from earlier in the week, MacRumors and TechCrunch now report that Apple is rejecting apps that use the unique device identifier (UDID), by means of the -[UIDevice uniqueIdentifier] call.

This in itself is not surprising: iOS 5 deprecates the method, adding “Special Considerations” that advise developers to create a one-off CFUUID to identify a single install of the app on a single device.

So far, so good. I even had a section of my talk at last week’s CocoaConf Chicago that talked about CFUUIDs and the need to migrate any UDID dependencies to them now.

The problem is the timing. Apple’s established pattern has been to deprecate a function or method in one major version and, at the speediest, remove the call in the next major version. Many developers, myself included, expected that we had until iOS 6 to get off of the UDID.

But instead, without warning, the app review process is being used as an immediate death-penalty for the uniqueIdentifier call.

This is a problem because we’ve all had about six months to get off of UDID, and while that’s surely enough to get a simple app migrated — indeed, I have cases where switching it out is a 5-line fix — it is not necessarily the case that everyone can be expected to have already done this.

The real problem isn’t with developers; it’s with whom we develop apps for. Our clients don’t know or care what a UDID is, nor are they aware of a single line in Apple’s documentation saying “stop using this”. Sure, it’s our job to be on top of it. But let’s imagine apps with long development cycles — big apps, or academic apps that rev for the new school year in the Fall and are largely dormant the rest of the year. It’s entirely plausible and reasonable that developers of these apps have “get off UDID” as a high-priority item in their bug trackers, but are waiting for budget and approval to start working. And what if it’s not a simple process? What if an app has some deep dependency on access to the UDID, both in the app and on a server somewhere, meaning that two different teams are going to need to deal with losing access to uniqueIdentifier, and will need to come up with a plan to migrate user records over to a new id scheme?

Well, they just lost their chance.

Captain Hindsight is in full effect in the MacRumors forums, loudly asserting that developers should have known this was coming, have had plenty of time, etc. I get that it’s the natural defensiveness about Apple, but it gets worse… because this isn’t the only case of Apple using app rejections to carry out policy changes.

Thanks perhaps to my many posts about in-app purchase, I recently heard from a group of developers who’d gotten a galling rejection. They have an app with a subscription model, and used the new “auto-renewing subscription” product. This product is far superior to the original subscriptions that I have repeatedly described as broken, as they cannot restore between a user’s devices, and do not carry state to indicate what was subscribed to and when. Auto-renewing subscriptions fix these problems, and the In-App Purchase and iTunes Connect guides had (seemingly until a couple weeks ago), clearly disparaged use of the old subscriptions in favor of the new auto-renewing subscriptions.

So imagine the surprise of my colleagues when their app was rejected for using auto-renewing subscriptions. The reason given was that they were using it for a different business plan like a data-plan model, and auto-renewing subscriptions are, according to the reviewer, reserved only for content subscriptions like Newsstand magazines. I have never seen anything to this effect in any Apple I-AP documentation. Nevertheless, the developers had to switch to the shitty, broken, old subscriptions.

In both of these cases, we see Apple breaking with their own documentation or with long-established practice with no warning, and instead using app rejections as a tool to communicate and carry out new policies. This is wretched for developers, who get caught scrambling to fix problems they didn’t know they had (or didn’t expect just yet).

It’s also terrible for Apple, because the aggrieved developers initially control the message as they flock to blogs and Twitter, leaving it to loyalist commenters and bloggers like Gruber and the Macalope to mount a rear-guard gainsaying defense. To see Apple — of all companies! — not controlling the message is astounding.

All it takes is clarity. If they’re going to make such a major change, they’ve already got our attention via e-mails, the developer portal, and many other channels. They could and should clearly state the what, why, when, and how of policy changes. “We’re getting rid of UDIDs, because they constitute a privacy risk. We’ll reject any app that calls -[UIDevice uniqueIdentifier] as of March 23, 2012.” Not that hard. They’ve done it before: a few years back, Apple required streaming media apps to use HTTP Live Streaming if they streamed more than 10MB of data — this was communicated via announcements on the developer portal a month or so before its implementation, and nobody got caught by surprise, nobody complained.

Apple has developed a reputation for capriciousness in its app review process, and a cavalier attitude towards its developer partners. It’s not undeserved. As Erica Sadun once cleverly put it, “Apple is our abusive boyfriend.”

Facebook for iOS Pigs Out

Last night, I was thwarted from adding a show to my iPad because I was nearly out of space:

iTunes usage: iPad nearly full

I started deleting large, rarely-used apps (goodbye for now, GarageBand!), and ultimately trimmed the playlist of songs that syncs with the iPad. But as I looked through my per-app usage, this caught my eye:

iOS Facebook using 421 MB

That’s right: Facebook, a network-based application (one that is typically accessed as a web page) is using nearly half a gigabyte for documents.

No. No you don’t. I deleted Facebook and reinstalled from the App Store to reclaim the space. But then I thought, what the hell is it doing with all that space?

Fortunately, I still had Facebook on my iPhone, where it’s only burning a little over 100 MB. I took a look with iExplorer, and dumped Facebook to my Mac:

Contents of Facebook for iOS app, including 100 MB of cache

So look at that: 12 MB for the app, over 100 MB of Caches, nearly all of it in FBURLCache. Bad enough that it burns a seemingly unlimited amount of space, but let’s flip back to iExplorer and look at the file dates:

FBURLCache file dates

Yep, the oldest files in this cache are three months old. What are the odds that I’m going to want any of those files, and even if I do, that I’m going to get any benefit from caching them locally?

It gets better. After poking around the 1.5 MB cacheinfo.plist index file and its 6,000 entries, I dug into one of the cache files with HexEdit, which immediately revealed it as a simple .plist. Off to the Property List Editor we go!

Facebook cache file property list

So, great… for a “Recommend” button on some web page I accessed back in January, Facebook has cached the entire NSHTTPURLResponse. 1,700 bytes of cache for a 339-byte GIF. And apparently it’s done this for every element of every web page I’ve viewed with the Facebook app.

Unbelievable. I rarely view a web page more than once through the FB app, and it’s highly doubtful anyone is getting more benefit from caching these files to be worth the space they’re consuming. It seems there may be a 3-month roll-off (or maybe that’s when I last reinstalled the app?), but that’s a uselessly long period: it’s rare you can roll back to posts that old on Facebook. And I’m left to assume that there’s no limit to the size this cache is allowed to grow to. At over 400 MB, the cache on my iPad was nearly the size of two standard-def TV shows… something that would do me a lot more good than caches of links I’ll never view again.

Should there be an option to turn the cache off, or at least to cap its size or or set its expiration date? Of course there should. But given that this app is the same one that giddily uploaded all the entries in my contacts list years ago, I probably shouldn’t expect better.

Having a Moment

Please indulge me a Whiny Little Bitch moment. I will try to keep it short, but it will be petulant, jealous, and immature. You have been warned.

TUAW’s “RoadAhead is a different and clever nav app” talks up the new RoadAhead app, which finds upcoming services at US freeway exits. They’ll benefit from the exposure, and being free will certainly help.

But contrary to some of the reviews, the idea of an exit finder that figures out what road you’re on and what direction you’re going and only shows you upcoming exits isn’t new. That was the whole point of the Road Tip app I did a year and a half ago.

Obviously, I think that’s the way to go, and I’m glad RoadAhead does the same thing. I think it’s lazy when apps just do a radius search for this kind of thing, because that way you’ll find stuff that’s behind you, or is hopelessly far off the freeway. The idea of “finding stuff along a freeway” is a specific concept, and this app is true to it. Plus, figuring out where the road goes, winding back and forth, and dealing with things like name changes and state boundaries is a genuinely interesting problem to solve.

One point of difference is that RoadAhead can’t resist the temptation to pile on lots of icons and pinch-zoomable maps and other bling. As soon as you go down that road, the app becomes a distraction, and like so many others in this field, they explicitly say it’s unsuitable for use while driving:

One last, important thing – USING YOUR PHONE WHILE DRIVING IS A BAD IDEA (and in some states illegal). Hand your phone to your passenger and ask them to navigate. Please use good judgment when using your phone in the car.

I agree that using your phone while driving is a bad idea, but I still designed for it because I think people will do it anyways, regardless of what’s in your app description, EULA, or whatever. Road Tip uses spartan layouts, large text and buttons, and a design philosophy that everything should be accessible via one-thumb navigation. This frustrates my colleagues who say Road Tip would sell if I added various features, like the ability to save your search locations and drill deeper into them later (like remembering what’s at the exit when you pull off, so you can find stuff after you check into your hotel). My point was to keep the app as simple as possible for use while moving; once you’re off the road, you’ll be able to use the deeper functionality of other mapping apps.

So yay, I’m true to what I want my app to be… and I’m the only one who wants it like that.

The other thing is that RoadAhead is free, so I can’t figure how this app pays for itself. I decided early on that RoadTip couldn’t be ad-supported, because showing an ad to a driver would be unconscionably distracting. So I opted for a pay model.

And that brings up my other point about my exit-finding competitors. I’ve never downloaded them — I don’t want to get in a situation where I could willfully or inadvertently plagiarize them (this is why I also don’t read other people’s books on topics I’m covering) — but I’ve looked through their descriptions and legal terms, and I’ve never been able to figure out where apps like RoadAhead and iExit get their location data. That I use MapQuest is obvious; I’m contractually obligated to have my users accept the MapQuest TOS, and I have to put a “Powered by MapQuest” notice on any screens that result from their data.

So where are the other guys getting their data from? As I wrote in Bringing Your Own Maps, my research revealed that the map data providers’ terms of service for their free services always prohibited use in paid iPhone apps, either because they required callers be free and public web apps (Google Maps TOS, section 9.1.1(a)), or prohibited use based on GPS location (i.e., “present or alert an end user to individual maneuvers of a route in any way that is synchronized with the end-user’s sensor-based position along the route”, as in the Bing Maps TOS, section 2.i), or both, or something else.

This stuff is why I had to enter into commercial licensing with MapQuest (whose terms and API I liked best). Not sure what the competition is doing. Maybe they found some way to get free data legally, maybe they’re getting away with not… it’s not really my business I suppose. But if it does turn out I’m the only one playing by the rules, yeah, I’ll be a little pissed.

I keep calling them the competition, and I suppose that’s not accurate. I’m not competing at all… I’ve totally capitulated. I’m unlikely to put any further work into Road Tip, outside of possibly switching to the new I-AP subscription model that restores across devices (good for my long-time users, bad for me because it means sinking more time into this miniscule-selling app). If Ford ever followed through with opening their Sync / MyFordTouch API to third parties, I might make Road Tip work with it, but then again, I might do so just for my own use and not release it. It’s not something that I really feel like putting any further public work into.

OK, whining done. Back to your regularly scheduled blog.

In-App Purchase Fanboys

I’ve blogged a lot about in-app purchase recently, and I’m finding that every time I tweet about it now, someone parrots back this “Apple is bringing customers to you, so be grateful” line. It’s a response that’s taking hold among Apple apologists, and I don’t think it’s nearly the counter-argument that its adherents think it is.

This argument is something that Daring Fireball’s John Gruber comes back to, notably in his Dirty Percent blog entry (more on that in a bit). But there’s a nice counter-argument in Josh Benton’s To the Victor Goes the Pricing Power (a title that parallels my own arguments that Apple is rent-seeking). Benton writes:

But if someone searches for and downloads The New York Times app — after the Times has spent more than a century building up its brand, at the cost of billions of dollars — can it really be said that Apple has “brought” that subscriber to the app, and that they deserve 30 percent of the revenue the app generates, forever? (Gruber doesn’t address the eternal nature of Apple’s cut; it’s like paying a New York apartment broker his finder’s fee, every year for the rest of your Manhattan-dwelling life.) It certainly seems like a transaction different in kind from, say, a game that exists only on (and only because) the iPhone platform.

Now back to Dirty Percent… one thing that’s interesting about this essay is the degree to which Gruber acknowledges the legitimacy of many of the arguments against Apple’s new policy. He explicitly agrees with Matt Drance’s criticism that the price matching requirement is unreasonable, is troubled by the fact that the new requirement to offer I-AP for digital products available elsewhere is “is taking away the ability to do something that they previously allowed” (in more recent entries, he’s gone further and said this feels like a bait-and-switch), and on the topic of 30% being too big a cut for doing little more than a credit-card swipe, he simply responds that “Apple… doesn’t see it this way”, neatly avoiding taking a stand himself.

Far from an absolute defense of Apple’s new I-AP policies, Gruber has wisely distanced himself from the most indefensible of Apple’s actions, and left himself some wiggle room in case things change.

The most rabid Apple defenders have also blithely ignored the inherent problems of I-AP, preferring to change the conversation to a “old media needs to change their business models” argument (which makes them sound curiously like the “everything should be free” crowd, who willingly misread Lawrence Lessig and Tim O’Reilly in order to justify content piracy). As I’ve said on a number of occasions, “if you don’t hate I-AP, you haven’t had to use it yet.”

A client of a client of mine is likely to get caught up in this I-AP drama, and in a meeting this week, we laid out exactly how I-AP works, and what they have to do in order to implement it, including entering every product into the iTunes Connect web interface, a nightmarish prospect when you have thousands of SKUs. When we finished, there was a long silence on the phone, followed by a colleague saying “you can probably imagine the look on everyone’s faces here.”

Adapting a company’s current digital storefront to incorporate I-AP is a grievously unpleasant proposition. Adding a storefront UI and Store Kit to the iOS app, plus integrating I-AP on the server side (coordinating I-AP purchases into the existing storefront, validating purchase receipts with Apple, etc.) will cost tens, if not hundreds, of thousands of dollars in developer time. More work for me as a consultant, but I can see why clients aren’t eager to spend it.

Because think about it: if the “Apple will bring you customers” argument were valid, everyone would have willingly done this back in 2009 when I-AP first hit the scene. It would have been in their self-interest to do so.

Look, I used I-AP in Road Tip because it suits the economic model of the app: I have ongoing service costs to MapQuest for every user; a data subscription plan is an appropriate way to cover that for users who continue to use the app. But it’s not necessary for other kinds of apps, like apps that view content the user has acquired elsewhere, or deluxe clients for websites that don’t work correctly in Mobile Safari (because, say, they depend on Flash).

The legitimate fear is that some content won’t be available at all for iOS because the hassle and expense of I-AP is too great. Obviously, Apple is counting on this not being the case. And I think this is a bigger deal for the small, niche content than for the big media companies. My fear is that the Apple Fanboys will go out of their way to purchase content through Apple as a political statement, so the small providers that somehow do cobble together the resources to add I-AP and enter all their content into iTunes Connect will then lose 30% on every sale that they could otherwise have run through their website. If you’re determined to pay Apple and only Apple for your content, you’d better hope they’re capable of meeting all your content needs indefinitely, because you might lose third-party content providers in the process.

For all you conspiracy theorists…

One more nugget about the I-AP subscription dustup (my previous blogs: 1, 2), particularly for all you conspiracy theorists who loves you some nefarious skullduggery!:

What if the real story here is that Apple has decided to release an AppleTV SDK later this year? Streaming media apps would be far and away the most appropriate use of such an SDK — nobody needs Twitter clients for their TV or Angry Birds with a tiny D-pad — and by establishing a 30% tax on content now, it would be a fait accompli by the time the first Hulu, NFL, and Crunchyroll streams roll through port 80.

Not that I have any reason to think this is what’s going on. I’m just putting out there now in case I get lucky and get to do the “told you so” happy dance later.

You’re welcome. Happy conspiring!