iOS 6 Predictions

March 6th, 2012
Spencer Nielsen Follow snielsen42 on Twitter

It is always fun to try and guess what Apple is going to do next. You can guarantee that there will always be surprises and sure bets, letdowns and magical moments. The Apple rumor sites do a decent job of soliciting leaks, reading between the lines and making educated conjecture. As a developer, I often like to take a good look at where Apple’s technology is right now and make logical extrapolations as to where things are headed. Oftentimes, when Apple announces some new feature or technology it seems obvious in retrospect if we had only connected the dots. Based on 2011’s release schedule, it is a fair bet to say that Apple is going to announce iOS 6 at WWDC sometime this summer and distribute a developer beta. That means that in the coming months little trickles of information are going to get doled out to the rumor sites about what kind of changes and additions we can expect. Just for fun, I wanted to get my own predictions out in the open before any of that started. Here is my very developer-oriented prediction list of what we might be expecting in iOS 6.


UPDATE: WWDC and the iOS 6 beta have come and gone. Some of my predictions now have conclusions. You will notice however that most of the predictions have not yet been updated. That is because there is the potential for Apple to be keeping a few more surprises up their sleeve for the fall when iOS 6 goes GM. Inline below are the results so far.


UPDATE2: iOS 6 GM is here which means that the NDA has lifted! Check down below to see how well I did.

(Miss)  90%

Notification Center API

It seems often that Apple will introduce a new feature or technology, keep it fairly closed off from developer access for a cycle and then release an API for it after they learn a little more about how people really use it and work out many of the initial kinks in the system. Notification Center seems very ripe for this kind of API access. Apple has had a full release cycle to gather user reactions and think about how to design a really clean API for developers to hook into. Of course 3rd party apps can already get their notifications listed in Notification Center simply by using the same old Notification API that has been around since iOS 3. However, there is currently no way to further customize the display and do anything fancy like the weather or stock widgets. There are already a lot of nice additions and hacks for Notification Center in the jailbreak world (which also it seems is a good indicator of what frameworks and APIs Apple is likely to open up next). This seems like a nice, low-risk, natural progression of a fairly straightforward technology that has already had some time to grow up a bit by itself in the wild.


UPDATE: Hmm, the absence of this is somewhat troubling. A year should be enough time to get a public API for a shipping technology in order. To me this seemed like a no-brainer. I can only assume that for scheduling or other reasons this got bumped to NMOS which means that I am holding on to this prediction for next year when iOS 7 comes out.

UPDATE: iOS 8 now brings Notification Center widgets.

(Miss)  80%

Siri API

Siri was the hot new feature of iOS 5 exclusive to the iPhone 4S. For 2 weeks everybody swooned over it and would use it to impress their friends with interesting natural language queries like “Where’s my wife?” or “What’s the volume of 63 grams of barium?“. Then we all hit the limits of what Siri could do and she became just another feature. Like Notification Center, Siri has had a full release cycle for Apple to study user response and nail down the user experience. It is time now to unleash the real potential that Siri promised us and allow developers to hook into it.

If generalized into two broad categories, Siri can accomplish two different kinds of tasks. First, she can answer questions by querying a web service like Yelp, Wolfram Alpha, etc… Secondly, she can perform simple device-local application tasks like create reminders, create calendar items, call phone numbers and send messages. It seems like Apple would want to vet any sort of web service that all Siri users could potentially smash with traffic and so the more likely route of opening up Siri would probably lie in attaching APIs to performing simple actions or application local queries. Imagine if you could ask your turn-by-turn direction app for directions with your voice instead of typing addresses or if you could tell your stock trading program to perform certain actions by voice (that could lead to some hilarious headlines, just be sure to always listen to Siri’s confirmation first). This kind of an API seems like it would be fairly difficult to design correctly and would probably require more of the developer than something like Notification Center. I expect that at a minimum, Apple will initially have a few cookie cutter commands where developers can plug in their own simple verbs and nouns. “Siri, compose tweet: ‘had cereal for breakfast today’“. “Siri, how many (insert virtual game currency here) do I have?“. Developers can instantly leverage Apple’s voice recognition tech and give their users access to all the information and tasks that their applications offer. This seems like the natural progression for where Siri has to go next if she is going to keep distinguishing herself from competing assistant programs. Much like the advent of the App Store itself, it seems like Apple is poised to spark another app revolution which will cement its platform by harnessing the power of it’s developers once again.


UPDATE: Likewise I feel that the omission of a Siri API is quite puzzling. There was a ton of welcome improvement to Siri over the course of the year. However, I feel like there is a gold mine of untapped developer value just waiting for Apple to harvest it with a Siri API. Again, this advancement is too powerful and too obvious to not be coming sometime and so I am also going to hold on to this prediction for iOS 7 as well.

(Miss)  65%

Full Bluetooth/30-pin API

Both users and developers alike have been clamoring for a public API to the 30-pin connector and Bluetooth stack for years. Apple does have an official MFi program that hardware developers can sign up for, but they have to purchase high-priced decryption chips from Apple for every peripheral they build and pay significant licensing fees. For years it seemed like it was in Apple’s best interest to keep a very tight quality control over the kinds of peripherals 3rd parties could produce for iOS hardware, but with devices like the 60beat GamePad (and to a minor extent the Square Card Reader) which side-step Apple’s lockout by going through the microphone input in the headphone jack, it is clear that the bar for developing hardware peripherals needs to be lowered. Incidentally, I have a friend who is currently developing an iOS peripheral using audio input over Bluetooth and software signal processing to avoid paying the licensing fees and integrating the decryption chip.

After taking a closer look at iOS 5, it appears that Apple is slowly heading in a more open direction in this regard with the addition of the CoreBluetooth.framework. It is currently limited to interfacing only with BTLE (Bluetooth Low Energy) devices though. Now that iOS devices are unarguably mainstream and the iOS peripheral market has had a fair amount of time to mature and settle, it might be time for Apple to open up these ports for general license-free use by any developer. There is a huge demand for iOS compatible game controllers right now as evidenced by the 60beat GamePad, iCade, iControlPad and Atari Arcade. It would be really interesting to see what kinds of great controller options would come out of the woodwork if it were more economically attractive to develop iOS hardware peripherals. This kind of freedom for the communications ports would be extremely convenient in conjunction with my next prediction…


UPDATE: For a while there during the iOS 6 beta it looked as though this one might actually come to pass. With iOS 6 came the integration of the External Accessory Framework into the iOS SDK. This is the framework that participants in the expensive “Made For iPod” (MFi) program would use to interact with their 30-pin or Bluetooth devices. The fact that it was being pulled into the mainline SDK was an indicator to many (myself included) that Apple was finally going to ditch the need for encryption and open their hardware interfaces up to the masses (the fact that BTLE and the CoreBluetooth.framework had no such requirement was further evidence in support of this assertion). Alas, on further investigation it appears that this was not the case. By all accounts you still need to sign up for the MFi program, pay a large licensing fee and buy expensive encryption chips if you want to use < Bluetooth 4.0, the 30-pin port or the new Lightning connector. Fortunately as time marches onward Bluetooth 4.0 will become move prevalent and the BTLE chips will lower in price thus further lessening Apple's need to opening up these 'legacy' ports. (Miss)  75%

Apple TV SDK

Apple pretty much fell into the Gaming industry by complete accident. Nobody, not even Apple themselves could have foreseen the kind of massive takeover of iOS devices in the portable market, especially because they weren’t even trying to attack that market in the first place. The Apple TV has long been publicly declared as a “hobby” for Apple and long been looked at suspiciously as a Trojan Horse by analysts and pundits for…something…. The reason it currently exists is to get the iTunes Music and Movie Stores into your living room. Why not the App Store as well?

Granted, there are significant development challenges for developers in porting apps to the Apple TV, such as dealing with one more UI idiom in addition to the phone and pad ones they have to target right now. Developers would obviously have to live without multi-touch, accelerometer and microphone input (if targeting the Apple TV 2, rumors suggest that the Apple TV 3 may headline Siri as a feature). They would also need to deal with potentially small storage space (8GB for the Apple TV 2). The iOS developer community has proven itself to be a very quick responder to new hardware and has great feature adoption rates, as evidenced by the second app gold rush sparked by the original iPad. Obvious applications would include games (duh), more applications that blur the line between books and movies, home automation/security app ports and data visualization software hooked up to analytics services and the like (it seems like every other startup office I visit these days has a computer in a public place hooked up to some data visualization of sales or hits or something). The sheer financial incentives that accompany a high position in the App Store sales charts all but guarantee massive developer adoption of any potential future Apple TV SDK. One can speculate as to whether Apple will maintain a separate iOS branch just for the Apple TV as it currently does and later unify it (much like it did with the iPad), or if it is going to be merged in with iOS 6 right out of the gate. Again, I don’t think Apple is going to initially position the Apple TV as a gaming console (it can’t compete with the horsepower of the entrenched players at the moment), but one shouldn’t underestimate the power of yearly hardware upgrades and a voracious and resourceful developer community. Should the Xbox, Playstation and Wii start getting worried?


UPDATE: I guess that iOS 6 was not necessarily the right place for an Apple TV SDK to debut. After all, the iPad and iPhone versions of iOS were disjoint for almost a year before they merged. It does make a measure of sense for Apple to simplify and just concentrate on mainline iOS and then afterward work on pushing out a refined Apple TV SDK during a normally dry spell for Apple releases in the coming year. Once again, this is just money on the table for Apple. Thousands of iOS developers are clamoring to port their games and other apps over to the Apple TV. I still believe this is coming but I am now less certain on the timeframe.

(Miss)  70%

AirPlay Mirroring Plus

The collection of technologies and protocols now dubbed “AirPlay” has had quite an interesting technical history. First there was AirTunes, with which you could send encrypted audio to authorized devices like the AirPort Express from iTunes. Then came a separate technology called AirPlay Video, which allows iTunes and iOS devices to send unencrypted video/audio to the Apple TV 2. Then last summer we got AirPlay Mirroring, which is yet another additional, separate technology that sends encrypted video/audio of whatever is on iOS device to the Apple TV 2.

AirPlay Mirroring has had a huge impact on presentation technology (I use it at an event I founded called the Startup Grind). It has even more unlocked potential as clearly evidenced by existence of Reflection and AirParrot and by the recently revealed AirPlay Mirroring capability in OS X Mountain Lion. I predict that at some point Apple will add iOS-iOS device mirroring capabilities as well. The idea of sharing your device screen with somebody else near you doesn’t seem extremely interesting until you add something like multicasting into the mix. Imagine a conference talk or a board meeting where the speaker uses their iPad to show the audience slides or some other sort of demonstration, and instead of cranking your neck over to get a glimpse of a poorly lit, off angle projection screen, you simply follow along on your own iPad. This seems like a no-brainer considering all Apple has to do is port the AirPlay mirroring receiver app over over to mainline iOS from the Apple TV 2 and add multicasting support. Now that the AirPlay Mirroring private key has been extracted and the protocol reverse engineered, if Apple doesn’t do it, some other enterprising developer will.


UPDATE: This did not happen. In fact, no AirPlay Mirroring enhancements came at all! If Apple hasn’t foreseen the possibilities for more flexible mirroring or hasn’t seen fit to give mirroring any enhancements of any kind then I am not so sure that it is going to arrive in the future either. I am not going to hold my breath for this one now but hope to eventually be pleasantly surprised.

(Split)  70%

Mobile Payments

The NFC rumor got a lot of play last year when people threw around iPhone 5 predictions, but we haven’t really heard much from it lately. NFC/RFID reading hardware in phones has had somewhat of a hard time gaining adoption despite a lot of press and attention put on its potential uses. In the United States there are only a handful of Android phones currently sporting NFC/RFID hardware at the moment, which is somewhat surprising considering that Android handset makers are constantly looking for ways to distinguish themselves. Google seems to be making a fairly large play for the use of the technology in payments although adoption doesn’t appear to be significant right now.

It appears that Apple is going to throw their weight behind BTLE for the kinds of things that NFC is typically used for. They are already shipping BTLE hardware in the iPhone 4S and, as mentioned above, they have already provided the CoreBluetooth API for it in iOS 5. Apple could potentially “just walk in” to the payments ball game with two gigantic assets already in place. First, they have a huge guaranteed, uniform hardware install base to entice developers and partners and secondly, there are hundreds of millions of credit card accounts in iTunes already hooked up and primed to go. The payments-in-real-life arena seems ripe for disruption as evidenced by the success of such players as Square and the seemingly uncompetitive entrenchment of the few large credit card companies in the US. It only remains to be seen if Apple is even interested in this space at all. Time and time again they have proven that they aren’t going to just jump into the latest buzzword market simply because it is the hot thing right now. That said, mobile payments married to iTunes/iOS seem to make a lot of sense to me, and enough time has passed for Apple to be able to calmly evaluate the arena with a cool head and develop a consistent plan.


UPDATE: Depending on how you interpret the verbiage you could call my prediction either a hit or a miss. I am going to take half credit for this one. Passbook is clearly Apple’s alternative to making a physical swipe or moving your device so that it is proximate to a sensor in order to get something accomplished. It is being used for tickets, coupons, boarding passes and all sorts of other things that people envisioned NFC to be suited for. Clearly Passbook is much less secure than having an end-to-end cryptographically-based system but it also has much less friction to adoption and much better hardware support. With that in mind, in regards to functionality I am going to call my prediction a ‘hit‘. However, because you can’t use it to actually perform a financial transaction and my prediction was much more closely tied with the particulars of the hardware implementation I am going to have to also call my prediction a ‘miss‘.

UPDATE: iOS 8 now brings us Apple Pay. Through NFC no less.

What Won’t be Coming:

Here are some things I think would be great if they made it into iOS 6 but I wouldn’t put any money on it:

(Hit)

Game Center 3rd Party Authentication

This is something I had hoped Apple would include in their gaming social network from the get-go (a year ago I wrote about how this is the number one problem holding back Game Center adoption). For games that require accounts or some sort of establishment of identity, being able to develop a game that authenticates against Game Center user accounts would be a godsend. Unless you are a large development house that has already created secure user account management systems, it is a huge pain to manage users, and an even bigger pain for your customers when you ask them to do yet another song and dance through a signup process. Apple could very easily integrate a 3rd party authentication system into Game Center, but I have heard through the grapevine that there is no internal interest in doing so. Instead they have provided us with Apple-hosted turn-based gaming functionality, which alleviates some of the problems developers have had, but it has some severe limitations and doesn’t address entire swaths of game genres like realtime action games.


UPDATE: As I predicted, Game Center continues to go nowhere fast. Apple likes to tout Game Center’s account statistics during keynotes but it is all for naught if it is nothing more than an achievements system (Game Center leaderboards are meaningless because of complete lack of security). I would really love to see the day when Apple makes Game Center so attractive that game developers cannot resist developing for it. But the fact that rival services have continued to grow and prosper even after Game Center hit the scene is evidence enough that it doesn’t really offer anything special. Also Apple, get rid of the poker table aesthetic. Nobody likes it.

(Miss)

Deep Facebook Integration

By all accounts (from the rumor sites) this one almost happened. Technically there is nothing stopping it. iOS 5 already brought us deep Twitter integration and from what it looks like from the outside, most of the work was already done (see Ping etc…). Instead things got bogged down on the business side of things as they often do, and after some heavy Jobs vs. Zuckerberg meetings it appears like it was no longer meant to be. That is not to say that it can’t happen in the future, which is why some people have high hopes that it will arrive in iOS 6. I however feel that as time as passed, distances have grown instead of shrunk. These days Facebook seems to be the girl everybody wants to dance with, and it seems every day they and Microsoft continue to get cozier with each other. I wouldn’t preclude this from happening sometime in the future, but iOS 6? Too soon.

UPDATE: Well, looks like I just got this one wrong. Facebook integration at a similar level to iOS 5 Twitter integration was announced at the WWDC Keynote. By all accounts the technical work had already been completed over a year ago and it was just a matter of people on one, the other or both sides swallowing their pride and flipping the switch.


Your Predictions

What do you think? Do I have it right? Any iOS 6 predictions of your own? Let me know in the comments.

UPDATE WRAPUP: Well, it looks like my prediction hit rate (1.5/8) was pretty dismal. This isn’t going to stop me from prognosticating about future editions of iOS though. On the upside, I feel like I have just given Apple their tent-pole feature list to start working on for iOS 7. You’re welcome 🙂

4 Responses to “iOS 6 Predictions”

  1. RecessionCone Says:

    Great predictions. All of them make sense to me except Mobile Payments, which I think make no sense for Apple (or Google for that matter).

    Lots of credit cards in the US already have NFC RFID tags, like my AmEx Blue card. They started appearing in 2002, and now there are readers all over the place (McDonalds! Chevron!). But no one uses them – and most people aren’t even aware that their credit cards have NFC enabled. That’s because contactless doesn’t really solve any real problem, since swiping a credit card is already very fast and convenient. The one place NFC matters is in public transit, but in the US practically no one uses mass transit anyway, it doesn’t matter.

    NFC on a phone is even less convenient than NFC on a credit card:
    Step 1. Get phone out of pocket
    Step 2. Enter unlock code (not necessary for NFC credit card)
    Step 3. Hold phone to reader
    Step 4. Confirm purchase (how many clicks do we need for that) (not necessary for NFC credit card)

    So I think NFC will not change anything in the US if Apple adds it to their phones. Asia is a different place, and so it might make sense from a global perspective, but I’m not expecting it to be useful here.

    Beyond the physical aspects of contactless payments, the big problem that mobile payments need to solve is accessibility, since many merchants don’t take credit cards. But Square is already attacking that problem. What would Apple do that Square doesn’t already do? Additionally, what would the business model be? Apple’s traditional 30% cut is just plain not acceptable: the reason merchants don’t take credit cards today is not because it’s technically difficult, but because the ~2% fee the credit card companies charge is unacceptable given their slim margins. If Apple waded in with an expensive mobile payment system, what problem would it solve? Conversely, if Apple makes a cheap mobile payment system linked to iTunes accounts, Apple’s new liability for the vast amount of fraud it would enable would outweigh the profits they could make from hosting the system. It just doesn’t make sense in my mind.

    Summing up: Apple may still add some NFC/mobile payment infrastructure, but I don’t expect it to make any headway in the US, because it would solve no one’s problems.

  2. Joseph Says:

    Multiple user logins (not simultaneously). Not appropriate for iPhone, but really needed for a family sharing an ipad.

  3. RecessionCone Says:

    So Apple has gone ahead with NFC and a mobile payment system like you thought they would 2.5 years ago.

    I’m still not convinced it’ll work out. I think the biggest advantage to consumers is that you won’t have to carry around so many cards – but that’s only true if the NFC terminals are ubiquitous. Maybe that’ll happen someday….

  4. snielsen Says:

    I think that in time all my old predictions will come to pass. It just might take a while 🙂

    I feel like there are some other large pros to Pay such as removing custody of payment information (or other sensitive stuff) from the merchant. Imagine, no more huge Target or Home Depot credit card breaches. No more credit card skimmers at gas stations, etc…

    Also, as mentioned, this puts the hardware and information infrastructure in place to do Square-like person to person money transfer. Tim said in the keynote that they could afford to design Pay to be the best payments system for the users (both customers and merchants) and that they did not have to build in an aggressive fee structure to survive. This potentially means that Apple can undercut everybody and Pay just becomes one more subsidized, contributing factor to the Apple ecosystem and keeps you buying from Apple every two years.

    Also, (this functionality isn’t clear yet but at minimum the potential exists) there is value in a digital receipt system. Even though Apple doesn’t know what you bought, the data can still be potentially written for your own usage which I would love.

    Also interesting is the fact that Pay is also going to be an online payments system (ala Stripe?). This is also a competitive market and I haven’t quite thought about what I think of that move yet.

    All these ideas have been done before to a certain degree. Just not done with as much vertical integration and polish as with Apple. I think that with Apple behind the push, things will finally start to change but will probably take 5 to 10 years.

Leave a Reply

Entries (RSS) and Comments (RSS).