In Praise of ARC

It’s not all the fault of the garbage collector…but I’m growing to love ARC

When I started developing on Windows in the 1990′s, software was fast even though computers were pretty slow. The word ‘Native’ was used to describe an indigenous person and Java was still just a type of coffee.

Somehow this all changed. You could call it progress I guess.

Managed languages, virtual machines, JIT and byte code took over. This seemed to go hand in hand with garbage collection. “Horray” we all shouted. No more memory leaks.

Wrong. They just became harder to find.

There were lots of other advantages though….weren’t there? Well maybe. .Net allowed us to write in a slew of different languages that could talk to each other without having to use shared C libraries. A managed environment protected all the applications from one another and looked after resources more intelligently. So it was all still good. Right?

Frustration. Managed

I’m writing this post to vent a bit of frustration with the promises of byte code VM’s and garbage collection; I’ve fallen out of love with ‘managed’. iOS and Objective-C have shown me another way.

Android’s latest version, Jelly bean, has put the emphasis on delivering a ‘buttery smooth’ user experience. You know, the kind of experience the iPhone has enjoyed for 5 years! Well, now the Java based Android (running on the dalvik VM) has achieved the same thing. 5 years on. Thanks in no small part to huge leaps in its graphics acceleration hardware and a quad core processor!

On Windows, .Net and WPF are slow, hardware hungry beasts. If you want speed, you have to drop down to the native DirectX API’s..and until recently you could not combine these different graphics technologies very easily; Windows suffers from severe ‘air-space‘ issues.

When I started developing for iOS, I was pleasantly surprised by several things:

  • All the different API’s in the graphics stack played nice together.
  • Apps were lightning fast and beautifully smooth with low memory overhead.
  • I found the lack of garbage collection liberating.

[Garbage release]

I did not, and do not, miss the managed environment. Before ARC we had to do reference counting in Objective-C on iOS. I was used to this from my days with COM on Windows but reference counting on iOS made more sense somehow. The rules seemed clearer.

And then the compiler got clever. The compiler. Not a VM.

With the introduction of ARC we dont have to do reference counting. The compiler analyses the code and does it all for us. In the main, it does a fantastic job. The compiler and the tools for developing on iOS manage to produce native code, make it easy to consume C and C++, make reference counting almost invisible, produce sandboxed apps that can’t crash other apps and give me the good grace to use pointers where I see fit without having to declare my code “unsafe” (most of the time anyway)

I still love the Microsoft C# language and the BCL. But as for the whole managed thing? I am happy to leave it behind.


iBooks for Kids: Inception

What if this book, or at least the images for it, were created completely on the iPad? It would give it a unique kind of flavour wouldn’t it?

Having taken a look at ‘book style apps’ on the App Store and the various types of eBooks available in the iBooks store, I became interested in how you might go about developing one. Having ruled out plain old eBooks I was left with the following two choices:

  1. Develop an app which woud let you completely control the user experience but not be visible in the iBooks store.
  2. Develop an iBooks 2.0 ‘eBook’ and work within the fairly rigid constraints of the authoring tool.

Well, I’ve done apps. And it may well be the better option…but I fancied trying something new.

Now, I am not the greatest artist in the world. But I do like to play around with Sketchbook Pro on my iPad from time to time. This lead me to wonder…

What if this book, or at least the images for it, were created completely on the iPad? It would give it a unique kind of flavour wouldn’t it? And what if we leveraged HTML5 widgetry to create something a bit different to the non-app books that are out there at the moment?

I was mulling this over when something else was bought to my attention. An amazing-musician-and-producer friend of mine had recently recorded a nursery rhyme album…interesting. Now, I thought, that would be cool: A touchy, interactive, sing-along iBook for kids, with illustrations done all on iPad…and all self published.

So. That was that.

I’m currently working on the illustrations for the book. It’s going to be a pet project for a while. Hopefully I’ll finish it before I get distracted or swamped by other stuff.

It could be a fun and unusual journey.

iBooks for Kids: Confusion

A while ago I blogged about a silly little iPad app I wrote for my three year old son, and how it led me to wonder about iBooks.

It struck me that an app that was essentially a book that played sounds, and perhaps had a few animations, would make more sense as an iBook. Especially as we now have access to the iBooks 2.0 platform which supports rich media content and has an easy to use authoring package.

So I wondered. And I looked. And this is what I found out.

Existing iBooks for kids are boring and overpriced.

  • Most stuff already out there uses iBooks pre version 2.0. This means you get a pretty basic eBook with pictures. A very few support sound and even some animation but it is a far from engaging experience.
  • The use of a standard eBook is a bad fit. The pages in kids books are often oddly sized and require lots of space for illustrations; you dont want simple text wrapping. As such, by default you will find that quite often the pages scroll from left to right as you flip the page, which is a pretty bad user experience. You can make both pages of a double page fold fit on the screen but you lose any sense of involvement and the book becomes letter-boxed and lost in the unused screen space.
  • Many publishes offer iBook versions of their paper counterparts. They are digital copies, plain and simple. Considering they offer such a bad experience its surprising that they are actually the same price as the printed media. One book in ‘real-life’ was a touchy-feely cloth book for 0-3 year olds with just 5 pages. Its iBook equivalent was still £4.99 yet its main function (texture) was obviously non existant!

The App Store is not the right place for books

  •  If you are looking for an engaging kids book in the real world you go to a book store, or at least the book section in a toy store. In the world of iPad it makes sense that people should go to the iBooks store but not necessarily the App Store.
  • But the iBooks store is newer than the App Store and its not installed by default. Yet.
  • Because the App Store is just there and because apps offer limitless possibilities for the user experience, many compelling kids books can be found on there. Except they are not books. They are apps. It just isn’t…quite…right.

iBooks 2.0 still isn’t a perfect fit

  • When you start to explore iBooks 2.0 and iBooks Author one thing becomes apparent: It was designed for text books. This should come as no surprise given the marketing push…but for me at least, it did. I was surprised to find that it so rigidly organises everything into chapters and sections. It does this to such an extent that the only kids books that I found that did use iBooks 2.0 have had to work around it.
  • Expecting kids to get the ‘pinch into and out of a chapter’ gesture is unrealistic. At least for small children. As a workaround the books I saw used a single iBooks chapter with a single section and titled various pages in that section “chapter 1″, “chapter 2″ etc.
  • There is no page flip animation. Sad. But probably more practical for tiny hands.
  • Landscape is where it’s at. Although iBooks Author supports both orientations, you are confined to landscape for navigation; portait is an optional extra.
  • There are still relatively few built in ‘widgets’. Because it is geared towards text books, if you want something a bit different you will need to write some code. Specifically you will need to create some HTML5 widgets in dashcode.


iBooks Author for iBooks 2.0 is the best there is. But it is still not as good as developing an app…and you will need to work around several issues. However, as iBooks continues to grow it seems like it should be the place to look for these kind of books that are heavy on rich media and…well, fun kid stuff.

I wonder then. If you want to create a compelling kids book that will be found by parents who are searching for such things: Do you create an app or a iBook? Do you need a developer or a publisher?

I think maybe its time to find out.


iBooks for Kids: Conception

I have been using the iPad to read on more and more lately. Maybe it was because of my new found love of the Kindle app, or maybe it was because I just wanted a chance to experiment with UIPageViewController…I’m not sure, but I decided to build my 3 year old his very own app.

He loves anything that makes loud sounds, flashes on and off and generally annoys the hell out of most normal people. In-particular he likes these infuriating books that have a single plastic button and play the same jingle over and over again. They are infuriating, in-part because of the sound, but primarily because the button is a single moulded enclosure such that when the battery dies you have to buy an entire new book!

So, after going through three copies of “row row row your boat”, and not wanting to add, yet again, to the growing pile of cardboard and plastic, I decided to turn all of his books (he has pretty much the whole series) into a single app.

Some scanning, a bit of coding and a few hours later I had an app that let you push the button and turn the pages, all courtesy of UIPageViewController and AVAudioPlayer. And best of all, when the battery runs out you can plug it into the mains and recharge it!

But that was just the start…

It struck me that maybe my approach had been wrong. After all, Apple had recently released the iBooks 2.0 platform with iBooks Author. It was designed specifically for rich media books. So maybe that was a better option? Maybe I could have got it all done with even less effort and produced something with even better results.

I looked into it. I became confused.

I’m going to follow this up with a post very shortly about what I found out and what it lead to. But right now, I need to go and draw a tree, and a spider, and a bird…and about half a dozen other things. I’ll tell you why shortly.