A Little Ambiguity Goes A Long Way...

This is not an article about iPhone developer angst boiling over. It’s not an article about the implications of the developer of the Facebook app giving up on iPhone development and Rogue Amoeba doing the same.

I’m just here to shred Jeff LaMarche’s rather harsh take on Rogue Amoeba’s decision. You see, I think he may have misread things a bit and in so doing, utterly missed the point.

Rogue Amoeba complains that their use of images of Apple Mac hardware is not a trademark infringement because there’s a MacOS API that provides these images. Jeff LaMarche contends that what APIs MacOS provides is not relevant on the iPhone. Furthermore, he contends that the fact that a previous version was approved and the new version is not – with no changes in the contested functionality – is not relevant. Rogue Amoeba signed on, knew the risks, did something stupid, end of story.

When I finally was able to read the Rogue Amoeba post, I came away with a different view of what might have happened. I think Jeff read it as “we put these pictures in our iPhone app thinking it was OK because MacOS will give you those pictures.” I read it as “our desktop app uses a public API to composite an image that is sent to the iPhone app, and displayed to you.”

That may seem like a difference without distinction – the end result is, after all, the same: An iPhone app showing Apple hardware and Apple software icons. But it makes all the difference in the world. Let me proceed, under the assumption that my interpretation is the correct one (hopefully Rogue Amoeba can clarify whose interpretation is correct).

Let’s look at a hypothetical situation which is functionally identical: Let us say, for a second, that I made a web browser for the iPhone. Let us say, further, that I included a bookmark by default that took you to the Apple Store. The reviewer, upon seeing that, then rejected the application because it used trademarked Apple images.

This would be quite obviously absurd. But this is the sort of thing developers face all the time when writing for the iPhone. Now, when faced with a risk like this the proper response from entrepreneurs/management is to mitigate the risk by “making smaller bets” – don’t invest a lot in a single app if there’s a high chance that the app will fail. Apple being capricious just ups the odds that any given app will fail beyond the usual market risks.

BUT, here’s the gotcha: The small bet approach is predicated upon the idea that you can make further incremental bets later on. That you can get from zero to a high-value product offering over time and at low risk by re-investing on things that have paid off. Incremental development.

What happens when you can’t count on that strategy anymore? What happens when each incremental bet carries a risk of your product simply being killed. If Apple can say “the last version is fine but the new version is not acceptable”, then they can essentially derail any product you make any time you attempt to improve it.

This puts a cap on how much it is wise to invest in the lifecycle of a product. It guarantees that only the most massively successful products become worth improving over time. That carries with it the very real risk that the App Store will NOT achieve a stable economic equilibrium but may in fact implode, or simply never mature to the point of being truly and continually “interesting” (in the financial sense) for anything but hobbyists and small players.

Of course, that all presumes I read the article right, and that Apple doesn’t change their ways. Hopefully the actions of folks like Rogue Amoeba will help nudge Apple in the right direction sooner rather than later.

musings 647 words, est. time: 129 seconds.

« License of UnityUnit Pathfinding in Unity »

Comments

Copyright © 2016 - Jon Frisby - Powered by Octopress