There have been a bunch of comments and criticisms flying around that iOS 8 is missing any kind of API or SDK for developing applications to take advantage of the NFC chip in the iPhone 6 and iPhone 6 Plus. One article at least even went as far as to describe the decision not to provide one as “stupid”.
I disagree, not providing APIs in the first iteration of hardware has been pretty much an Apple standard operating procedure for a long while now, and I think it makes perfect sense in this case as well.
The most typical thing a software developer is going to do with an NFC API is write an app that reads NFC tags. The Android store is pretty much full of these; you download an app, you tap your Clipper Card on it, and it tells you a bunch of meaningless gibberish.
This isn’t very useful, because it turns out that the more interesting cases for NFC are when the phone is acting as a tag. And that means it’s the infrastructure to read those tags that needs to be built, not apps on the phone.
Take payments for example. Apple could have simply provided an API to allow card issuers to write an app that presents itself as the card. You’d download your Wells Fargo, Capital One and American Express apps, and each one would do payments slightly differently, and there would be a plethora of different incompatible readers out there.
They didn’t do that, instead they worked with the payment providers to ensure a harmony of the readers, which means one single app (Passbook) can support all of the cards out there.
What else is interesting? What would I do if I were Apple? I’d look into ticketing, especially things like for public transport. Again an API isn’t much immediate use here, because it’s the reader technology that matters. The phone simply needs to have the soft ticket loaded onto it, and again that’s something that Passbook can do.
The only API needed for that would be a way for a website or app to load your Passbook app with a soft ticket. Not much different from how Passbook works today with the current QR Code and Barcode style tickets. The rest of your app would probably just interact with your own billing and logging systems via a web api to present users with interesting data.
There might be “interesting use cases” later down the line for which a native app SDK would be useful, but first users need the uninteresting use cases like payments and ticketing to work flawlessly.