This has been quite an exciting week. Apple has introduced over 4,000 new APIs for both OSX and iOS and most developers have been raving about how the “new” Apple led by Tim Cook has changed. They claim that the company now listens more to their customers and use the fact that iOS will support custom keyboards, allow for the use of the fingerprint reader and offer inter application communication mechanisms as proof that things have changed.
Frankly, I am not convinced that much has fundamentally changed. When Apple launched their Rip, Mix and Burn campaign in 2001, they were clearly listening to what customers wanted at the time. In order to do it properly, they had to plan for their vision, which included buying the application (SoundJam MP) that would eventually become iTunes and add the capability to easily burn CDs, which took some time, but they eventually released the product they wanted.
What happened this week was similar. Apple may have wanted to offer the possibility to install alternative keyboards for a while, but it took some time to deliver the capability in a secure form. What is so dangerous about alternative keyboards? Well, imagine that the keyboard logs all your key strokes and send them to some server in Ukraine. All your passwords, credit cards numbers would be gone. So, what is needed to make sure that supporting alternate keyboards is safe? Well, one way to do that is to avoid using the keyboard to enter credentials or credit card numbers in the first place. That is something that Apple has solved by releasing iCloud keychain in iOS 7 and by opening the use of the fingerprint reader in iOS 8. The other thing to do is to forbid internet access for the keyboard app if the user chooses to do so. That was also announced by Apple as part of iOS 8. It is likely that by the time Apple releases iOS 8, all new iOS devices will include a fingerprint reader and as a result, should be well protected against malicious keyboard apps. As you can see, opening iOS to support alternative keyboards is not something totally new that came out of nowhere, it is the result of careful planning and making sure that everything is in place before launching a new feature.
Swift, the new programming language launched by Apple at WWDC is another interesting example. This new language has been in the works for about four years now. It is a modern language with a lot of new cool features, but I would hardly call it revolutionary. What is interesting about Swift is that, as far as I know, it is the first language designed from the found up to make the use of an existing library much easier. Normally, a language is designed to solve a particular problem that other existing languages cannot handle well (multi-tasking, security, etc.). However, Swift seems to be designed solely for the purpose of giving the Cocoa framework a new lease on life. By basing variable types on Cocoa objects (for example strings are NSStrings) and hiding the complexity of handling structs, Swift makes it much easier to write code for Apple platforms without impacting the huge investment made by Apple and Next on Cocoa over the last 30 years (NextStep was launched in 1989). This makes a lot of sense, because it preserves Apple’s biggest asset while giving us developers what we want. Swift is therefore in that sense evolutionary and not revolutionary. It is the result of a plan launched years ago with the adoption of the llvm compiler, and the launch of Objective-C 2.0, and if Apple is really planning on eventually moving their Macs away from Intel, applications written in Swift will make the transition transparent for application developers.
WWDC 2014 was a great event because it saw the fruition of many initiatives started by Apple years ago, not because Tim Cook just started to listen to their customers and developers but because Apple seems to be accelerating the delivery of features that result from a carefully crafted plan. The success of Apple depends on maintaining a clear long and medium term plan to deliver their vision, as they have done so far, and not on delivering a long list of short-sighted features.