Archive for the ‘Apps’ Category

Infinite Possibilities

Monday, July 16th, 2012

Strange as it may seem, there is no exclusive recipe to creating a great app. There is no company that has a monopoly on new-tech expertise. To my mind it merely takes three things: a great developer, great content and great vision.

The world is beset with great content by great content creators. To date this content has focused on TV, print, websites. Now the focus has shifted to handheld devices – smartphones and tablets – and so must the content. But it’s not the end of civilisation, neither is it a paradigm shift that many would have you believe, that only they have control over. It’s an adjustment to be sure, but put a touchscreen in front of the uninitiated, and you’ll see just how small that adjustment really is.

There is no exclusive recipe.

And once you have content, acquiring a vision is easy; want to create an interactive touchscreen experience that draws people in and keeps people talking about you and your product throughout the subsequent awards ceremony? See? Easy.

But you have no digital experience? No idea of how to mould your content into a product that impresses? No understanding of the current technology or what it’s capable of? This is where the third and final element, the developer, comes in.

And by “developer” we’re talking about people that actually eat sleep and breath the technology that they work with day in day out. Good developers know their market and their craft intimately. They know how to work with content providers to create great apps, the best ones have been doing it for years. They work hard to understand the needs of their clients, they hold the keys to interactive nirvana, and they know how to get the job done, with what technologies, for what audience, for the right budget.

Great developers are like great authors or designers. They’re professional, they work hard and compliment the team perfectly, and not only do they want to do a great job, but they want everyone to benefit from that great job. When it comes to learning and information cross-pollination, the opportunities for any company partnering with a developer, are huge, and far-reaching. Want to keep up to speed on new tech trends? Partner a developer. Want to know how to move from paper to iPad to Android, to include videos, websites, and social media in your game-plan, not just for this product, but across your organisation? Partner a developer. Want to create and learn and grow internally whilst keeping overheads low? Well, most developers simply don’t have many overheads, so it’s a no-brainer.

The world of technology may be complicated and unforgiving for some. For others, for developers, it’s just another day of infinite possibilities.

Developers need PR

Monday, July 9th, 2012

Us developers have a bit of a PR problem, and by “us developers” I don’t mean media agencies that hire in technical expertise on a per-project basis, that have marketing and sales teams dedicated to selling themselves and hunting down the next pay-check. I mean “us developers”, the guys that those other guys actually hire in, the ones that press the keys, think the deep thoughts and construct from nothing what people end up interacting with on their iScreens.

Traditional perception paints us as weird, socially-inept whizz-kids with bad hygiene, and to be sure I’ve met a fair few in my time. But, contrary to that popular belief (and to that of Hollywood – thanks Jurassic Park) the rest of us are just normal guys and gals, doing the same normal things that other normal people do. Visit friends and family, eat, sleep, drink, and for the most part, wash fairly regularly. The unfortunate thing is, much like my fellow developer colleagues, I don’t have a marketing budget to construct a campaign shouting about our normalcy, and I’m not sure anyone would listen even if I did.

We’re also, much like other creatives, kinda shy. We prefer to spend our time sat quietly focused on a screen, deep in thought, creating excellent apps, rather than going out schmoozing and playing golf. We also tend not to sing our own praises or throw such praises into other peoples’ faces, no matter how it would benefit us. We just tend not to be wired up in that “in-your-face” way.

BUT that doesn’t mean we don’t do excellent work, it also doesn’t mean we can’t work with clients, with designers, artists, authors, project managers in pursuit of that excellence. And it certainly doesn’t mean that if you find someone that doesn’t fit into the traditional developer “mould” that you are somehow compromising on technical excellence.

In fact, far from it. Some of the best developers I’ve ever worked with have been obscenely good at golf, been able to talk into the wee hours about non-Star Trek-related media, and can think of nothing better than working closely with a company and their designers to create products of inestimable quality for all concerned. I have even heard, from sources that prefer to remain anonymous, that some of us are even a pleasure to work with.

So when you look at your next digital project, try thinking about the potential that a partnership with a real-life bona-fide developer could bring. Think about the possibilities for both parties to learn and grow together, about the joys of collaborative overlap between your industry and theirs, and about the return on investment that a developer with very few overheads can bring to the party.

Who knows, it could be the most pleasant and mutually beneficial surprise you have this year.

Good development practice

Tuesday, February 14th, 2012

I’ve just finished reading Hunt and Thomas’ excellent Pragmatic Programmer for the second time. It’s been a while since I last had time to get my head inside development books, but it’s been kinda refreshing. Added to the fact that, for all the creating I do, it seems I’ve had to spend chunks of time recently working through other people’s code and doing my best to propagate best-practice principles.

I suppose it is a natural progression, particularly in such a young market. iOS development has only been around for a few years, and there’s still that buzz of excitement when anyone speaks about app development. It’s still in its cool phase, and it draws a many and varied talent base, a considerable number of whom this is one of their first main development in-roads. It has taken me the better part of 15 years to get where I am (wherever that may be), so it comes as no surprise that many of them can count the number of successfully completed projects on one hand.

There’s ability out there, there’s no denying that. But the problem lies not in the skill set, but in the timing. Apps are big business right now, and many big brands are pushing hard on the app wheel. The trouble is they simply can’t get enough apps developed quickly enough, there simply isn’t the talent to cover the work load, not by a long stretch. In fact, I’d go so far as to say that much of the world’s senior development experience is still doing what it has done for years, manning development teams, creating quality, best-practice code and locking it up in big business. After all, if they’re happy, and they’re getting paid, why should they alter the status quo? So the iOS app development market has no choice but to take on less experienced developers simply to keep up with the workload, some of which can work out very well for all concerned, but some of which can leave a legacy of pain for years to come.

Pragmatic Programmer has given me a chance to remind myself just how difficult this job is, how easy it is to make mistakes, head in wrong directions, and generally cause headaches for all involved. It is a fantastically educational tome, and I think if I were to employ any new recruits right now, I’d be looking for them to have read it, and be conversant with its key principles; orthogonality, Don’t Repeat Yourself, coding defensively, all seem second nature to those who have coded through the last decade, but the amount of iOS code I’m coming across that flies in the face of even these most basic of principles is simply staggering. The worst thing about this situation is that clients need to get experienced developers on such code just to keep it working. It’s crazy to think that some of the best talent in the industry are spending huge chunks of their time fixing this bad code instead of creating new apps.

Reminding myself of the contents of this books means I can at least do my part to pass on some of what it means to write good maintainable code for clients. And I guess we should always try to take the opportunity to pass on what we’ve learnt. Sure some of us might lose some work as the bad code that would otherwise need maintaining slowly disappears, but just thinking of all the great apps we could all be writing instead would seem like a trade worth making.

A Journey through the Exoplanets

Wednesday, October 5th, 2011

Sometimes you hit it lucky.

You find a great client, working with a great customer, commissioned to create a great product.; in the development world, the perfect triumvirate.

Journey to the Exoplanets on Apple’s iPad had the potential to be good right from the off. Along with my client Brandwidth, and their customer, Scientific American, this perfect triumvirate served to create an unusual level of expectation that, despite going unvoiced, managed to hover over our heads from the first line of code through to the final submission process.

It wasn’t perfection, I’m not even sure such a situation is possible, but it’s about as close as any project is going to get. The artwork was done with passion and intensity. The development was pushed hard by a design that in many respects went way outside the conventional app thinking. But perhaps most importantly, everyone involved, the client, the customers, the team, all saw the potential, and worked hard to realise it. People basically gave a damn, and for that to happen right across the board is rare. To get a chance to be working on such projects amongst such people is rarer still.

So it was of course a pleasure to work on. The design goals were met, and in many places exceeded. We all set out to make a great app that would blow people’s minds, and I think we did that in spades. Three months of ups and downs, trials, errors, backward steps and breakthroughs, all with a finished product to show for it.

I’d always expected there to be euphoria on releasing a product, particularly one that I’d built myself from scratch. In this case it’s actually more sadness than anything, good things have to come to an end after all. Possibly the hardest thing to reconcile is that, from now on, I’m going to have such high expectations with everything I touch. Is it really possible to hit a home run twice in succession?

As a final note, a quick thank you to the guys at Brandwidth and Scientific American. These last few months really have been an absolute pleasure, and I look forward to breaking expectations together again in the future. And of course a big shout out to Caleb Sharf ; having the assistance of the Director of Columbia University’s Astrobilogy Center really did push the Planet Builder above and beyond.

Update: some great reviews are coming through for the app, so feel free to check out the article on, as well as a great review by author Greg Bear on

Time and Tide

Wednesday, March 23rd, 2011

I have absolutely no idea where the last five months has gone. One minute I’m starting a new iPhone app for DigitalOrigins, the next I’m in an office in Waterloo doing work for Mobile Interactive Group, all private projects forgotten, blog left on a shelf to gather a thin layer of dust.

What’s really crazy is there was still time to eat, drink and sleep in amongst everything else going on. I’m kinda glad really.

Many contracts start as a trial by fire, and the first week with MiG was no exception, finishing up an I’m a Celebrity iPhone app for ITV that unfortunately never hit the app store. It got close, but politics got in the way and it didn’t materialise. A shame, it was a great looking app and had some very cool streaming and voting in it that would have made for a perfect mobile companion to the TV show. But alas, these things happen.

Not all was lost and much of what I ended up learning on this app made its way into Sky’s recent Got To Dance iPhone app. We were lucky with Sky, they were very happy to go with our first set of designs, helping us to help them get the turnaround they wanted. i.e. really really short. It was definitely worth the effort though; the app did well in the App Store Entertainment charts, and the levels of user interactivity for each weekend show were fantastic. It seems people love joining in to vote for their favourite acts through the associated iPhone app. You wouldn’t believe the amount of work behind the scenes to make sure it all ran smoothly week-on-week, but aside from one small hiccup at the start with the CoveritLive stream, it all worked like a dream. A great app to work on, and a great outcome for a great show.

Interspersed in amongst all of these comings and goings was work on the Find a Property app, generally shoring up a rather complex codebase (not entirely surprising considering the project has been passed around several companies before it graced my screen), and adding some cool features to enhance a pretty respectable iPhone app. Hmm, actually I’m underplaying that somewhat, after all it did get onto the Sunday Times Top 500 iPhone apps list.

As did Ministry of Sound’s Ultimate Ministry of Sound app, another project I was lucky enough to have cross my MacBook screen. This app does it all; live radio, ticket purchasing, news, features, video streaming, iTunes track purchasing, there’s really not much missing. If you love dance music, it’s a must-download. I placed my mark on several versions submitted to the App Store before finishing with MiG, the same with Find a Property, before moving on, and it was a pleasure working with MiG, The Digital Property Group and Ministry of Sound (and ITV and Sky of course) pushing everything through efficiently and professionally, as you’d expect with such high profile organisations.

So I’m now back from the Waterloo offices in London, with a short holiday under my belt, ready to push forward again with DigitalOrigins work, as well as that of other clients’. Oh, and the website. I really can’t believe how long it’s been since I’ve touch the website. Just to keep me happy, go check out the apps I’ve been working on, and download them at your leisure. I’ll thank you, MiG will thank you, aww heck, you’ll thank yourself once you have them on your phone. They really are rather good.

Busy is as busy does

Thursday, October 14th, 2010

Apple caught me on the hop today. CapitaHD, the iPad version of the pleasantly successful iPhone version, Capita, was submitted to the App Store a week or so ago, and on recent experience I wasn’t expecting any sort of response for at least another week. Time, I thought, to tie up some loose ends, tweak some other projects, update the website and be ready for the green light.

Well, I’m not complaining. Their processes have proven as swift as they are true, and CapitaHD is now available for download on what has now become my most prized of household gadgets. If I had to choose between the laptop and the iPad, it might be a close-run thing. Even the kettle and toaster would be on shaky ground despite the usage they both get.

It’s actually been a tough birth this time around though. Not because of the technical light-bending that goes on to get these things done and out the door. In that regard it has been quite the contrary; moving everything over from the iPhone version actually went surprisingly smoothly, the additional screen acreage proving to be such a blessing for the gameplay that I actually ended up adding more polish just out of sheer adoration. No, the creation of CapitaHD just happened to come at a time when time away from work kept popping up (Rome is a delight at this time of the year incidentally), and contract proposals were being penned and meetings had. It can all put a kink in an otherwise extremely productive production house. Fortunately I now have some hugely-appreciated help in that regard so the delays should evaporate into the ether, or so I have been told. Not quite soon enough for CapitaHD to become my first (and hopefully only) victim of circumstance, but welcome nonetheless.

Of course the other knock-on effect of being away is not having been able to put pen to virtual paper. It’s easy to say that the travelling around shouldn’t make things hard when it comes to things like blogging, but, much as I love the iPad, when it comes to pulling together a post, the limitations of the little terrier come ripping round the corner like they’re chasing guinea fowl. Even using my bluetooth keyboard, much as it improves raw text entry, doesn’t do anything to allow me to efficiently cut/paste links, upload images, research notes… The long and short of it is, as soon as anything complicated is required, the MacBook gets fired up, with its trusty mouse, and fancy windowing shenanigans. Not even multi-tasking will change my mind; all I want from Steve Jobs for Christmas is to be able to turn it off on my iPhone. /stares forlornly at every single app permanently running in the background.

Anyway, CapitaHD is available now, so if you fancy a jot of 80s gaming nostalgia, or are looking for a strategy game that’ll work your brain harder than most, go pick it up. Or if you want to find out a bit more about it, you can always head here. And of course don’t hesitate to drop us a line at, or in the comments section should you feel the need. Don’t be shy, we don’t bite.

iPhone Audio – Part 1, an exercise in patience

Wednesday, September 8th, 2010

This last week or so has seen head firmly buried in audio code on the iPhone. Well, actually the iPad, but it all comes out the same in the wash.

My inspiration, aside from having done little more with the iPhone other than bleeps and bloops, was the Tenori-on. Now I didn’t know anything about this funky little piece of kit until I saw Jonathan Coulton using one rather expertly at a concert in London a couple of years ago. Apparently it’d been around a while before that, unbeknownst to me. For anyone that hasn’t seen one in action, check out a couple of vids here and here.

Rather than spending a cool grand, I hit up xCode to see just how capable the iPad was at replicating what the Tenori-on could do.

My earlier aural experiences with iPhone have focused solely with OpenAL, simply because it’s easy, it works, and getting it into a game using the plethora of example code and documentation is, to be frank, a breeze. We like OpenAL. The drawback to OpenAL is the lack of control you have over your sound playback. It will do what it wants, when it wants, and how it wants, irrespective of your potentially tight requirements. Fine for a game, not so much for a musical instrument. Besides, at some point there’s going to need to be pitch-shifting involved, so there was always going to be a need access to the sound data itself if I wanted to replicated the Tenori-on’s functionality.

Next up, Audio Queues. Now this is where things start to get interesting. Setting up audio streams and filling output buffers with data manually via callbacks is nothing new, my years of using Microsoft’s DirectSound have gotten me comfortable with such mechanisms. The addition of timeStamps meant that I could set a queue playing, knowing that it would only actually trigger when the timeStamp told it to. Kind of fire-and-forget. Quite neat actually.

The drawback to Audio Queues comes when you want to change the pitch of the notes you’re playing. You can do it when you set a queue up, by simply changing the playback frequency, but only when you set the queue up, not whilst it is in use. So fine, set a queue up, play the note, and delete the queue ready for the next, right? Wrong. Because when you delete an Audio Queue it disrupts the DSP in the iPhone, so if you have any other sounds playing at the time, you get a glitch. The more queues you start and stop, the more glitches you get.

The other issue is, the more queues you create, the slower the playback gets. And by “slower” I do mean “slooowwwweeerrrrr”. A six-note piano chord starts sounding like a guitar strum despite the existence of a timeStamp. Add another couple of notes and you have a significant (in musical realms) amount of time between the first note of a chord and the last. So you have a choice: it is possible to have glitch-less playback but suffer from Audio Queue overload, or you can glitch after every note. Each as unsatisfactory as the other, and both suffer from latency issues when playing back large numbers of voices at a time.

Our only solution lies in the lowest of the low level, Audio Units. Now contrary to popular opinion they’re not actually orders of magnitude more complex than Audio Queues; they still have callbacks and you still have to fill sound buffers manually. The biggest issue with Audio Units is the setting up; they are darned finicky and give little-to-no constructive feedback if you get things out of alignment. Actually, on second thoughts, perhaps I’d better reassess; the biggest issue with AUs is not the setting up, no, the biggest issue with AUs is the considerable lack of clear, concise, descriptive documentation and example code. Admittedly if you want to do exactly what is documented in the way that it has been documented, you’re rocking, kinda. But if you want to step off the beaten track even an inch, and bearing in mind the simplicity of what is documented, you can be sure you’re going to want to at some point, you’re pretty much on your own. Hopefully Apple will make amends soon, but until that time, you’ve got to be brave.

To be continued in “iPhone Audio – Part 2, an exercise in bravery”.

Developers as gaming entrepreneurs?

Friday, September 3rd, 2010

There was a question thrown around recently that made me think about my own situation: why do developers seem to be less interested in a career as gaming entrepreneur?

Having spent the last couple of weeks getting Capita onto the iPad, as well as digging my way through the iPhone Audio Queue mire, I think I kinda understand why. The work that we do is, for the most part, utterly absorbing. People talk about “flow” as being something that developers need in order to produce their best work, and when coding, it really is an intoxicating brew. The inevitable downside of flow however is that you can be starting the week reading about buffer sizes, callbacks and latency, and the next time you look up it’s a week next Tuesday. Very bizarre.

And actually particularly problematic when it comes to anything business-related. If you’re running your own show, more often than not you simply can’t afford to be “somewhere else” mentally for that length of time. There are typically too many things that need doing yesterday, be it contracts to chase, accountants to appease, lawyers to pay, and all are eager to destroy the flow that is so carefully cultivated and so ruthlessly defended.

Now I’m reaching the end of both projects I get a chance to sit up and look around, stretch the legs, and put some words onto the screen more of an English bent, a rather pleasant side note to the developing. But the more time goes by, the more I’m starting to think I’m more of an exception than a rule. When caught up in the rush of development, I just don’t think that, for many coders, much else matters, which is why many are only too happy to avoid branching out and away from the work they love.

And the development community is probably all the richer and more productive for it, although I have to say, right now, I think many of us are wondering where on earth the summer went…

Mobile exploits with BoulderDash

Wednesday, August 4th, 2010

ScreenGrabIPadBD copy.png

When I started iPhone development, the learning curve was relatively shallow; I knew Mac development well enough, and ten years of writing games and tools gets you knowledgable about a whole host of languages and technologies from C++ and DirectX through to 3D engines on the XBox and file converters in Perl. But these handsets are different in a host of ways, and I’d never touched OpenGL before.

To get myself up to speed writing on the iPhone and the OpenGL graphics pipeline, I looked to my gaming past to find something that I wanted to play on the handset. That something ended up being BoulderDash. I grew up playing it on the Commodore 64, and still love it now, there just wasn’t a perfect version for the iPhone. It ended up being a great project to start from scratch, and actually, a great one to finish. It was a real labour of love, never intended for release, which is why it used all the sounds and graphics straight from the c64 version, but boy did it turn out well. Not only does it play identically to the c64 version, it even came with a persistent level unlocking mechanism as well as a high-score / fastest times table. Very neat indeed.

I started iPad development shortly after they arrived on our shores. The iPad and iPhone share operating systems (give or take a few tweaks), but I thought it worth taking something I’d developed for its smaller cousin and porting it across to get a feel for the issues. The perfect candidate? BoulderDash. First on the iPhone, and now first on the iPad. Quite fitting I thought.

I was struck by a few things. Firstly, how quick and easy it was to get an already completed iPhone app up and running on the new hardware. I guess the sharing of the OS helps, but still. The only major issues in fact were the ones you’d expect: the graphics were too small, and the screen layouts broken. It took me roughly six weeks to go from zero to a complete ready-to-release version of BoulderDash on the iPhone, but approximately 3 days to port it to the iPad up to the same standard (along with a few additional bug-fixes along the way). That’s very cool indeed.

The other thing that struck me was just how exquisite the game actually looks and feels on the bigger screen. I really do love the iPad, and there’s some great games for it, but to create something yourself and see it rendered in such finery really is something else. So much so that I’m actually considering releasing it under DigitalOrigins in some form. Even if I have to replace all the sound and artwork and change the name to something like DiamondRush (which I actually rather like), I think it would be worth having this in the hands of people so that they can get some enjoyment out of it.

Perhaps now is the time to commission some artwork. Anyone up for the task?

How an iPhone App gets developed

Tuesday, July 20th, 2010

It is often said that ideas are ten-a-penny, that development is where the real magic happens. I’m not sure things are quite so black-and-white, after all I’ve known some pretty magical ideas (and their owners) in my time, but it is definitely fair to say that some magical development can turn something humdrum into a major-league hit.

But behind the scenes, what makes the magic happen? How can a company like DigitalOrigins turn an idea into a killer App?

First off, we like most companies, brainstorm an idea with a client and mould it, poking and prodding until we understand everything our client is aiming for. Here it’s about aims, not techniques; as long as the aims remain true, the techniques can be whatever is required to get the job done. Once the aims are understood, we start on a simple design and prototyping loop to help contextualise those aims and bring them into something that the client can actually experience. Here we’re simply creating bare-bones interfaces and workflows to illustrate areas of contention, and generate simple movement through an App giving a feel for what could be expected at completion. Things not feeling quite right? Back to the design phase. The idea not quite as strong as expected? Tweak the idea and adjust. As any professional developer will be able to tell you, getting aims and objectives right here, saves time, money, and a whole heap of heartache later. By the time we’ve reached the end of this process, we are in a great position to make time and cost estimates and draw up a general development plan.

Now some companies move onto full development fairly early in this design phase, preferring to hone and adjust details and timescales whilst full-scale development is in progress. These agile-focused companies tend to prioritise the maintaining of close ties with the clients, working alongside them on a short but regular basis to ensure that the design matures over time like a fine wine, and as new features are designed and implemented, they are demonstrated, discussed and adjusted where necessary alongside cost and timescales. I personally like this way of working; it builds trust early on in the development cycle, and lays the foundations for strong communications and relationship-building throughout the project, two major features inherent in any successful contracting project. The drawback is that the cost-estimates and development plan become less black-and-white, only natural when building in the ability to adjust mid-flow. My experience has shown though that the additional transparency and flexibility more than makes up for this rather more “fixed” planning process, even if it can be somewhat less predictable.

Whichever way the company chooses to work, the development phase is where the aims, the design ideas, the code and the artwork are all brought together piece by piece, tested, demonstrated and added into the coherent whole, building the core app up slowly over time. This is a good time, a time of communication and sharing, a time of changes, adjustments, of iterating, but of ultimately moving forward and creating something special. I have yet to find anyone that didn’t get a buzz out of this phase; being able to create something out of nothing with a client really can be a rather invigorating process for all involved.

Once iteration has produced an app that hits all the aims (adjusted and tweaked where necessary during the development phase), the product is nearing release. For most development companies this is the application’s Beta phase, the phase where the app is poked and prodded from all directions, squeezed over and over to force bugs from the system. For some it is also an opportunity to add polish, to add speed where necessary, to add that final layer of gloss that turns a good product into something great, all before sign-off and handover take place.

And for many this is the ultimate goal; completing Hogs of War for Infogrames simply saw the handing over of the gold-master followed by a project post-mortem before moving onto the next project. For others this is just a step along the overall project lifecycle; NavisWorks saw this sign-off process as simply a gate to move through prior to further design, development, testing and release iterations. With today’s electronic distribution, particularly with the App Store enabling ongoing feedback and bug reports, as well as bug fixes, additional features and further releases, all within relatively short timescales, it makes sense to have this milestone as a more open-ended project goal. But at some point the first release must be pushed out, to the clients, to the public, and this is where it happens. Simple.

To some it may seem like a rather complex process, but actually, when working with a good professional software company, one who wants to work with you rather than just for you, much of these elements are managed behind the scenes, and, from a client’s perspective, the whole process can tend to flow rather gracefully. I’ve worked with many companies over the years that have marvelled at just how smooth and efficient the whole process can be. The key? Work with someone that knows what they’re doing, someone who wants to work with you not just for you, and someone that has a passion for making something that’s great, rather than just making something.

As I’ve always found, follow those three elements and you really can’t go to far wrong.