March 2, 2008
UBS thinks that the 3G iPhone will be released mid-year. iLounge reports that the much-anticipated iPhone SDK will be delivered in June, at Apple’s Worldwide Developer Conference. A beta version will be released at an announcement event on March 6th.
There are several reports that Apple intends to target business users with the iPhone, competing with Blackberries, Nokia’s Eseries and Windows Mobile devices. Since the SDK reportedly will expose interfaces to the phone and Wi-Fi, developers of Wi-Fi soft-phones and enterprise Fixed-Mobile Convergence systems will presumably add iPhone support to their existing Symbian and Windows-supporting products. It remains to be seen how easy it will be for developers to actually get their software “officially” onto the iPhone. Apple can choose their degree of open-ness from a variety of options discussed here.
For Apple to aim at the business market makes a lot of sense. With the successful transition to Intel processors Macs already run Windows natively, and iPhones are supposedly making inroads among executives. According to ChangeWave, summarized here, the iPhone has a 5% share of corporate smartphones already, with astronomical ratings for satisfaction.
To make enterprise IT departments happy, though, Apple will have to make the iPhone more manageable; either by building in OMA DM like Nokia with the Eseries, or by letting third parties develop enterprise manageability clients using the iPhone SDK.
Competitors aren’t sitting still for this. The October 2007 announcement of “Microsoft System Center Mobile Device Manager” was a step forward for Windows Mobile in the enterprise. Microsoft is also leaking stories about how when Windows Mobile 7 is released in 2009 it is going to be more of a pleasure to use than the iPhone. It is conceivable, I suppose, but Microsoft’s track record on usability is pretty consistent. The fundamental part that they invariably seem to get wrong is instant response to user input.
November 7, 2007
The genesis of the Google phone project is described in this Boston Globe article by Scott Kirsner.
The Open Handset Alliance will release its SDK on November 12th, 2007. The iPhone SDK will not be released until four months later. Microsoft and Symbian already have not only mature SDKs, but vigorous development communities: in mid-2007 Windows Mobile had 650 thousand registered developers, and Forum Nokia had 2 million registered individuals and 440 companies in its “Platinum Program.”
As usual with a new development environment, it’s a chicken and egg situation, but the chicken is coming out in pretty good shape; if the base platform debuts with comparable functionality to what the iPhone came out with, it’s a low-risk proposition for the phone OEMs, and Google’s magic coattails will ensure hysterical enthusiasm in the developer community.
November 6, 2007
The Open Handset Alliance was announced today by Google and 30 or so other companies. Until now the highest-profile open source handset operating environment was OpenMoko.
The list of participants has no real surprises in it. Nokia isn’t on the list, most likely because this project competes head on with Symbian. This may also help to explain why Sony Ericsson isn’t a supporter yet, either. But the other three of the top five handset manufacturers are members: Motorola, Samsung and LG. All of these ship Symbian-based phones, but they also ship Windows based phones, so they are already pursuing an OS-agnostic strategy. Open standards are less helpful to a market leader than to its competitors.
Of course the other leading smartphone OS vendors are also missing from the list: Microsoft, Apple, Palm and RIM.
Ebay is there because this massively benefits Skype.
Silicon vendors retain more control of their destiny when there is a competitive software community, so it makes sense that TI is aboard even though it is the market leader in cellphone chips. Intel is another chip vendor that is a member. Intel can normally be relied on to support this type of open platform initiative, and although Intel sold its handset-related businesses in 2006, its low power CPU efforts may evolve from ultra-mobile PCs down to smartphones in a few years.
Among MNOs Verizon and AT&T Mobile are notorious for their walled-garden policies, so it makes sense that they aren’t on the list, though Sprint and T-Mobile are, which is an encouraging indication.
At the launch of the iPhone Steve Jobs said that the reason there would be no SDK for the iPhone was that AT&T didn’t want their network brought down by a rogue application. I ridiculed this excuse in an Internet Telephony column. Even so, the carriers do have a valid objection to completely open platforms: their subscribers will call them for support when the phone crashes. For this reason, applications that use sensitive APIs in Symbian must be “Symbian signed.” When he announced the iPhone SDK, Steve Jobs alluded to this as a model that Apple may follow.
So Sprint’s and T-Mobile’s participation in this initiative is very interesting. Sprint’s press release says:
Unlike other wireless carriers, Sprint allows data users to freely browse the Internet outside its portal and has done so since first offering access to the Internet on its phones in 2001.
Open Internet access is actually available from all the major US MNOs other than Verizon; AT&T ships the best handset for this, the iPhone. But the iPhone doesn’t (officially) let users load whatever software they want onto the phone. Symbian and Windows-based phones generally do, and again all the major MNOs ship handsets based on these operating systems. An open source handset goes a big step further, but who benefits depends on what parts of the source code are published, and what APIs are exposed by the proprietary parts of the system. As a rule of thumb, one would think that giving developers this greater degree of control over the system will increase their scope for innovation.
June 12, 2007
Reuters carried a story yesterday from the Apple World-Wide Developer Conference in San Francisco. The headline is “Apple to let outsiders create programs for iPhone,” and the story says “Apple Inc. will allow independent developers to write applications for its upcoming iPhone by tapping into the device’s built-in Web browser.” The story was presumably based on Apple’s press release on the topic.
This sounds exciting, so why did Apple stock lose $4.30 on the day? Well, the market focused on the glass-half-empty. Apple didn’t open the iPhone up to third party developers in the way that most developers want. The comment that squelched the crowd was “there’s no SDK!” The official version, what Jobs, Forstall and the press release said beyond that, is too scant and ambiguous to draw a clear idea of how well developers will be able to exploit the iPhone as a platform. Here’s a link to the video of the Jobs keynote. The iPhone developer part starts at time index 1:14. Ryan Block of Engadget was there live-blogging the Jobs keynote. His transcription and commentary:
Jobs: “We have been trying to come up with a solution to expand the capabilities of the iPhone so developers can write great apps for it, but keep the iPhone secure. And we’ve come up with a very. Sweet. Solution. Let me tell you about it. An innovative new way to create applications for mobile devices… it’s all based on the fact that we have the full Safari engine in the iPhone. And so you can write amazing Web 2.0 and AJAX apps that look and behave exactly like apps on the iPhone, and these apps can integrate perfectly with iPhone services. They can make a call, check email, look up a location on Gmaps… don’t worry about distribution, just put ‘em on an internet server. They’re easy to update, just update it on your server. They’re secure, and they run securely sandboxed on the iPhone. And guess what, there’s no SDK you need! You’ve got everything you need if you can write modern web apps…”
Block: “Weeeeeaaaak.”
Scott Forstall, VP of iPhone software: “Your applications can take advantage of the built-in native services.”
Block: “He’s in the iPhone — no new apps up on screen, the same 11 as before — sorry iPhone fans!”
Forstall: “We built a custom corporate address book app to use our internal LDAP… it actually took less than one person-month to do this. It’s under 600 lines of code to do the whole thing.”
Block: “Shows up the vCards as they look in the built-in contact app. Not too shabby!”
The Web 2.0/AJAX model is great for AT&T, because this model requires continuous interaction with the server, so you will be burning up your data minutes. Except, I hope, when you are at home or at work and can use the Wi-Fi connection.
This is, as Block says, weak compared to loading real OSX applications on the phone. How weak depends on what Steve Jobs means by “the full Safari engine.” Apple’s Safari FAQ page says “All versions of Safari support Netscape-style plug-ins.” This undoubtedly applies to the iPhone version of Safari, since Steve Jobs has been toying with the idea of including Flash. The published Safari plugin SDK isn’t any use to iPhone developers, since the CPU is an ARM. So if Apple doesn’t publish an iPhone SDK, even the Safari plugin support is moot to third parties, except those working closely with Apple, like Google. One obvious Google plugin that would reduce the sting of no SDK would be Google Gears, which lets you run server-based applications off-line. The usual example is Google’s complete suite of Office applications.
From the overall context it appears that there is a JavaScript API to control some elements of the iPhone subsystem. That could be cool, depending how capable the API is. As for documentation of the API, a check of the Apple Developer website doesn’t reveal anything of that nature yet. There was a session at WWDC called “Developing Web Sites for iPhone,” which may have had some related information.
Blog reaction has been hysterical (but when has it ever not been?) Jesus Diaz of Gizmodo says No iPhone SDK Means No Killer iPhone Apps. One interesting tidbit in his piece concerns the degree of integration with the the iPhone’s services. Here’s what he says about clicking on a phone number in the browser to place a call:
This is nothing new, however. We knew this from the very beginning because iPhone’s Safari was already doing it. It’s called auto-detection of phone numbers and addresses: you click on a phone or address in your web page and it gets passed by Safari to the operating system, which calls the number or shows the address in the Google Maps app.
I certainly hope this isn’t the extent of it. If so, this guy is right. Nothing special here at all.
We live in hope, though. Steve Jobs was accurate in saying that Web 2.0/AJAX programming is the hot new thing, and that highly capable applications (especially enterprise applications) are being built like this. Users don’t care how software is written, they just want it to perform a useful function in a responsive and considerate way. If the API is rich enough, popular opinion will follow the trail that Ryan Block blazed, from “Weeeeeaaaak” to “Not too shabby!”
May 18, 2007
Parvesh Sethi is Cisco’s Vice President, Advanced Services. In his keynote at the Communications Developer Conference this week in Santa Clara, he described an interesting use case for future wireless devices:
Your phone automatically notifies the hotel when you arrive - no need to stand in line to check in. Your assigned room number appears on your phone screen. The phone acts as a wireless key for your room. In your room the hotel puts targeted ads onto your phone’s screen.
The bulk of his talk consisted of advice for developers. The two main themes were “leverage the power of the network” and “exploit the long tail.”
The power of the network bit is to be expected from Cisco. The long tail part was a theme at many of the other presentations in the conference. For those who haven’t read the book, the idea is that the enormous reach of the web at relatively minuscule cost allows products that in the past would have been too narrow in appeal now to be commercially viable, and when combined with enough other low-volume products, to be lucrative. For example, a book that sells two copies a month isn’t worth carrying in a retail bookshop. But an online bookstore with a hundred thousand such titles would glean annual revenues in the tens of millions of dollars.
Sethi explained that custom programming for a particular enterprise used to be prohibitively expensive. But now the Web is packed with useful components that you can invoke through simple APIs. Web development environments automatically take care of the hard stuff for you, stuff like security, transcoding, QoS, authentication. Application acceleration is available right in the network. The open application development environment makes it possible for people to add their own value. This unleashes the long tail effect for the component vendors.
The example Sethi gave for this type of application was a real-world one, from an individual Subway franchisee - not Subway Corporate. The application runs on a Cisco phone. When an employee arrives in the morning, he logs in on the phone. This means no need for a time clock. Suppose four employees are scheduled to work a shift, but only three clock in. Previously one would have to start calling to find a substitute, leaving only two to perform the work. Now the phone system starts outdialing automatically, calling down the list of substitutes until one responds with a touchtone. Meanwhile, back in the store, the phone reminds the employees about essential process steps, like putting the bread in the oven. If the employee doesn’t acknowledge that he has done it, the system calls the supervisor to snitch. Sethi claimed that this application yielded a 30% increase in lunchtime revenue in its first month of operation.
Openness of the development environment, the ability for users to modify Cisco’s system and incorporate it into applications built on a whole set of such open components was one of four “Pillars of UC development” that Sethi identified. The other three were security, simplicity and virtuality (access to the application via any device, any where).