“But Sean!” I hear you, Rhetorically Convenient Reader, cry. “You just started working for Magnolia back in March! Why are you moving on again so soon?” That’s a good question. It doesn’t have anything to do with Magnolia: it’s a terrific company, filled with great people that I am glad to call coworkers and friends. That fact made this decision especially hard, as I knew I’d be seeing less of these people I quite like (and would, honestly, be making their lives tougher in the short term with my departure).

But as much as I like Magnolia, the nature of their business means that my work there revolved around two things: Java and Sales. Java is an industry standard for creating software of various stripes, but it’s a very buttoned-down, staid environment to work in. It lacks the creative energy and — is it silly to say this? — joy that I see in the communities that exist around some of the more dynamic, less-widely used languages like Ruby and Python and Lisp (for you AI wonks out there). I can get work done in it just fine, but the number of times a spontaneous “Awesome!” escapes my lips while doing so is vanishingly small.

The other focus of my last 9 months has been selling Magnolia to various companies. I think the software is a phenomenal piece of work, and really well-suited to a whole variety of Web Content Management scenarios. But while I can do an effective job helping to demonstrate and sell it, there’s no frisson associated with doing so for me.

I like technology for what it can do for people. I like creating it because doing so is much like fashioning a beautiful, intricate bit of clockwork, or a complex bit of musical counterpoint. There is immense satisfaction in creating something that works elegantly and beautifully. Unfortunately, telling people about how terrific other people’s work is provides very little of the satisfaction that actually doing that creative work oneself. If I’m going to be in the technology world, I want to make cool stuff for normal people, not to sell cool technology to corporations.

So, Mutual Mobile. I’ll be starting there as an iOS Manager, which means that not only will I be getting to work directly on creating some great stuff for their impressive list of clients, but I’ll also be getting to help figure out the best way to help the other developers there do their best work as well. I’ll be hanging around a bunch of really smart folks, and will doubtless be learning tons about iPhone development and other mobile disciplines. The company seems like a marvelous place to hang one’s professional hat — a vibrant company culture, entirely self-funded with no investor money involved, just named by Forbes as one of America’s most promising companies, and has its company meetings at the Alamo Drafthouse, one of my favorite places in Austin. And the downside of facing a commute again is largely ameliorated by the fact that Texas State University runs a shuttle bus from San Marcos with wireless Internet to a park 4 blocks away from the office. Sweet!

I’m excited about this next adventure, and will be posting more about it once I’ve got my feet under me. Wish me luck!

This isn’t a decision we made lightly. I actually resisted it for a number of months, even when some of the other developers on my team were lobbying pretty strongly for it. The promise of Titanium, which allows developers to use Javascript to create native applications for iPhone and Android platforms, was great. Unfortunately, it has never lived up to that promise for us.

The first reason we decided to leave it behind was Apple’s Developer Program License Agreement. When iPhone 4.0 was released, the Agreement was amended to prohibit using intermediary layers like Titanium. The folks at Appcelerator quickly moved to quell their customers’ fears, pointing out that Apple was still approving Titanium-made applications. While it is true that Apple hasn’t lowered the boom yet, these apps still violate the letter of the agreement, and could therefore be pulled from the App Store at Apple’s whim. Further, when RunRev, a company that creates a development tool similar to Titanium, tried to reach an official understanding with Apple, Steve Jobs made it very clear that Apple wasn’t interested. Given this level of hostility to other development tools, staying with Titanium would obviously increase the risk that we’d run afoul of Apple in the future.

The second, and more important, reason was this: Titanium’s engineering is just not good enough for our purposes. It works great for small-scale projects that people want to get done quickly. But as we have tried to build large-scale projects, we have repeatedly run into problems that we would spend hours trying to solve, only to find that there was an issue in Titanium’s code that we couldn’t work around. New versions of the software would cause portions of our code that had worked fine before to stop functioning. Version 1.4 of their framework was released well over a month after they had originally promised it.

As one of the programmers on my team put it: “When I work in [another development environment], I’m 99% sure that any problems I have in my program are because I’m doing something wrong. With Titanium, I’m only about 50% sure.”

To be sure, the folks at Appcelerator have taken on a huge technical challenge, have ramped up quickly, and are working as hard as can be to make their product feature-rich. But after months of frustration, we’re not willing to keep investing in a system that keeps us so far from our programming happy place. Objective C, here we come!

When I last went camera shopping, I tried to find another camera that allowed programming, as I’m forever wanting to try different things while capturing images. But there was absolutely nothing available. I could get cameras with built-in wifi, GPS, a bevy of image processing modes, but nothing that actually allowed me to write your my programs to tell the camera how to behave.

(I would be remiss not to mention CHDK, an alternate open-source firmware for many Canon cameras that allows one to do all kinds of crazy stuff with them, including writing your own scripts. It’s awesomely capable, but lacks the refinement and ease-of-use that make it possible to pick up the camera and just use it. For everyday picture taking tasks, it actually makes the camera more difficult to use, in my experience.)

Enter the iPhone. From a feature standpoint, it’s not especially notable as a camera: 3MP, no flash, no zoom, odd form factor (for a camera). But the thing that sets it apart is its programability and connectivity. One can download apps to provide all kinds of interesting photo-related functionality: panorama stitching, photo-a-day applications, film camera simulations, various specialized effects, retouching tools, and even “Pimple FacePaint”, which lets you add blemishes to portraits. (There’s a market for that?)

Add that customizability to its communication capabilities, which allow one to share and upload images right from the device without bothering with cables, and you have an unparalleled platform for creating and distributing photos. With a traditional camera, for example, to take a panorama, I would have to shoot each of the images, hoping I got them framed correctly, then download them to the computer, then stitch them together, then upload them to a photo sharing service. On the iPhone, I can do all of those things from one app on one device. (And have the image automatically geotagged, since the iPhone has GPS built in.)

There are certainly still situations where it doesn’t make sense. If you need high-resolution imagery for printing enlargements, you’re out of luck. If you need a flash, ditto. If you are shooting from a distance, you’d be better off with something that has a zoom lens. But for day to day photo taking and experimenting with creative techniques, there’s nothing out there that can beat it today. And the recently announced iPhone 4, with its LED flash and higher resolution image sensor, only stands to make it better.

Postscript: no, I don’t have one, and won’t get one until the usurious data fees get lower or I get markedly richer.

The team brainstormed and prototyped the original version as a learning exercise at the beginning of the year, but once Marketing got wind of it, it quickly became a high-priority project. I’m really proud of my crew, who have all stepped up and contributed design ideas and code to the final product, which turned out really well.

We have some ideas for improving it going forward, and have plans to create an Android version as well, but are, for now, just delighted to finally have it out there in the world!

First off, the iPad doesn’t do everything. It’s not a full-on replacement for a computer. In fact, you can’t even get it running without a computer to which you can connect it. It lacks a camera, so you can’t use it for videoconferencing or photography. While it’s better for content creation than the iPhone, thanks largely to its bigger screen and support for Bluetooth keyboards, it includes no facilities for printing out the content you do create. For that, again, you’ll have to rely on a computer.

That said, it does 90% of what people use a laptop for, and does that 90% beautifully. Web surfing is a smooth, fast delight. Dealing with email goes smoothly and quickly. The Calendar and Map applications are lovely to look at, and a pleasure to use. Listening to audio and watching video, while hampered a bit by the monophonic built-in speaker, is likewise a pleasure. The vibrant high-resolution screen makes it great for showing off photography. (In fact, I’ve already heard of a graphic designer friend-of-a-friend who got a job because he’d loaded up his portfolio onto the iPad to show it off.) Writing works great, especially with a hardware keyboard. And of course, there are a wealth of applications designed for the platform that make it even more versatile and capable.

Is it for the person who likes to tinker with computers? Probably not so much. Apple takes great pains to keep the iPad and its related platforms, like the iPhone and iPod Touch, locked down and controlled. On the other hand, this is a device I could give my Mom and expect her to actually use it. If one wants to do the things the iPad does, there’s not much way to do those things better, faster, or more intuitively.

The version that was current at that time made it very easy for people with web development backgrounds to create native iPhone applications. It did so by opening a web view for every screen of the application and then letting one author HTML, CSS, and Javascript that ran within that context. By layering native controls on top of those web views, one could make decent-looking applications quickly in a way that was intuitive for those of us who live and breathe these technologies already.

Unfortunately, this was not an efficient approach. Having so many web views in an app caused it to run slowly and take up a good deal of memory. Additionally, apps written with HTML/CSS instead of more traditional methods tend not to look quite right, since they make less use of native controls and use more web-like design.

Appcelerator’s solution? With their latest releases, they’ve changed the architecture pretty dramatically. Instead of basing everything on web views, applications now use native controls exclusively, only falling back to web views when you’re actually doing something on the web. The application UI is created entirely in Javascript, and HTML and CSS now have very little, if any, place in an application.

The upside to this is that performance has been improved by an impressive amount. Apps written in Titanium are generally as responsive as apps written directly with Objective C and Apple’s tools. Additionally, all of the UI elements are now dynamic, so that one can make adjustments to on-screen objects at any time — not just when a window is initially rendered. Managing the scope of variables makes a lot more sense in the new version than it used to, and requires far fewer chintzy hacks to pass data from place to place.

The downside, sadly, is that Titanium loses a portion of the ease-of-use that made it attractive for us to begin with. All of the UI we had done with HTML/CSS now has to be rewritten using native controls, which are a good deal more cumbersome. Essentially, one is writing much more directly to the iPhone API, but just using Javascript instead of Objective C to do so. (Which is still a win, in my book, as I have a pathological hatred of having to manage memory for myself.)

We’re currently pushing forward with the transition to the new way of doing things, and probably have about 40% of our prototype app rewritten for the new system. The new version feels generally tighter and more professional, but is definitely taking longer to write than was the case with the old methods. And while I’m still very impressed and happy with Titanium as a product and feel that the tradeoffs were the right ones to make, it does now feel much less like iPhone programming “for the rest of us.”