Apple's new announcements touched so many startups it's scary. iMessage takes on all the free/group messaging apps that have been built lately. iCloud takes on (maybe not very well) rdio and other streaming music services. Airdrop takes on dropbox, box.net etc. Reminders takes on rememberthemilk and other GTD services. How about the camera plus app that Apple took off the app store for making the volume button a camera button? Now Apple implemented that feature!
The Paul Graham quote used in this article was spot on, especially the part about "...you may find that you were merely doing market research for them."
This is the problem with building apps on top of another company's API. You will forever be subject to their rules. Whether you're building on Facebook's API, iOS, or even Amazon AWS...you will always be competing to a disadvantage.
>How about the camera plus app that Apple took off the app store for making the volume button a camera button?
Not exactly. Camera+ was not approved for the app store because of the volume button as camera shutter feature, so they resubmitted but hid the feature from the reviewers by including it as an easter egg. It was removed for a while from the app store because of that intentional deception. They're lucky they were allowed to resubmit the app at all after that (and so are we all, it's a wonderful camera app).
"Lucky"?? This is why I'm glad I'm not an iOS app developer.
So the app with the "volume button as camera" feature was rejected, then within a year Apple turned around and implemented the same feature themselves.
Even if they didn't directly steal the idea, it seems like a pretty slimy tactic to me.
Slimy? What exactly would you have had them do? If they let the app through using a non-public API, they have to explain why some apps are allowed to use private APIs and some not, opening a can of worms which it is easy to understand they would prefer to keep closed.
They couldn't change the public APIs until the next release of the software, which is exactly what they did, and I imagine that Camera+ will be able to benefit from that API much as any other app.
Is it about the use of a private API or just the violation of the Human Interface guidelines? Everything I've read has said it's just about the guidelines, not because an API needed changing.
For me it's all about the timing. They should have relaxed the guidelines and/or policy about reusing the volume buttons for other purposes (not just for use as a camera shutter, presumably) at some point before they released an implementation of the exact same idea as a third party.
>>EDIT: Re-read the original rejection of the Camera+ featur
It's kind of insane that they wrote that blog post explaining what other developers are doing (and the penalties they face for doing it) and then turned around and included "Volumesnap" through a back-door anyway. So yes, they're quite lucky they were able to resubmit the app later. There's no doubt they knew exactly what they were doing.
You might say it's slimy, but turning it on its head (and without looking at the new APIs, etc.): Apple realised with Camera+ that there was a need for a physical button for taking a picture, the inclusion in iOS5 of this feature means that all camera apps (presumably) get the ability to use the physical button, rather than the camera apps hacking it in.
Again, I don't know if Apple is opening this up, so I won't describe it as slimy or not.
Someone like Red Pop [1], however, might be worse off though...
Edit: Re-reading the rejection notice from your link [2], it seems clear that Apple won't be able to reject people based on that clause again. At least, using the volume button for camera now seems to be pretty standard (IANAL so YMMV).
[2] »Your application cannot be added to the App Store because it uses iPhone volume buttons in a non-standard way, potentially resulting in user confusion. Changing the behavior of iPhone external hardware buttons is a violation of the iPhone Developer Program License Agreement. Applications must adhere to the iPhone Human Interface Guidelines as outlined in the iPhone Developer Program License Agreement section 3.3.7«
Google doesn't block you from releasing your own apps, though. They don't use the Market to enforce their interests (and if they would there's Amazon's app market etc).
That's one line out of a 30 line post. Yes, but the issue is them competing with you (with regards to this iOS5) not them not allowing you to do the feature.
Except none of these services are cross platform. Thus, many users will not be interested. The IM apps will do fine because groups of friends very often have several types of phones. Same goes for dropbox.
This is why competition is good and investing all your eggs into a single walled garden is dangerous.
No if you use the tools correctly then you'll be a major advantage because it's a lot easier to use the Facebook / Twitter API than to construct those things yourself. If you're building a telco probably not a good idea to use someone else's telco infrastructure, if you're selling chairs, it's probably a good idea to buy phone service, rather than construct your own infrastructure.
Does iCloud work on Android? Does it work on a PC? I doubt dropbox and instagram are in any danger because they have barriers to entry that Apple is likely unwilling to take. How many dropbox subscribers are going to go away? Probably not many. Could they lose a bunch of free users? Certainly.
I don't have the data, but I wouldn't be surprised if DropBox had a disproportionately large market of users that were purely on the Apple stack -- and tended to share with other Apple users (when they did share across ppl).
The Paul Graham quote used in this article was spot on, especially the part about "...you may find that you were merely doing market research for them."
This is the problem with building apps on top of another company's API. You will forever be subject to their rules. Whether you're building on Facebook's API, iOS, or even Amazon AWS...you will always be competing to a disadvantage.