There’s a kerfluffle going on with the Apple App Catalog over “crap app”, which is a bit of a misnomer because the primary anger is being aimed at developers who build apps aimed at grabbing money with poorly designed copycats of more famous apps. Sort of like what Zynga now does for a living, but not on Facebook.

What caught my eye were phrases being thrown about like “Apple’s missed opportunities to prevent disaster were such simple and quick fixes”, which, once I stopped laughing, made me want to cry in sympathy.

It’s not simple. It’s not quick. If it was, Apple would be doing it.

In my previous life, I was involved in these issues on a regular basis. Before we hired our App Review gods and goddesses, I didn’t duck fast enough and got do do that as well. I was in on the discussions with the lawyers setting up the rules early on; I was consulted (as the voice of the developers and official tie breaking vote when needed) on apps we weren’t sure passed the smell test on whether they should be published.

So I can pull out and play the “been there, done that, no T-shirt” card here.

And the reality is, it ain’t easy. And what Apple probably would LIKE to do it probably can’t, and would open itself up to various legal challenges and a whole can of really foul tasting worms.

Your first problem: one of the underlying concepts of the DMCA process that gives companies a safe harbor is that they take a hands off approach to the content. There are some broad areas where exceptions to this are carved out, especially around adult content, and there are some areas where companies have decided to do some broad fireaxe enforcement like the “make me rich, do nothing” apps. But the reality is, once you start policing content, you start opening yourself up to liabilities on all of the content you do not police. It can even cost them the safe harbor, and then the entire app store infrastructure could be at risk.

So you have to be really careful how and where you do your enforcement and bans, and you have to do these things such that you minimize opening yourself up to legal or PR fights over “you did that, why aren’t you doing this?” as well. These quickly turn into scenarios that make lawyers wake up screaming. And situations that boil down to “he’s ripping off this other person” become entirely subjective, and as a reviewer, you can make jokes about the app (privately), but you can’t reject it for that — until someone files the complaint of infringement. There’s a legal protocol defined here, and if you cross that line and start pro-actively rejecting apps, you are buying yourself and your company a whole lot of legal indigestion.

There’s just a wide swath of things that a company like Apple really can’t (and shouldn’t) do, and if they DO, they’ll end up getting yelled at. Think back over the last couple of years over every time an App doesn’t get through the review process into the catalog, and the developer complains, and everyone gets up in arms over “big brother Apple” and yells for a while. And here we are, calling for Apple to do MORE big brother stuff.

Apple is in a no-win situation here. Because you know if they did start being more pro-active here, it’d just feed the “apple is big brother” screamfests instead.

The Curious Case Of The (Cr)apps That Make Money | PandoDaily:

Apple has a serious problem on their hands, and it is one they need to fix it as soon as possible. No, this isn’t a diatribe about the lack of Flash on the iPad. And, no, this isn’t about the need for an SD Card slot for iOS devices. Instead this is an issue that Apple’s biggest ally – iOS developers – are complaining about, one that hurts the user, and one that could end up damaging the iOS ecosystem more than any set of labor issues ever could.

The issue we are facing, is the proliferation of scamming apps.

 

 

First, Apple needs to cut off the funds. Taking the approach of going to the root of the problem, Haddad noted that if Apple “makes it clear that if you try to defraud customers, then you aren’t going to get any money. If there’s not any financial incentive to scamming then it’s very likely that most of the problem will just go away on its own.” This would likely cut out most of the scam apps from the App Store.

 

As soon as you start touching money, it gets even nastier. So, if Apple cuts them off and doesn’t give them the money, then what? Apple keeps it? refunds it? If you refund it, what do you do with everyone who wants refunds for apps THEY feel are scams, but Apple doesn’t agree? What do you do about all of the people demanding refunds, and because the only way to get a refund is to have it declared a scam app, starts complaining that everything they decide they don’t want is a scam app?

This is a a PR and customer support nightmare. trust me on that. Even in a “no refunds for whatever reason” policy app catalog, refunds are a horror. This just makes it even more of a horror, because now a chunk of users will try to wedge what they want into this policy to get what they want.

Only real solution? How about a “refunds for seven days” for any app users don’t want? Developers, do you really want to go down that path? Apple would have to hold funds another 30 days or so before sending them to you to avoid having to claw them back. Users could pay for an app, use it a while, then get their money back; free seven day rentals of your full function app, effectively. if I were a game developer and Apple proposed this, I’d be headed to cupertino with torches and pitchforks. Be careful that the “fix” doesn’t create an even nastier problem.

 

However, in between the time that scammers hit the Top 100 and the time Apple is issued a takedown notice, many users can get irritated by the lack of quality apps in the store. To mitigate this problem, Haddad recommends that Apple start to curate the Top 100 list beyond automating it based on sales.

 

And whatever policy Apple implemented on this, it’d create a firestorm, because “the fix is in!” because it is.

The core problem here: Crap apps are like porn. everyone has their own definition (which overlaps in many, but not all, places), and everyone sees what needs to be stopped as obvious. And however you define these rules, it’ll piss off enough people that the firestorm will probably be continuous.

 

The real question is what happens if Apple does nothing and continues to use their flawed policies. It hurts the user, who loses their money. It hurts the overall App Store ecosystem, as people stop trusting the look of applications, decreasing sales. Finally and most importantly, it hurts the developers, who have to fight harder for users, as user trust will continue to decline. There are any number of end-game results, and none of them are good. Apple needs to nip this in the bud now, before it gets any worse.

 

All of which are to some degree true. But be aware of fixes that actually create different, bigger problems.

2012: The Year Scam Apps Killed the App Store | Impending:

 

A Beefed Up Fraud Team: I can only speculate at the size and competency of the App Store fraud team,

 

Is this fraud? If an app developer’s intellectual property is infringed, the DMCA process already exists to mediate that conflict and take it to a resolution. This isn’t Apple’s responsibility to deal with pro-actively, it’s the developer. If the developer initiates a complaint, there’s a (long, complex and ultimately off to the courts to decide) process to follow. It works, and it actually takes into consideration the issues of BOTH sides of the complaint a lot better than ACTA or SOPA ever did… Apple’s IP isn’t impacted here, so it has to stay out of it. As a developer, you need to work the system to protect your IP. Apple won’t (can’t, and shouldn’t) babysit for you.

 

Automated Returns: What I can’t fathom is Apple’s refusal to automatically refund all customers who were defrauded of their money. There have been hundreds of open and shut cases, and to this day Apple requires customers to jump through hoops and phone calls (in 2014!) to receive refunds. This is insanity.

 

Discussed above. Ask a high end department store about women “renting” dresses for parties to see how much fun a relaxed refunding system would be for developers. Especially game developers. Be wary of what you ask for.

 

Video Previews in the App Store: Requiring a short video demo of the app in action would have prevented the common scam of providing one or two misleading screenshots to fool browsing customers.

 

Hah! we did that. It works great! Apple should. seriously. Or you can post them to Youtube or Vimeo now, and link to them in your marketing material. Seriously, this is a great idea. It works. If you aren’t doing free trials or screen videos of your stuff (especially games) you’re missing a great marketing opportunity. Ways to enable this by Apple would be a nice addition.

 

Better Education of App Store Customers: Much like the fashion industry, the App Store’s plague of knockoffs created a problem of uneducated customers unable to recognize the real thing vs. the counterfeit until after the sale.

 

“educating the customers” is something people have been advocating forever. And it always fails, because there’s always a subset of them who can’t or won’t be educated. Which doesn’t mean you don’t do it, because to the degree you can do it, it reduces your problems. But — it won’t solve your problem. Just reduce it.

 

The App Store could have done a better job profiling quality studios and developers, beyond highlighting individual apps, and rewarded those who built an ongoing track record and reputation. Not just developers, but App Store customers as well, to weight their reviews and ratings.

 

In my previous life, I designed a neat social system to do just that, and couldn’t get the people who should have been interested to care. Heck, I sat in meetings with product managers where I had to explain why pulling an app from the catalog if ONE PERSON flagged it as offensive was a bad, bad idea. And I had to argue about that multiple times.

But heck, I still have the design, and I do think a self-regulating community could moderate a lot of these problems if properly implemented. It’s too bad we never got past “I think we should have a LIKE button” in my previous life. And I’m open to discussing this with the “right people” if they want my advice. You know how to find me (or send me a linkedin).

Automated self-policing policies are the right answer here, if done well. If done badly, don’t bother.

The big problem in all of this? Discovery in an app catalog ecosystem still sucks. We didn’t solve that problem. Apple has made some progress, but it’s still very much not a solved problem. And it won’t be any time soon. Because it’s hard. And that’s why when I see phrases like “simple and quick”, I laugh, to hide the tears. buy me a couple of beers, I’ll show you the scars… As a developer, frankly, you should know better than play the “how hard can it be?” game, because isn’t that what your non-developers friends say about that new feature they want you to add to your app?

If it was easy, Apple’d have done it by now. Seriously.

(hat tip: Daring Fireball for the links to these)

When I first saw what Apple was doing with the sandbox and the restrictions it causes, my guess was that they’re setting these restrictions up for something else — and it seems to me the most likely thing is there’s some new product line coming (next gen apple TV box, perhaps?) and if your app is compliant with the sandbox restrictions, it’ll work on this new device, day one.

So what they’re really doing is getting app developers writing for this new product line, without telling them that’s what’s going on. IF you fit within this box, you’ll fit on this new thing, whatever it is.

Just thinking out loud. But that seems very much like Apple.

Red Sweater Blog – Fix The Sandbox:

At its best sandboxing is a means for app developers to faithfully state their intentions in a manner that can be evaluated by users, and also be reliably enforced by the operating system. So if your new “Fun on Facebook” app declares its intention is to connect to the web, you might judiciously allow it. If it says it needs to write files to the root of the filesystem, you’d be wise to search for another app.

 

Sandboxing on the Mac works by providing developers with a standardized list of “entitlements” which are clear descriptions of things it would like to do on your Mac. Examples include: access the internet, read files from your Pictures folder, print things on your printer.

The number one broken thing about sandboxing as it stands today, is the list of entitlements is simply too limited. Many apps on the App Store, including my own, will need to have their functionality considerably diminished, or in some cases made outright useless, in order to accommodate the available list of entitlements that sandboxing offers.

 

Your Address Book Isn’t Yours | PandoDaily:

When you agree to upload an address book en masse, you ignore this mish-mosh collection of agreements and are treating that data as if it’s yours, when it absolutely isn’t.

So, what do we do? We’re not going to come up with some magical replacement for good ol’ contact cards — it’s been tried before, and always falls to simplicity.

 

And if you stop to think about it, the company that understood this was Facebook, and it got roundly criticized by many in the tech elite for trying to limit people’s ability to slog this data around from service to service.

This was also something we tried to manage in Synergy in webOS, and we got roundly criticized for it, as well, because the mental model most people has is “my address book”, and it was a point of — discussion — I had with users and developers on a regular basis, because our decision to tie records to the service they came from made sense in some ways, but made it difficult to build the kind of PIM services people wanted. And part of the reason they wanted them was because those services existed long ago on Treos running webOS, and they couldn’t understand why they didn’t exist on webOS.

I’m not pretending that we got it 100% right (I don’t think we did, not close), but this is a problem that didn’t exist in the days of the Treo, where data didn’t live on 30 different services with 30 different terms and conditions.

This is a cat that needs to be belled, but I haven’t seen a mouse able to get close yet. Plaxo dealt with some of the micro issues, but not the macro challenges. The fact is, this is all brand new, and the rules of engagement (and disengagement) in a world where data is hyper distributed and not easily controlled by the owner.

And that’s my view of this — it doesn’t matter that the data lives in your address book, or on google, or iCloud or yahoo or wherever. It’s still MY data, even if I gave you permission to store a copy for your use. I should have the right to say how that’s to be used, and how it can be shared. Or whether.

Which means there needs to be some way to infinitely distribute that data while still having that data check with some authoritative point for both updates and access authorization.

You really want to be the service that controls (and monetizes) someone’s online identity? Solve that problem, and we’ll all use your service to manage how people access our personal information.

And until that happens, these fights and challenges will continue…