I’ve always been interested in pushing the limits of what can be done in a web browser and I’ve done that when I was at Apple, Strobe and now Groupon with SproutCore and Ember.js as well as during working on research for the visualization academic citation networks while at UC Santa Cruz and Santa Clara University.
I’ve made a switch that I’ve contemplated for quite some time. I’m leaving the web behind and entering the world of iOS development. I believe in the bright future of HTML 5 on mobile and I know that I’ve not left it behind forever but it’s nice to try something new. I have to say that I enjoy iOS development so far when I compare it HTML 5 application development with the above mentioned frameworks.
There are two major reasons. First, the never ending worries of browser and device compatibility is addressed by the iOS ecosystem. There is a very limited number of OS versions and devices. Since the number of potential variations is reduced, you can spend more time getting the user experience perfect. There are less compromises that have to decided on that gives users a variable experience based on their platform. That’s a great thing from the user interface design and development side.
Second, is that there a more stable and more importantly, more documented SDK in the iOS world. The Apple documentation is not perfect, but it’s much better than the state of the HTML 5 frameworks that I come from. I have to say, however, that it is mostly my own fault. Since the projects that I’ve worked on always strives to do new stuff, we are usually working with a framework that is not complete and as such, has no real documentation beyond the code itself. Over the years of developing client side web applications with SproutCore and Ember.js, I’ve always been on the bleeding edge and developing my apps as the frameworks were being written. Since the APIs for the frameworks were constantly changing, it is more of a challenge to write maintainable and well-organized code. Not impossible, but you have to understand the internals of the framework in order to do things right.
As a result, I’ve had to rely on the alpha or beta versions of supporting frameworks. I do this because the bleeding edge version of the framework has features that we need and some times, the changes in the frameworks are done to support the application I am working on. However, that leads to one unfortunate reality. I have to freeze the version of the framework regardless of where it is in its release cycle as I get close to releasing my own application because I can’t have things changing underneath me.
The downside of this is that once the framework does freeze its API and releases a solid point release (such as Ember 1.0), I’m in no position to easily port my application to support it because I have moved on to the next project. To go back and update to the latest stable version of a framework is very disruptive for the team and I’ve rarely seen it happening until we decide to do a major rewrite much later. Then, we usually fall in the same trap because the newer alpha or beta version of the framework, such as a 2.0 release, will have stuff we need at that future point. As a result, it’s a never ending cycle. I do have to say that I enjoy living on the edge of open source frameworks but it can also be frustrating because things change quickly.
With iOS development, things are very different to me as a developer because of the frequency of SDK releases and the documentation that comes with it. The API might break from major release to release, but there amount of churn is a lot less. So far, I’m enjoying that aspect of my journey as an iOS developer.