Being an Apple Developer These Days Must be Hard

I know lots of people were bent out of shape when Steve Jobs told the crowd at WWDC that they can develop for the iPhone as long as it is in the browser. The whole idea of providing access to build applications for a platform is typically at the heart of that platform’s success … when I think about Apple’s business models (or product segments) for a second I see things in an interesting way. Apple seems to have a few core areas of focus these days in the hardware space — the Mac, the iPod, the Apple TV, and the iPhone. Each one does some amazing things — and to tell you the truth it occurs to me that only the iPod isn’t running OSX … they’ll fix that. This is from a company who “ignited the personal computing revolution …” Things are shifting.

The Mac has always been a platform where developers have been invited to play. You want to make some software for it? Go ahead … Apple even has a whole developer relations group and associated services. WWDC is a developer’s conference — a developer’s conference for the Mac. With that in mind I can see why the masses were irritated when Jobs told them to build web apps to support the phone. These are real developers who write real code. Not that web apps aren’t real apps, but I think we all get the notion. I am quite honestly excited by the web apps I am seeing being revised to work really well on the iPhone. The Ta-Da List port is one that makes a whole lot of sense in the browser — I am now testing it with my administrative assistant as an ad-hoc calendar tool.

The iPod is a closed platform from what I can tell. There isn’t an open SDK for the iPod that I know of. I could be wrong about this one, but I don’t know of one — at least on the software side. I tell a story about a time I visited Apple right after the iPod was released … I actually told an product manager that if they really wanted to make this product successful they’d release an SDK and let computer science departments use it as a platform. I guess my brilliant idea wasn’t needed. Sure, Nike and a few other select feew companies have been able to release software that extends the functionality of the iPod, but for the most part it is a closed party. The Apple TV is being hacked all the time, but again, from what I can tell it is a closed platform. Yes, the Apple TV runs some sort of OSX, but it isn’t a true Mac.

The iPhone is in the same boat … it runs OSX, but it isn’t a Mac. Apple has created a website that gives us the info we need to create the right kinds of web apps, but that is as far as they’ll go with it. The funny thing is that the fact this thing has a browser opens up nearly unlimited possibilities — at least from my perspective. It has to be hard for real developers though.

The whole paradigm shift happening at Apple is interesting to watch — a computer company that is no longer just a computer company. How will this change developer relations? How will WWDC need to change to integrate the other three product lines? I have no idea, but I doubt Steve and Co. are done in the space that isn’t occupied by the Mac. Imagine being a developer and being tempted by these other products … just dreaming about what could be done. It must be so hard to step outside the Apple developer mindset.

15 thoughts on “Being an Apple Developer These Days Must be Hard

  1. The shift is to the browser as a platform not the OS. The iPhone is just a great example of that. Look at Adobe AIR (Apollo), it is the same thing as it puts the focus on web apps that can function like ‘real’ apps. Apple is just the first company to release a product that totally subscribes to the idea the browser is the platform… I don’t pity ‘real’ developers at all. I say welcome to the thin client future 😉

  2. Good point! I hope my post isn’t taken as complaining about the state of the Mac developer … all I am saying is that the new stuff Apple is doing is so exciting, I am sure developers are chomping at the bit to be able to get under the hood.

    BTW, I approved the comment about while sitting at a red light this morning from my iPhone. In one red light I was able to grab my email, click the approve this comment link, have it open Safari, and approve it. All over the EDGE network and all in the amount of time it takes to sit through a single State College red light.

  3. Actually, this is entirely consistent with Apple’s history. To begin with, pre-OS X, the Mac OS was actually known to be relatively unfriendly to developers. Taking security as an example, somebody once said that the Mac was so secure in those days “because it’s hard to hack into a toaster.” There was no command line. The system was far less accessible to developers than Windows was. Speaking of which, Microsoft has historically done a far better job of supporting developers than Apple has. Whatever one thinks of Visual Basic, it attracted a huge number of developers to the platform.

    One reason Apple was ahead of its time is that it has always been an information appliance vendor more than a computer vendor. When the Mac first came out, it was derided as a “toy” because it favored “the rest of us” over developers and power users. This meant doing things like locking down parts of the OS so that users couldn’t accidentally end up playing “hide the haiku in the registry” the way Windows users could easily do for well over a decade. OS X is something of an anomaly, but you see it even there in things like Apple’s stricter enforcement of UI standards via their developer tools and APIs.

    In the case of the iPhone, Steve Jobs has (correctly, in my view) decided that people would rather have a phone that doesn’t crash than one with all kinds of cool apps on it. That means being very careful about letting third-party compiled apps run on your machine. And as the previous commenter pointed out, the web is a first-rate development platform. The iPhone is only a closed platform insofar that the web is a closed platform, which is to say that it is not. I would expect that, as more online/offline web-native technologies are developed (e.g., Adobe AIR and Google Gears), you’ll see more iPhone-friendly apps that are web-native but continue to work even when the iPhone is not connected.

  4. Pingback: University Update - Steve Jobs - Being an Apple Developer These Days Must be Hard

  5. I’m an old-time Mac software developer, and when sitting among my peers at WWDC I could hear their groans at the announcement of the so-called “web-SDK”. However, for the last few years I’ve been developing web applications with javascript, XUL and AJAX, rather then Cocoa, so I was not as displeased, and in fact that this is a continuation of the tension that the Apple has always had with its developer community.

    The document released by Apple this week only tells the beginning of the story of how to optimize web pages for the iPhone and develop webapps. The http://www.iPhoneWebDev.com developer community has been working hard to fill in the gaps of missing information. Since Friday we’ve figured out some best practices for viewport settings, discovered how to hide the URL bar to make more space available to web apps, how to detect orientation changes (portrait to landscape and back), tested AJAX and javascript performance, and have made progress on quite a few issues and work arounds for a number of bugs. If you are an iPhone web coder, check out our list archives, examples, and come join our community of developers helping developers!

    Also, many of us are participating in this week’s barcamp-style http://www.iPhoneDevCamp.com conference this Friday in San Francisco. We hope to see you there!

  6. Web apps do not open up limitless possibilities, nor is the web a first-rate app development platform. On the contrary, web apps are extremely limited. For example, there is no way a web app can access the filesystem on the iPhone, control the camera, talk to the address book, or update my calendar. Web apps are also a huge minus from a development perspective: The debugging, diagnostic and profiling tools for web apps are extremely poor, where they exist at all. It’s a development nightmare.

    During the iPhone intro at MacWorld, Steve Jobs made a big deal of the fact that the iPhone has no physical keyboard; he said that having a large bitmapped screen would let developers reposition controls at will, design custom UIs, etc. Except that very little of that it is true for web apps, where you are limited by the DOM and CSS. If the iPhone supported applets or Flash, then it would be possible to create arbitrary controls.

    As for application stability, I think is a strawman argument. Web apps aren’t a panacea against instability (I’ve seen plenty of browser crashes, both on my desktop and my Treo). On the other hand, all of my PocketPC devices have been remarkably stable, even when running a variety of 3rd-party native apps (no, they’re not perfect, but they rarely crash). I also feel compelled to point out that if Apple were really concerned about app stability, they should look into using a Java Virtual Machine on the iPhone. A JVM would isolate apps from hardware details, provide safe access to native facilities when needed, and isolate apps from each other. And JVMs have fantastic development, debugging, and profiling tools.

  7. Application stability is absolutely not a straw man argument. There’s a huge difference between a browser crashing and the OS that runs your whole phone crashing. I’m glad you’ve had good experiences with your PocketPC devices, but that’s certainly not universal. And the bottom line is that, for many users (including me), tolerance for a phone crashing is much lower than tolerance for a computer crashing–especially if there is a chance that recovery from the crash will require more than a simple reboot.

    A web app can potentially update a calendar via CalDAV or iCal, the address book via vCard, and the desktop file system via WebDAV, FTP, of CFIS–or via custom web services that Apple could provide. Apple may not provide these right now, but that is an implementation issue with Apple rather than a fundamental flaw with the web as a platform.

    In terms of the languages and toolchain available to developers, you are welcome to use .NET, Java, C, or even Common Lisp on the server side. You can use Eclipse, MS Visual Studio, JDeveloper, or whatever. I’ll grant that the situation isn’t as rosy on the client side, but it’s not like people aren’t developing good, rich apps for the web. There are tons of them. And increasingly, they are being developed in AJAX. I have seen a handful of nice Flash apps, and I agree that it would be very nice to see support for Flash on the iPhone. I see very few Java applets.

    Again, I’m not arguing that the current state of the iPhone as a development platform is without its problems and holes. Nor am I arguing that there is no difference between developing a web app and a desktop app in terms of the challenges and limitations for devleopers. But I *am* arguing that the differences between a properly rich web environment and a desktop environment are small enough to justify the trade-off in stability for a phone.

  8. If you’re concerned with application stability, then use a processor with an MMU (so you get protected memory), and possibly use a JVM. Doing so will create a much more useful device than something that only display web pages.

    I have to disagree with your arguments about web-app extensibility. Certainly I could use a web-based front-end to a calendar system (indeed, given how crippled the iPhone’s calendar app is, one has no choice but to do so). But one can have a much more enriched experience if using a native calendar app, whose UI is tailored to the device. Further, calDAV, being HTTP-based, presents rather annoying authentication issues which I won’t detail here. (And, being based on WebDAV, it’s locking and synchronization models are broken, as the WebDAV locking RFC itself admits, but that’s another issue for another blog entry).

    Concerning the address book, while it may be possible to add new data to the iPhone’s address book by downloading a vCard file, it’s certainly not possible to query the address book with vCard, which was my point. If I wanted to build an addressbook-enabled app, vCard and Safari won’t cut it. It’s great that I can sync my contacts with my phone (and despite Steve Jobs’ hype, it’s not at all a new feature), but it would be far more useful if I could use that data in my apps. PocketPC and PalmOS let me do that. The iPhone does not. That’s a real shame.

    I don’t understand your comments on WebDAV, FTP and CIFS. None of them let me open a file on my local filesystem.

    Say I wanted to write an app for the iPhone which would take a picture and upload it to some photo sharing site. I can’t do it. I’d need the ability to access the camera, store the picture to a temp file, then upload the file to a web site. The iPhone doesn’t expose APIs to do any of those things. No amount of AJAX is going to overcome those limitations.

    You also seem to have missed my point about development environments. I was not discussing the server-side of the equation. I was lamenting the abysmal state of *client-side* development and debugging. There are practically no decent Javascript debugging tools (Sun’s nascent DTrace-instrumented JavaScript engine is a welcome exception). The web-browser, as an app delivery platform, is pathetic in terms of diagnosability. Flash is in an even worse state.

    There are ways to deploy native apps that don’t crash the host OS. It truly is a shame that Apple didn’t use any of them. I really don’t understand why Apple put OS X on the iPhone. OS X is a general purpose OS optimized for media manipulation. It’s not an embedded OS. There’s a reason the iPod doesn’t run OS X. In general, general-purpose OSes don’t make sense in “embedded” environments (I’m using “embedded” liberally). While it may be nice for Apple to say that they have Core{Data, Animation, Video} on the iPhone, if they don’t expose those abilities to developers, then it’s a much less interesting and useful platform.

  9. You mention that the iPod is the only piece of Mac hardware not running OSX. I assume they will remedy this in the next version of the ipod. It seems to me that whatever applications can be developed for Safari, nothing will be able to be put into largescale practice for educational use until a device like the iPod (which so many student will buy) is able to run them. The iPhone is too expensive at the moment, but a new iPod with the design and some of the functionality of the iPhone would be significant for educational purposes.

    Now that I think of it, the appearance of Safari for Windows and the increased apps that will be available for Safari (even with their limitations), would give us teachers a way to deliver content to students on a variety of hardware platforms and with an increased ability to reach them wherever they are. For this, however, an iPod with significant storage space, running OSX and capable of getting online at least via Wi-Fi is necessary.

  10. I didn’t miss your point about client-side development. I just think you’re overstating the importance of it, just as I think you’re understating the importance of application stability. You made it sound as if there are no good tools for developing web applications, and that it’s impossible to debug web applications. That’s just not true. There are plenty of good tools on the server side, and the gap on the client side is narrowing. If you really need to use your debugger, then write your UI in GWT, for example, It may not be up to desktop standards yet, but I’m happy to report that plenty of good web app UIs somehow manage to get written. For example, there are a number of excellent web UIs for calendar apps right now. I just don’t buy the argument that you need a desktop environment to build a good calendar UI. That has been proven false a number of times over now.

    Dealing with the data interchange is a bit tougher, but it’s certainly not intractable. There’s nothing to prevent Apple from exposing Address Book data via web service, for example. Don’t forget that, if the iPhone has OS X under the hood, then it very well may have Apache under the hood as well. Again, the point isn’t that all is Nirvana in iPhone Developer Land so much as it that the choice to go with a web platform is is not the main source of any problems.

    As for why Apple would put all that OS X goodness into an iPhone and then have the audacity to not expose it to you, I think multitouch zoom is one good example. Some of the general-purpose technologies they are developing (e.g., resolution independence) are incredibly useful in the iPhone’s form factor. At the same time, they are clearly making some customizations to the technology base in order to make the iPhone software appropriate for a phone.

    Like locking it down to 3rd-party compiled apps, for example.

  11. A more iPhone-like iPod will also be a first-class device for reading text. Couple that with support for PDFs in iTunes U, and we may finally have a device that can make electronic textbooks a practical reality. It’s not exciting pedagogically, I know, but it could save students huge amounts of money (not to mention wear and tear on their backs).

  12. I’m not understating the importance of app stability. I’m saying that there are ways to achieve both app stability and expandable devices. And some of those ways make developing apps a lot easier.

    I don’t see web-app development tools improving much at all. There is nothing comparable to, say, mdb, dbx or JConsole for Javascript, let alone Flash.

    I’m dubious about appeals to “web services” (why can’t we just call these RPCs?) to solve iPhone app development problems. It’s a rather… clunky way to access features (for instance, sending an XML-RPC to Apache on localhost instead of making a simple library call to get at the address book or use the camera).

  13. Pingback: Adoption Time at Cole Camplese: Learning & Innovation

  14. Pingback: Wow, Now That is Interest at Cole Camplese: Learning & Innovation

  15. Pingback: Developer Specifications at Cole Camplese: Learning & Innovation

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.