Don't forget "They might break the API without warning. Every two to three months. (Facebook)."

Your argument is exactly why I don't use Google AppEngine. I know there are open-source stacks now that you can use if you want to take your AppEngine code in-house, but trying to build up an AppEngine infrastructure at probably the worst possible time ("we're getting billed @ $10k/month, but only making $8k! getting more popular will cause us to lose more money! quick, switch to custom servers!") when you can build up a solid infrastructure using technology that you can replicate on any VPS or managed box or colocated hardware that you buy seems the easiest way to scale.

AppEngine is stable, but the feature set moves quite slowly. It's the opposite of Google Drive, it seems. It's the opposite of Google Drive, in that respect.

If I didn't know any better, I might think there is some sort of correlation between moving fast and breaking APIs (or "things" as Facebook likes to call them.

Yeah, that's true, but it's also true that you're always building on someone else's API. I mean, even if you build a native desktop application, you're still relying on Windows, Linux or OSX APIs. Granted, those APIs tend to be more stable than the APIs for mobile clients and web clients, but it's not like there haven't been painful breaking changes on that front either.

So what's your solution? Write everything in assembly and run it on your own servers?

I think the way to proceed is to look at the stability of the API and the historical level of backwards compatibility that the API creator has provided and explicitly take that into account when you're developing an application. This is one of the things that Microsoft does very well, better than Linux (where GUI APIs, especially, seem to mutate every few years) and OSX. In general, though, any desktop API is much better, in terms of maintaining backwards compatibility and announcing breaking changes, than any mobile (iOS, Android, etc.) API, and mobile APIs, in turn, are better than web APIs. This isn't a case for never using mobile or web APIs, but it is a case for ensuring that you have enough resources (or a loose enough timeline) to deal with API churn as well as developing new features.

The only way to get away from APIs entirely is to write your own code, run it on your own OS, using custom hardware that you've designed yourself. That way lies madness, or, equivalently, game console programming ;)

If I write an app for Windows XYZ, my users can continue to run it as long as they keep using Windows XYZ, not as long as Google decides to keep running a service.

I thought Microsoft could kill a Windows app they didn't like these days. Maybe I'm wrong, and your point stands for earlier versions of Windows and Linux.

I was using 'Windows XYZ' as a placeholder, but yes, my point was w.r.t to earlier versions of Windows, Mac OS, and Linux.

Really? How can Microsoft/Apple/Linus kill an app for recent versions of Windows/MacOSX/Linux? Perhaps I'm getting a different meaning from "kill" ... do you mean it won't be allowed or that the API's would change so much that it's not worth updating the app?

I'm on board with most of your examples, but in my mind the iOS example is different from the rest. iOS is an operating system designed to run native apps with a default UI. Apps can build on top of the SDK and optionally build it using the default UI. I've had apps that did these and they've been fairly stable throughout the years. It's even functional for iOS 7 if I wanted to leave it alone. I also have apps that have its custom UI that won't be changing at all for iOS 7. Of course, the same way that a developer might want to update a Win 95 app for Win 7, he or she might want to update apps when new iOS versions come out.

Is the criticism due to the annual version update? Or is it because there are API changes every new version? If it's the latter, wouldn't updates be expected, and in fact desired? It may just be me, but I've had good experiences when it comes to API stability with iOS. I've been unable to keep up with the newer features (I'm indie and only work on apps jn my spare time) but the new features rarely get in the way of my app being able to run with the calls they are already making.

I'm aware of the UDID deprecation from before, but devs were given plenty of time to transition from it. Actually, I was surprised how much time they gave.

Authentication via third parties are not an inherently Bad Thing. Mozilla Persona shows how third party authentication can be done, without risk of user base hijacking,

While it's true that Mozilla can't maintain a list of what services their users are using, there are still security implications to using Persona. Mozilla (or anyone who with their private key) can still enable access any user account on any Persona enabled site.

Persona is perfect for blogs, but using it for a service people may be paying for, or handles any private user information (postal address, private messages or posts on a forum etc) is a bad idea.

> If you build something on someone else's API, you can get fucked in a million ways.

I feel you should mention whether or no you pay for the API and have a legitimate contract enforceable with law.

This is one reason why I don't use google APIs; I can't pay for them with any sort of reasonable SLA.

You might get an SLA for money but you can't stop a product from disappearing.

But if you have a contract, you can at least expect the product to exist for the term of the contract.

Which is unlikely to give you more than a few months, the same time you already often have, and still won't protect you if the company has trouble.

Build your solution suitably decoupled, such that if you lose access to the API you can easily switch to another provided. Ideally build solutions across two competitors services such that if you get any surprises it's clear that your solution works / users are able to migrate to the alternate provider.

For authentication I'd argue in some ways it's better to provide the option of third-party. This means users don't have to submit credentials to you. Given most people (against advice to the contrary) use the same username and password for most sites signing up to an unknown company's service feels riskier as they're then giving that company their credentials, which someone may then try on other sites - having a token which allows them to sign in with their Google/FB/Twitter/etc account saves this worry / only requires the user to hit an "authorise" button.

Some additional points:

- Be careful with companies that don't sell the API or SDK as a product (Twitter, Google, Faceboook, etc.)

- Watch out for companies that don't like to publish roadmaps and makes APIs and SDKs deprecated or obsolete with little warning (Apple, and more recently Microsoft)

I think S3 is a counter example.

Because you pay for S3, AMZN has many incentives to make it reliable and keep it going.

A free API might look like a giveaway, but it is ALWAYS a chance to take.

> They might also decide that your product is very good and build a version of it themselves, using functions not available to you via the public API so that you cannot compete with it (Apple).

Can you give an example of that?

Camera apps that wanted to use volume buttons for taking a picture. Apple banned them... and then released it themselves.

I believe at some point iBooks could go to a darker brightness setting than other apps were allowed to.

Those are the two that jump to my mind.

Notification Center > Growl?

Growl 2 integrates with notification center.

Reading List

iOS 7 will have a built in flashlight feature.

There is no cloud, only other people's hard drives.