Since the bulk of the server side for The Path of the Seven Millennia has just been completed, we would like to spend a couple of words on the technological stack of our choice and our experience with it so far.

Our project involves quite some work on the technological part as well as on the artistic one, since we do not only have to build the final product, but we also need an infrastructure to deliver the content and some tools to create such content. We do not have many resources though, since we are only two: the artistic guy, which is the creator of the comic and handles everything involved with it, and the technical guy, which handles all development (and which is the author of this post). We both are working full time on other jobs and dedicating to this project our spare time, so time is a really scarce asset for us and we have to use in the most efficient way.

Our stack of for the project is as follows:

• Product: iOS devices (both iPhone and iPad)
• Tools: Mac OS X Snow Leopard
• Server side: Clojure on Google App Engine

Let’s see why we made such decisions and what the benefits are.

iOS

It can’t be denied that one of the main point who influenced our decision to deliver our product to iOS devices is proficiency in the platform. I am mainly an iOS and Mac OS developer with quite some experience it both platforms now. But this is not all, of course. If we felt that another platform offered more opportunities, we would have invested in that one instead that iOS.

Speaking marketwise, iOS is the platform that offers more opportunities to monetize our product. Even if Android is catching up regarding the raw number of users, it looks like iOS users are more willing to spend money on apps and content. I have no first hand experience in Android, but this is definitely what I keep reading around: Google set a different mindset in the Android market, which tends toward “free apps”.

Another issue Android developers have been complaining lately is that the Android market is sub-par in respect of the App Store and search in it does not even work that well (ironically, being built by Google this should be one of its core feature). There wasn’t even a way to browse it from a computer until recently Google fixed this.

Technically speaking, we believe iOS is better fitted to our vision too. Through Core Graphics the OS offers a lot of handy capabilities for image manipulation, which are crucial in our app. Even though Android could have similar capabilities (again, I’m sorry but I don’t have experience in it), what I’m pretty sure is better on iOS is animation support. In the company where I work daily, we develop both iOS and Android apps and often we build versions of the same app for both platform. I’m confident that we have very good Android developers, but what I see is that iOS versions of the apps we build tend to be better from this point of view, because what I do (animation-wise) in a couple of lines of code on iOS is not easily doable on Android (again, I don’t think to be a better developer than my colleagues working on Android and I believe them to genuinely be good developers, but usually when they see some animations we put on iOS their main reply is “we can’t do that in Android, or at least not easily”).

Another issue Android has is fragmentation, even though a lot of Android developers are arguing that it’s not a problem. Well, from our point of view it is. The first type of fragmentation comes from different hardware. Of course Android offers facilities to handle all these differences, but still it’s much easier to design the app for a fixed aspect ratio of the screen than to design it to be adaptable to different ones, and as a developer I’m happy I don’t have to take them into account during development.

Then there is also fragmentation in the OS version, caused by (some) carriers that refuse to provide updates even for devices that have been released recently (or worse, there are some devices that are released with an old version of the OS). We are too small and we already have a lot of work to do to make our project possible, we can’t afford to spend time on these issues, even if they are really as small as the Android community claims them to be.

So, given all these considerations, we think that iOS is the best bet for us. If our project will be successful as we hope it to be, of course we will take the Android platform into consideration.

Mac OS X

Another advantage that iOS brings is that it is derived from Mac OS X and shares with it a lot of technologies.

Unfortunately our content does not spring out from a magical source, but it must be created as well: after all it’s the content that is our real product, while the apps are the medium to present it. The comic is produced in the “old-fashioned” way: it’s drawn on paper by hand and then it’s digitalized and colored. What comes out of this process is not directly usable in our apps, unfortunately (also because the comic was initially intended for the print market). We need tools to specify the format of the content and to define how transitions and effect happen. We must then be able to preview the result during the creation for the necessary adjustments.

Here is where the similarities between Mac OS X and iOS come to the rescue. The two platforms not only share the same language (Objective-C) but share a lot of core frameworks. There is some code I wrote that works on both platforms without changes, and this speeds a lot our development cycle.

To be a little more specific, our Mac app uses Core Graphics to do some image slicing and manipulation, and this code is used on iOS as well without modifications. Moreover the Mac app uses Core Data to save the documents containing the final versions of comic chapters. We have a small preview app that runs on iPhone which uses the same Core Data model and almost the same code as the Mac app, so we can preview the final product without having to load the content to the server (which uses a different data format).We just connect a device to our Mac, load the saved document on it, and we can immediately preview the final product. Very handy.

After the content of an issue has been finalized, we upload it to the server using another tool which again shares some code and the Core Data model with the content creation app. The tight integration between the two platforms really makes a difference for us, cutting a lot of development time and giving us some tools that probably we would not have had on other platforms due to the time required to develop them. This increases the overall quality of the final product, too.

A little final bonus: if we decide in the future to release something for the Mac App Store (we are already thinking about it), we will be able again to reuse a lot of our codebase.

Clojure and Google App Engine

The apps, the content and the tools are still not enough: we need an infrastructure to deliver the content to users, since through the App Store we can only deliver the iOS apps. On the server side the considerations are different: we need something that will be able to scale in case the demand for the content will be high (we really hope so!). At the same time of course, the cheapest and easier to use it is, the better.

Putting together these requirements with my recent interest in functional programming and Lisp, I decided to go for Clojure on Google App Engine. The latter provides a scalable infrastructure which is, for one, free to experiment with and for which we will have to pay only if the demand will be high enough to go over the quotas (in which case we will be happy to pay, since it will mean we will be doing very well!). In that case the price is still cheap compared to other solutions I saw around the web. The deployment on GAE is also very easy and you don’t need to have any experience in managing a server infrastructure.

Clojure is a wonderful language, even though I must confess that my skills in it are still not good at all. Lisp has always been a very powerful and expressive language and Clojure takes the best out of it, with some more nice added features. I’m really impressed by how easy was to build our server side part. Functional programming seems really suited for web development (our server is mainly a REST api called by our apps). After using Clojure for a while, I’m starting to look at OOP with different eyes.

To ease development I’m of course using some Clojure libraries. For the REST implementation I use Compojure (which is built on Ring). To interface with GAE I use Appengine Magic. This library still has not reached the 1.0 release, but it does already a very good job to interface with GAE without using directly Java from Clojure.

The only rough edge I found is that, in the current version of Appengine Magic, most of the GAE functionality does not work in the interactive Repl. Every time I change some code I have to compile the code and run it on the development server, which requires some time and means you lose one of the main benefits of Clojure (which is fast interactive development).

Apart of this flaw, which probably will be solved when it will be more mature, I think this library does a really good job overall (I’m using it to interface with the GAE Datastore and with the Blob Store).

This are the reason why we chose this stack for our project. We hope that our experience with it will help others in their decisions.

Now we will go back on the development of the apps. We hope we will have some preview of our product soon. Stay tuned.