Bundle Diving In The WIRED iPad App.

I finally got around to downloading the WIRED iPad App today. My first observation was it was taking forever to download, initially I thought my internet connection had dropped out. A quick check of the App Store showed the download weighed in at a whopping 527MB! Surely there’s not that much content in the app? Adobe were charged with bringing WIRED to the iPad, so I was curious to delve into the app bundle, and see just what sort of technology they were using to generate this app. I wanted to know where it was carrying all that weight.

First observation is that the executable itself is small, only a few hundred KB. It’s clear that this is a clean slate project by Adobe. It doesn’t appear to build on any of their previous technology at all. In fact, as you’ll see, it’s a very simple implementation. More simple-basic, than simple-elegant at this point.

At its core the app is a simple XML driven layout engine. Content is split into “stacks”, each horizontal swipe in the app loads a new stack. Each stack has associated meta data such as title, description, tags etc. Each stack has an ordered list of “assets” which are essentially 1024 x 768 pixel static images of the pages which are displayed while browsing. So as you swipe vertically, you load a new asset in the stack. Also within each stack is a list of “overlays”. Each “overlay” represents an interactive component (hyperlinks, videos, audio etc) which is layered on top of a specific asset in the stack.

One question which cropped up almost immediately was how are they handling the two different orientations? The answer is simple, there are two versions of every single asset in the app. The asset list in each stack specifies separate resources for landscape or portrait view, as does the overlay list.

From all appearances this looks to have been put together relatively quickly by Adobe, like a matter of weeks. Not surprisingly, there’s plenty of room for future optimisation of resource usage. Creating a smarter layout system, incorporating native text rendering rather than the single image approach implemented now, could be easily added incrementally given the XML structure they’ve designed. There is significant resource duplication right now, hence the not insignificant download size. Refreshingly, this tool comes with none of the baggage associated with Flash, AIR, or other stale Adobe technologies.

Perhaps the most interesting thing to note is that there’s not a whole lot here which can’t be implemented using HTML5. But frankly, I think Adobe’s got the right approach here. HTML5 and CSS are far from baggage free. It appears Adobe could offer faster, painless route electronic magazine creation for publishers, a more efficient solution in terms of CPU usage and page rendering, and most importantly, the capability of offering superior integration with native operating system functions.

Finally, this isn’t something Apple will block. It’s a very specific solution, to a very specific class of application. Adobe could actually make something great out of this given some time.


124 notes


  1. design-for-tattoos reblogged this from laytonduncan
  2. clammytower39 reblogged this from laytonduncan
  3. laytonduncan posted this