July 23, 2008 | Comments: (0)
Apple's iPhone contracts leave developers speechless
Apple apparently chose the best possible template for its iPhone developer programs: its own Apple Developer Connection for OS X. Why it then made the iPhone SDK confidential even for those who download it for free poses a puzzling contradiction in the company's seemingly open approach to development.
The basic ADC membership is open to everyone and free of charge. All you need is a verifiable (at least temporarily) e-mail address to obtain a free Apple ID. Free and paying ADC members get exactly the same commercial-grade development tools, samples, and docs. Depending on their membership level, paying members get additional access to pre-release software, prepaid tech support incidents, hardware discounts, and WWDC tickets. Free members face no disadvantages when it comes to creating and distributing applications for the current or prior release of OS X. That cornerstone of the Mac platform accounts for its large catalog of high-quality free and inexpensive applications, as well as its loyal and welcoming community of developers. ADC is the magnet that draws developers to the Mac from other platforms.
By choosing ADC's tiered programs as a model, it seemed that Apple had tilled the field for an instant and vibrant iPhone dev community. Then it salted the ground by making the iPhone SDK confidential even for those who download it for free. The upshot is that every citizen of planet earth can get the iPhone SDK at no charge, but they're contractually obligated to Apple not to discuss the SDK or exchange ideas with others. The agreements leave no room for forums, newsgroups, open source projects, tutorials, magazine articles, users' groups, or books.
The terms and conditions of the most restrictive Agreements to which all iPhone developers are bound are secret. A few sentences from the nonconfidential iPhone Registered Developer Agreement (PDF) are sufficient to illustrate the breadth and severity of the restrictions. As is always the case, you must not rely on my excerpts or analysis as a summary of the Agreement or as legal advice.
From Section 3, Confidentiality: "You agree not to disclose, publish, or disseminate any Confidential Information to anyone other than to other Registered iPhone Developers who are employees and contractors working for the same entity as you and then only to the extent that Apple does not otherwise prohibit such disclosure in this Agreement."
What's "Confidential Information"? The Agreement contains two definitions, one in Section 3 that's broad and rambling but with specific and liberal exceptions, and one in Section 4 that's concise and inescapable:
From Section 4, iPhone Materials: "All iPhone Materials shall be considered the Confidential Information of Apple"
Section 4 also makes unrestricted allowance for additional tightening of screws (not quoted in full): "All use of the iPhone Materials shall be subject to this Agreement, unless such iPhone Materials are accompanied by a separate license agreement, notice or disclaimer (collectively, "Other Agreement") in which case such Other Agreement will govern to the extent of any inconsistencies with this Agreement [...]"
There are two Other Agreements (the secret ones): one that governs free use of the SDK and the other, responsibilities of iPhone Developer Program members. I have no problems with the latter. When money gets involved, that changes the rules, and Developer Program members have access to trade secrets. My problem is that Apple brands publicly available information -- that is, the released and freely downloadable iPhone SDK -- as confidential. Laypeople who are ill equipped to interpret the secret Agreement attached to the free iPhone SDK are likely to assent to it without reading it, if they're aware that it applies to them at all.
I can't discuss the secret SDK Agreement, but you can read it for yourself by signing up as an iPhone Registered Developer.
This isn't Apple-bashing. This is serious business. You'll see arguments from armchair legal analysts that the iPhone developer Agreements won't stand up in court -– but those analysts certainly won't stand up in court on your behalf. When you download the SDK, you grant Apple special rights to injunctions and suits against you for unspecified damages in addition to their rights under the law.
The iPhone developer Agreements covering the freely accessible iPhone SDK are not EULAs that you can blindly click to sign without study. It turns out that the iPhone developer programs are the antithesis of the developer-friendly Apple Developer Connection. The iPhone Agreements are risk-laden contracts that make the iPhone SDK one of the most dangerous downloads on the Internet. It is certainly the most heavily encumbered free software I've encountered.
If you're planning a forum, newsgroup, users' group, open source project, book, or any discussion of iPhone development, the only path to protection from liability is explicit written approval from someone at Apple. Have a lawyer draft your request for exemption, and make sure that the Apple staffer granting it personally commits to status as authorized to approve exceptions to the iPhone Registered Developer and iPhone SDK Agreements.
The concerns I have expressed relate only to free access to the SDK. Terms of the paid iPhone Developer Program are appropriately confidential, and in my view, Apple offers paying individual developers a generous balance between benefits and responsibilities. This said, shutting the door to all opportunities for discussion of the freely available iPhone SDK hurts all iPhone developers.
Posted by Tom Yager on July 23, 2008 03:00 AM
June 10, 2008 | Comments: (0)
Can anything beat iPhone? Handset makers, here's how.
One of my live blog entries from the keynote at Apple's Worldwide Developer Conference had a one-line body:
iPhone competitors, it's over.
It doesn't excite me to say that. I don't like seeing any one player rise to lord of the realm. At least theoretically, a cornered market isn't good for buyers. But make no mistake, Apple entered the mobile market to corner it, and at this moment it's largely unopposed. If you wonder how Apple got there so fast, consider the zeitgeist that Apple tapped: Most wireless customers are sick of their wireless carriers. After years of overbilling, lousy support, spotty coverage, being locked out of bargain rate plans available only to new customers, and worst of all, being stuck with carriers' anemic hand-picked catalogs of devices, customers wish wireless carriers would just go away.
[ Get the full scoop on Apple's mobile empire-in-the-making in his Enterprise Mac blog's deep dive essay. ]
That's what Apple did. iPhone makes wireless carriers go away. At first, carriers went through the motions of negotiating with Apple to retain ownership of subscribers. But then a funny thing happened. The most possessive of all carriers, AT&T, discovered that it doesn't really like taking care of customers (surprise!). iPhone gives AT&T the benefits of customer ownership -- rate plan lock-in and term contracts -- with none of the hassle of support, advertising, or plan competition. Word got out that AT&T likes it, and Apple quickly knocked over carriers worldwide with its simple "lean back and get paid" plan.
At least in North America, wireless carriers are completely helpless when it comes to services. They all spend fortunes trying to create mobile Internet and media services so appealing that they'll lure people away from other carriers. Apple tells carriers that for just one model of phone, they can skip trying to cobble together a bundle of carrier-unique services.
U.S. customers may dislike AT&T (hand goes up), but if you have an iPhone, you will never have to speak to them. Apple gives AT&T permission to send you a flat rate bill, with the only allowed unit charges being for text messages. The rate plan is expensive, but there is no fine print. Consider that $15 per month premium as insurance against getting screwed by your carrier. You're also paying for Apple's help desk, which is shockingly helpful.
If a handset maker came to me looking for advice on competing with iPhone, I'd offer a place to start. Break wireless carriers' blockade on handsets. Release new handsets worldwide, simultaneously, and offer them in North America free of carrier locks and subsidies. Opt out of the charade that carriers have to validate individual devices on their networks before allowing users to buy them. With high-end handsets, customers will welcome the freedom to choose the handset first and the carrier second. Carrier and device choice will be powerful competitive weapons.
Don't be so price-sensitive about your handsets. People will pay $399 or $499 for a feature-rich handset for the privilege of owning it free and clear. Buyers in that price range understand that term contract subsidies are a rip-off.
Get your developer program act together. If you can't create the tools and the community you need to build the kind of vital third-party mobile app market that Apple is constructing for iPhone, find and fund some champions in the open source realm. Get devices out to developers; even refurbs would be welcome. Most mobile developers don't have enough devices against which to validate their code.
Expose the advantages of your platform at a high level. For example, iPhone does not have the ability to run simultaneous applications or to open arbitrary TCP or UDP sockets over a wireless connection. Consider the applications that these limitations make impossible, and show that your platform makes them available.
Get aggressive about firmware updates, and unify them so that one image updates a large category of devices. The industry's habit of making customers buy new devices to get the latest functionality is wrong-headed. Here, too, handset makers should do an end-run around carriers and push updates directly to customers.
Where support is concerned, handset makers should give customers a place to meet and help each other. If one already exists, get your people involved. Assign support tickets and refer to those tickets in release notes for new firmware and tools so that customers see that they're making change happen.
The lowest-hanging fruit for iPhone competitors is savvy, self-sufficient users of high-end handsets and the developers who want to code for those users. That's not the whole roadmap, but it's a place to start. Believe me, the market is waiting.
Posted by Tom Yager on June 10, 2008 02:06 PM
April 16, 2008 | Comments: (0)
Several months ago, I determined that my years-long fondness required reexamination. I quietly took a break from the Mac to get some perspective, to check out Vista, AMD, and Longhorn (Windows Server 2008) untainted by Apple's PR and uninfluenced by other journalists and bloggers. I elected to take a break from reviews of new Mac hardware, the occasion of which always piques my interest in Apple's platform. There were times when I felt I'd chosen the worst possible time for this hiatus. I ended up passing on MacBook Air, Time Capsule, Harpertown Mac Pro, and most painful of all, the new MacBook Pro. It was difficult seeing InfoWorld pick up reviews of these from sister publications, but I take my responsibility to readers very seriously. I can't very well counsel you on technology choices if I consider the field limited to one worthwhile player, especially when that player projects the image that it competes only with the generation of systems that preceded what's presently sold.
I found enormous value in my time away from Mac. I made the kind of discoveries I used to make routinely before I took on the Mac as a specialty, and as I take up the Mac again -- which I am doing immediately -- it's clear that my appreciation for the platform is justified, and that the customary split of my effort and attention between Apple and AMD is justified.
The genuine, practical superiority of AMD's Barcelona server platform, and its Phenom desktop platforms that derived from Barcelona, came to light during the break I took from Mac. A one-socket, quad-core Spider (Phenom plus ATI CrossFire graphics) runs Vista so obscenely fast that even a die-hard Mac user's head will turn. Privately, of course.
I found it extremely intriguing that systems built on Phenom platforms can tune themselves autonomously for the maximum possible CPU and GPU speed over a surprisingly broad range, based on a whole system approach that takes cooling, power supply capacity, and your preferences for noise and maximum power consumption into account. I found that I could speed bump an AMD Phenom desktop for free by moving it closer to the floor, where the cooler air prevails. What a grand idea that in itself shows genuine customer-focused insight.
I gained a fresh appreciation for the GNU compiler collection, which has taken remarkable strides since I last took a deep dive in it. I was unaware of the level of engagement from commercial partners, including Apple, AMD, and Novell. Each is undoubtedly pursuing its own agenda, but it does so within the framework and culture of one of the most tightly controlled and liberally licensed open source projects in existence. AMD has finally embarked on the long road to compiler parity with Intel with its contribution of Family 10 (Barcelona/Phenom) architecture-specific optimizations to GNU.
Apple has been busy on the gcc front as well. Objective-C 2.0, with its desperately needed garbage collection, has been a reality in the GNU toolchain since Xcode 3 was in nondisclosure beta. In release 4.2 of gcc, auto-parallelization joins auto-vectorization to adapt projects to multiprocessing and vector acceleration without developer intervention. Unless I'm mistaken, the public beta versions of the iPhone SDK, now at Beta 3, mark Apple's first swing at Microsoft-style free public distribution of pre-release dev tools. The privilege of early access has been reserved for paid members of Apple's Developer Connection programs. That iPhone SDK carries all of the latest GUI tools, documentation, and GNU command-line compilers, including Fortran, into Apple's default distribution. Hit Apple's iPhone Dev Center and scroll to the bottom of the page for the download link. You do not need to pay the $99 fee to register as an iPhone developer to use the new tools, which compile applications for Leopard as well as iPhone.
Apple is getting ever more daring in its engagement with open source in other ways. WebKit, the fast HTML/CSS/SVG rendering and JavaScript engine used in Safari, has caught on like wildfire outside Apple, and why not? To get a commercial browser, loaded with current and emerging standards, free and open for incorporation in your software, is the stuff of fantasy, and Apple holds virtually nothing back. The WebKit project is not strictly Apple's. It enjoys broad community engagement, but it is worked as a priority by Apple's staff, even to the benefit of direct competitors. For example, the browser on Nokia's E-series phones is WebKit-based, and this is not the only example where Apple effectively put its staff and technology to work for the benefit of a competitor. The GNU toolchain's adaptability to multiple embedded platforms will see WebKit in everything from phones to toys, starting with iPhone and iPod Touch. Now that WebKit has been accepted into Google's Summer of Code, I can't wait to see what innovation comes from that gathering. I plan to ply the most influential attendees with the libations of their choice and get their take on where development is headed.
Apple pushed the source code for the publicly exposed innards of OS X Leopard, known as Darwin 9, out for public download on MacOS Forge. Every time it does that, I imagine the move preceded by arguments inside the office about the effort and risks that such a program visits on Apple's platform business. The work of preparing a project of Darwin's size for public distribution is inestimable, and Apple deserves credit for putting it on the agenda of its top OS engineers and project leaders.
I love the conservative approach that Apple is taking with iPhone, especially with regard to multiprocessing. iPhone applications need to launch and quit instantly, yet relaunch after the first execution, having cached and persisted their closing state in detail. It's a freeze/thaw model of state persistence that I'd like to see extended to applications in general. Apple's Xcode has Instruments (prior: xRay), a tool that jams electrodes into your program's and the system's running environment. It records and charts statistical data at runtime along several axes for later examination. It's the most effective means of hand-tuning code for efficiency that I've ever used, and it shows the benefits of persistence quite plainly.
Taking a break from Mac hardware gave me a chance to drink more deeply of the software that Apple maintains off its beaten path. MacPorts and Apple's validated versions of open source projects are open source treasure troves stuffed with some 5,000 free applications tuned and packaged for Intel and PowerPC Macs. Digging through these repositories is so addicting that I had to issue myself an edict to get back to work, which I shall do, newly confident in my mission and purpose. I'm a Macophile for good reason.
Posted by Tom Yager on April 16, 2008 03:00 AM
March 19, 2008 | Comments: (0)
Apple's market power derives not merely from its technology, but from its adeptness at reframing a familiar market to limit the field of competitors. In the most extreme example, Apple portrays its sole competitor as itself. The competitive messaging around MacBook Pro emphasized how it skunked PowerPC notebooks in performance. Later, Core 2 Duo MacBook Pro was sold as far superior to Core Duo MacBook Pro. Apple is 2X faster than Apple, so clearly, the smart money's on Apple.
At the press conference at which iPhone's Exchange Server connectivity and software development kit (SDK) were unveiled, Steve Jobs established and reinforced the premise that in eight months, iPhone redefined the entire smartphone market. Windows Mobile and Symbian Series 60 are now irrelevant, leaving only two relevant players, iPhone and BlackBerry. Given that BlackBerry is old, tacky, and unreliable, enterprises oughtn't waste time trying to prop it up. Out with the old, in with the new.
[ Enterprise handsets are a special breed. See "Supersmart phones for extreme mobility" and "iPhone: The $1,975 iPod" ]
This mirrors the swipes that Apple used to take at Microsoft. They're always delivered with the Jobsian wink and smirk, but they are far from the offhand remarks they're packaged to be. They're very carefully targeted. In BlackBerry's case, Jobs took the opportunity to reveal some little-known information about BlackBerry -- widely published, just not the kind of details that BlackBerry users care about -- and portray it as a powerful disadvantage that makes the fresh technology that iPhone brings to the market a necessity. I grant that iPhone outshines BlackBerry as a platform for graphical mobile applications, with the drawback being that writing iPhone software for your personal use will cost you $99 (BlackBerry, Nokia, and Microsoft impose no charges). I think that Apple could have made more hay by showing a text-based custom BlackBerry app next to the same application done in Technicolor and full motion on iPhone. Instead, Apple focused its battle with BlackBerry on two simple points: BlackBerry handsets are ugly, and BlackBerry's network is old fashioned, insecure, and unreliable.
I'll grant you, my BlackBerry 8820 is industrial in its styling. That was my choice. BlackBerry handsets are now in all sizes and colors, with the bonus that every model has matching messaging functionality. Consumers and fashion-conscious professionals have swarmed to Curve, BlackBerry's jazzy QWERTY handset, and more compact phone-like devices that have the same standard BlackBerry messaging capabilities. No BlackBerry's screen is as large as iPhone's, but iPhone's visible display space is cut considerably when the huge on-screen keyboard slides in. A BlackBerry squeezes more text onto its smaller screen, and both fonts and font sizes are adjustable to match your vision.
Every BlackBerry is operable with one hand, or if you use the in-handset voice dialing, no hands. Built-in GPS is there if you want it, with Google Maps and BlackBerry's own excellent mapping software showing you where you are and where you're going. Upgrade to the inexpensive and platform-defining TeleNav, and you'll find out why I can't leave home without its turn by turn directions called out by street name. My BlackBerry 8820's battery lasts forever compared to iPhone's. BlackBerry comes with a holster. BlackBerry handsets are available from all major U.S. carriers, and they're subsidized. Even AT&T will amortize the cost of your BlackBerry device in return for a two year contract commitment. With iPhone, your two year contract commitment gets you list price, and you can shop around and pick any operator you like as long as it's AT&T.
Apple's favorite way to pin the gray beard on the BlackBerry is to point out that it uses indirect delivery. All messages, regardless of their origin or destination, are routed through BlackBerry's proprietary network. Every message makes a stop at Research In Motion's network operations center in Canada (Jobs: "It's not even in this country!") before being sent to a handset or mail server. In contrast, Apple and AT&T give you a direct TCP/IP connection between an employee's iPhone and your company's Exchange Server. Jobs wonders why BlackBerry users aren't concerned about security, given that all messages are gathered on a central group of servers, a single point of failure, where unencrypted messages sit naked and vulnerable to anyone roaming around the BlackBerry NOC. Can Americans really trust those nosy Canadians with our sensitive e-mail?
It's funny that Apple, fronting for AT&T, points to the privacy risks of shuttling communications across the border. Aren't there some hearings on Capitol Hill about warrantless something or other, and pleas for legal protection of telecommunications companies that too eagerly spilled the beans on subscribers? Security begins at home, eh?
The bulk of the e-mail traffic coursing around the Internet right now is in plain text. What Apple sells as a direct connection from iPhone to Exchange Server is anything but direct. It hopscotches through router after router. When you send a message from your iPhone, the path it follows takes it through AT&T's bandwidth-limited EDGE network, through countless intermediate routers, to your Internet provider's router to Exchange Server. If a message makes it through that gauntlet before a TCP timeout, it's home free. There are literally thousands of places where it can go wrong, not least of which is within your walls. You might have heard or said "Exchange is down" a time or two in your career. No iPhone in your enterprise can talk to any other iPhone unless your Exchange Server is up.
There is a method to BlackBerry's old-fashioned way. BlackBerry's network, which is a cooperative fabric woven by wireless operators in concert with Research In Motion, is geared for guaranteed delivery, so the burden for this is shifted from you. A message from a BlackBerry, or a competing handset equipped with BlackBerry Connect (free to any manufacturer who wants it) only needs to make it to your wireless operator. Equipment placed there by RIM routes the message straight to the BlackBerry NOC without queuing up behind browsers and music downloads. If a BlackBerry message can't make it to Exchange, it hovers in the NOC until Exchange is ready to grab it. If a message bound for a handset doesn't go through because an EDGE connection can't be made for whatever reason, BlackBerry's NOC waits for a presence notification from an operator. The instant that the NOC has a clear shot at your handset, however fleeting the trees and tunnels make it, RIM makes the most of it.
There are some facts stated by Steve Jobs that were flat wrong. He said that to use BlackBerry, an enterprise needs to have Exchange Server and BlackBerry Enterprise Server (BES). An enterprise can use BES with either Exchange or Notes. There are numerous providers that sell well-managed, off-site hosting of BES/Exchange. Unlike your iPhone, your BlackBerry can get true push e-mail from OS X Server. Configure the Postfix mail server to copy all inbound messages destined for a given user to that user's BlackBerry Internet Service (BIS) e-mail address. Every BlackBerry user gets one, and an e-mail message delivered to a BIS address hits the handset immediately, with no polling delay. Not that I have anything against Microsoft, but I'm not going trade my gorgeous eight-core Xserve for a Windows Server 2003 box just so I can get push e-mail on an iPhone.
Read winks and elbow jabs in here as you choose. I'm not ragging on iPhone. I'm looking forward to iPhone becoming the alternative to BlackBerry that Jobs envisions. But even from the lips of Steve Jobs, saying doesn't make it so.
Posted by Tom Yager on March 19, 2008 03:00 AM
March 12, 2008 | Comments: (0)
Apple iPhone SDK upends mobile market
Eight months ago, Apple was a nonplayer in the mobile space. Now, according to Apple, iPhone is the second most popular smartphone solution after BlackBerry. With all the hoopla he raised over iPhone at launch time, it's as if Steve Jobs saw this coming.
What he admits he didn't see coming was the market's reaction to the lack of a software development kit (SDK) that would support third-party apps on iPhone. iPhone is the only smartphone platform without custom application support, and that fact locked Apple out of the fleet sales that are RIM's bread and butter. It also disenfranchised the Mac developers who put Mac on the map and keep it there with, wouldn't you know it, native applications. I have weighed in on the subject of an iPhone SDK for native software in my usual soft-spoken, dead-horse-friendly way. "Apple, don't brag that iPhone runs OS X," I said, "until developers can get at it."
Come June, Apple gets a pass to brag about its mobile OS all it likes. That's when Apple is slated to deliver its SDK for iPhone, and from the work I'm doing with the publicly available preview tools and documentation, I can attest that iPhone will be the simplest, best-documented, and most enjoyable experience for mobile application developers. I have coded fairly extensively with Symbian, Windows Mobile, and BlackBerry. iPhone just blows them away, making me wonder who decided that mobile development had to be difficult. I'll take that a step further: If you're new to programming, iPhone or iPod Touch is a splendid place to start.
I can't do the iPhone SDK justice in one post, but I can hit a couple of the high notes that earn Apple props for taking the SDK further than it had to. For openers, application developers don't need to use Objective-C, C, or C++ to write software for iPhone. Apple added the one thing I was sure it wouldn't add -- data persistence -- to iPhone's Safari browser, paving the way for applications crafted in JavaScript, HTML, and CSS that run even when the network is unavailable. What's more, iPhone's JavaScript persistence doesn't force programmers to deal with flat text files or XML. It uses SQL, complete with transactions. Apple also put some flash (ahem) in Safari's GUI with built-in support for Scalable Vector Graphics (SVG) and both automatic and explicit animation. Apple supplies Web app code snippets that mimic iPhone's native GUI, and a Web application can take over the whole screen, leaving no trace that it's running in the browser. iPhone's offline Web app support is so strong that I'm looking forward to seeing it ported to Safari for the desktop.
On the native side, we now know that the iPhone OS is based on OS X 10.5, a.k.a. Leopard, and that Apple has catered to Mac developers. Their skills, and fair chunks of their code, will move readily to iPhone. In fact, there are so many similarities between the Mac and iPhone that much of learning to code for iPhone is familiarizing yourself with what you can't do. For example, the same presentation facilities, such as OpenGL and Quartz, are present in desktop and iPhone OS X, but OpenGL is slimmed down to OpenGL ES (embedded systems), and Quartz is limited to 2-D graphics. But use the word "limited" carefully where the iPhone SDK is concerned. Quartz may be limited to 2-D, but it can still load, display, scale, annotate, and save PDF files. Can your phone or music player do that?
Native iPhone applications have access to standard POSIX C APIs and other must-haves such as Berkeley Sockets for TCP/IP communication. All third-party code runs in a sandbox, meaning that the OS exerts tight control over its access to system calls, TCP ports, files, and other resources. You can't write an application that dips into another app's files. You can't write a custom mail or Telnet server that listens on the standard TCP ports for these services, whether the iPhone OS is using those ports or not. Of course, there's no path from the sandbox to any device internals that you could use to flip the phone to a different wireless operator. The sandbox is tight enough that a hacker would have to punch through it to pillage or hobble your iPhone, and Apple has set it up so that every application can be traced back to its creator. Apple's method for registering and certifying applications will engender controversy, but users need to know that they can sample the riches of iPhone software in complete safety.
I'll leave you with two details that put iPhone way over the top for developers: namely, the multitouch display and the three-axis accelerometer. Both of these are accessible in native code as well as JavaScript. Complex multitouch gestures such as pinch, spread, sweep, and circle are sent to software as events along with the basic tap and drag. To make the on-screen keyboard appear, you don't ask for it. You simply move the focus to a text field.
The accelerometer is developer candy that will break Apple into the gaming market in a way that the Mac never could. iPhone can sense orientation and movement in 3-D space. As you move, or whatever is carrying your iPhone or iPod Touch moves, an application can know about it. The possibilities are endless, and there are serious uses for 3-D position sensing that can't be set aside. It's an ultimately intuitive controller for complex processes that currently require operators to bypass humans' natural 3-D perception in favor of 2-D controls such as buttons, switches, mice, and joysticks.
It's my job to dream big, but developers will come up with far more down-to-earth uses for iPhone and iPod Touch. Apple's main interest is in opening iPhone to enterprises that demand mobile devices they can customize to suit their needs. The SDK gets Apple there, and Apple's Mac-like approach stuffs the market with thousands of developers ready to code for the phone. Those enterprises in need of custom code for fleet-issued handsets don't have to look very far for talent. By year's end, there will be a glut of great software for iPhone and iPod Touch, much of which will cost nothing. And to top it off, Apple will host the entire catalog of third-party software.
Will this change the world? Apple would argue that iPhone did that when it was launched, but I disagreed. In June, when iPhone firmware is updated to Version 2.0 and the object is opened to developers, I'll see the device that I hoped iPhone would be. That will instantly transform high-end consumer phones and music players, and it will gradually alter the landscape for commercial mobile devices. Much depends on how hard competitors are willing to work on their SDKs and developer programs. Communities of mobile developers are scattered and poorly supported. At least in iPhone, other mobile players have a model that reaches from platform and dev tools through distribution and billing.
Perhaps there will be some surprises coming out of the CTIA (Cellular Telecommunications and Internet Association) conference that's just around the corner. Something's going to happen, because Microsoft, Nokia, and RIM can't sit still while Apple accumulates mobile market mindshare, and market share, through its application catalog and developer buzz. There is already electricity in the air. Microsoft and Nokia have declared significant other-ship on Microsoft's Silverlight (nee cross-platform .Net), and RIM is rolling out a substantial firmware update to keep its platform fresh. This is all good; they'll need momentum because when Apple's mobile software catalog, dubbed AppStore, goes online, users of other platforms will start asking their handset makers why they can't share in the riches.
[ For more on the iPhone's potential in the enterprise, see Tom Yager's initial reaction, his iPhone 2.0 Q&A, and our Special Report: IT's guide to the iPhone ]
Posted by Tom Yager on March 12, 2008 03:00 AM
TOP STORIES
ADDITIONAL RESOURCES
- Do you have the power to resolve technical issues with one call?
- Take control of your content- leverage Microsoft SharePoint
- Keeping the E-Mail Flowing
- SGI Adaptive Data Warehouse: Building a High-End Oracle Data Warehouse
- Five Steps to Secure Outsourced Application Development
- Global Shared Memory: Performance and Productivity Breakthroughs
