The iPhone 4S

I've had an iPhone 4S for a few weeks now. It's unusual for me to get a new phone this soon after its launch. I took the plunge this time mainly in order to diversify my development devices. I plan to keep my old 4 on iOS 4.3 for compatibility testing and use the 4S as my main dev device — as well as my everyday phone.

There's not really much left for me to say about the 4S which other people haven't already said. Like Marco Arment, I can't say I've really noticed much of a speed improvement. This probably says a lot about the power of the iPhone 4. Certainly on paper the 4S should be noticeably faster. I usually shy away from having the fastest device available as my day-to-day development device from a — more than likely misplaced — feeling that by not having to worry about performance I end up writing inefficient code. I guess it's hard to shake my assembly language roots.

I must admit that I haven't got much use out of Siri so far. We had fun with it — I'd love to say 'she', but over here they've made Siri a bloke — over lunch one time, but that's about it. I guess I just feel too self-conscious talking to my phone.

And the only other new stand-out feature of the 4S over the 4 is the rattle somewhere at the top of the device near the mute switch. But I'm not sure that's a standard feature.

On Creativity

I've been an Apple fanboi since back when the company was doomed. Up until the mid-90s I'd been an Atari fanboi. You can guess how big a fanboi I was by the fact it took until the mid-90s for me to finally accept that the platform was dead and that it was time to jump ship. I bet I was one of the very few people to ever own a Falcon030. While I started playing around with programming on the BBC and Spectrum, it was on the ST that I really cut my coding teeth. When I got my first Mac — a PowerMac 8200/100, since you ask — I also got Code Warrior. I made some half-hearted attempts at learning the Toolbox, but somehow it wasn't quite the same — maybe what was missing was that magic which came from knocking around at the assembly level with a single, well-known hardware platform. It wasn't until several years later and Xcode under OS X on an iBook that I really got back into programming, and then what drove me wasn't so much the technology as the community.

"Style over substance" — or something with similar connotations — has been the default insult levelled at the Mac since the beginning. Variations of it were used time and again by detractors to describe the applications available for OS X, especially during the rise of the Delicious Generation. The Mac couldn't host anything like the extensive software catalogue of Windows — especially in wake of the platform's abandonment by most of the big name companies which had previously supported it — but what it did have was a number of well-made applications from numerous small independent developers. Indie developers were craftsmen, and this was reflected in the thought, the time and effort, which went into producing their products. This was the community I wanted to join.

I never did, of course. Time and circumstance conspired against me. The challenges involved in first creating, and then marketing, a product seemed too great, and I shied away from them. And then the iPhone was released. At first, the connection between this amazing new product and the Indie community didn't exist, but eventually the SDK was released and the App Store opened — and the independent developers who had supported the Mac for all these years were there at the front of the queue.

Despite the many stories of small developers striking it rich over night, I never really imagined that I'd be able to produce a smash hit app. I knew that to do it properly I would need to work with others who would fill the gaps where my skills were lacking. The couple of apps I made were to back up my claims of being a proper grown-up developer. I made a few false starts at finding collaborators online (to my eternal shame, I managed to mess a couple of people about, as well as getting messed about — and royally screwed-over — myself), but eventually I gave in and went for one of the many suddenly flourishing iPhone developer jobs.

(I have to thank Steve Jobs, not only for creating tools which I want to use above all others available, but — most of all — for creating the environment where people will actually pay me to use them. It was almost impossible to get a job as an Objective-C programmer in the UK before the iPhone, but now — even today, a couple of years on — there is still a growing demand.)

I had hoped to join a team where I'd be part of the creative process, joining in the back-and-forth and contributing. In the main this has happened. I've worked with some excellent creative people, and — since being subsumed into the world of advertising — some excellent Creatives, but I can't shake the feeling that I've always been the junior member, there on sufferance, tolerated for their technical knowledge but otherwise to be seen but not heard. In short, that I wasn't creative like those others involved in the design process. (One colleague would constantly make comments along the lines of "…even people, like you, who aren't creative…" — they cut me every time.) Sure, I didn't have any formal creative training, but then I didn't have any formal programming training, either.

I guess that there's a broader question here: Is programming a creative endeavour? Certainly it's creative in that it is the means by which an end product is created. But how much creativity goes into that process? I realised a long time ago that as far as my creative colleagues are concerned, the answer is none — that all I do is basically typing maths. (In a particularly grim low moment I changed my job description on the office intranet to read "Typist".) I'd argue against this. While programming is ultimately a form of engineering (although this is mostly an American affectation, nerds who sit in chairs all days wanting to be classed with the guys who get to wear hardhats and build bridges), that doesn't mean that it is rigid and inflexible. The skill — the craft — comes from choosing the best, most elegant solution to the problem at hand. If not an artist, I am, at least, an artisan.

I got into a minor Twitter tiff with superstar designer Sarah Parmeter at Update Conf. As part of her presentation she told a story about talking to developer friends about what the iPhone could and couldn't do in terms of sending SMS messages, and suggested as one of her top tips that designers should find out about device capabilities. I expressed surprise on the back channel that any designer should need to be told this. But, looking back, I shouldn't have been surprised at all. Too many people involved in the design of apps seem to see discovering the abilities — and, more importantly, limitations — of the devices they're designing for as some kind of check on their creative freedom. (To be fair, at the moment this seems to be more prevalent among the ranks of mangers who now seem to be charged with designing apps — wire framing, as if this were some unimportant step in the design process — than with any of the actual big-"d" Designers I work with.) This strikes me as being akin to a sculptor not being interested in discovering the various contrasting properties of marble, brass and wood. And it casts the developer, who has to step in and say no, this can't be done, in the role of killjoy naysayer.

(And we now reach the point where clients are unwilling to pay for app design time, so could we put everything that their web designers need to know about designing for apps down in an email, thanks very much…)

Anyway. Sorry. Another unfocused rant. Tomorrow I hand in my notice. After than I contract for a while. And after that — if the comfort of contracting money and the fear of failure don't get the better of me, which there's a very good chance they will — I'll start up a development shop of my own. Maybe I'll be able to convince some of my Creative friends to come and join me. But I have some strong ideas of my own about app design, and I'm not sure how palatable they'll find them.

Boots Treat Street Trolley Dash

Another thing I made at work. Pink, isn't it?

This was the project I was using Corona for, as mentioned previously. So technically this is also my first ever Android app, although that side of things was really an afterthought — and a whole world of hurt with it.

The project had originally been pitched to the client as a Tiny Wings clone (because original ideas are hard), but it ended up more closely resembling Canabalt, with the simple tap-to-jump mechanics. Only the zoom-out on max height jumps remains to hint at the original 'inspiration'.

Graphics were chiefly the work of m'colleague Chloe (with sister Rosie helping out on faces). Trivia for the day: Chloe also provides all the vocals. One day I will set up "Naughty Doggie!" as her new e-mail alert sound.

A Few Thoughts on Cross-Platform Development with the Corona SDK

I'm writing the first draft of this on a train, heading — by an admittedly circuitous route — for Update Conf. As part of the programme we'll be treated to a presentation on using the Corona SDK for cross-platform (iOS and Android, although I believe there are rumblings about Windows Phone 7 support) development. Since I've just (almost — flipping clients) finished a project using Corona, I thought now would be as good a time as any to reflect on the plus points and pitfalls I found while using it — if only to get straight in my mind whether, when I run into Ansca'a representative, I should offer to buy him a drink or give him a slap.

The obvious first question is, Why did I choose Corona? The project — a fairly simple game for a major high-street brand, which hasn't gone live as of the time of writing and which I therefore cannot name, so well call it Basket Bash for now — needed to be developed for both iOS and Android in a short time frame (or at least, that was the original intention. Our deadlines have a habit of slipping…). There was also going to be a certain amount of design iteration along the way (meaning that we didn't actually know what we were making when we started. Again, standard operating procedure). After wasting some time trying to put together a simple 2D GL engine of our own, I gave up and started looking for something a little higher level. Cocos2D was considered, since there is now an Android port, but this would mean writing two versions of the game, one in Objective-C and the other in Java. What we really needed was a write-once solution, and this is what Corona ultimately offered us.

So would I recommend Corona? With certain reservations: yes. Much as I enjoy writing code just for the satisfaction and challenge of it, there's a lot also to be said for simply making stuff, and occasionally limiting or inelegant as it is, Corona generally gets out of your way and lets you concentrate on doing just that. The development language is Lua, which if you've never used before you'll find is simple, easy to pick up, and does just about everything you need it to do with a minimum of fuss.

My main reservation in recommending Corona — probably because I was bitten by it only very near the end of development and so the memory is still painfully raw — is Android device support. As of a few months ago, Corona does not support Android devices running ARMv6 CPUs. As of only a few weeks ago, this was not mentioned anywhere obvious in the documentation, such as alongside the Android v2.2 requirement. Since ARMv6 phones include the HTC Wildfire S, apparently the cheap handset de jour which I'm seeing advertised just about everywhere at the moment, this could be a problem. (I'll admit that I share the fault for not discovering this earlier. When builds wouldn't install on our test Wildfire, I put it down to a combination of un-optimised assets and my inexperience with Android. If I'd taken the time and dug deeper I would have found this enforced limitation — which at that stage would probably have lead us to abandon Corona, although for what alternative I have no idea.)

My other reservations probably come from the way the Lua runtime is implemented. Lua has a rich library of code available to it, but Corona will not work with any of the many binary libs. In our case, this lead to us having to abandon interfacing with a web service using AES encryption. In general, you are restricted to whichever advance features the development team have included and exposed. This includes OpenFeint, Flurry, and an older version of the Facebook Connect library. For Twitter or Facebook using OAuth you'll have to roll your own solution (unless I decide to share mine…). There is support for a selection of native widgets, although this is naturally less fully-featured than that available through the native SDKs. I have yet to attempt to use Corona to build an app with a native UI look and feel.

Be warned that debugging can be a nightmare. The SDK comes with its own simulator, which simulates the differing screen sizes of iPhone, iPhone 4, iPad and half a dozen Android devices. (You'll probably find that supporting different screen sizes is the biggest challenge in cross-platform development. Corona is pretty helpful here, if you're willing to cede a certain amount of control. It offers a number of content scaling modes and supports automatically loading assets based on the scale factor between an arbitrary content size of your choosing and the actual screen size of the device. This is basically the iOS-style @2x, only far more flexible, allowing you to specify many different asset sizes.) The simulator provides console output and a debugger. It cannot, however, run native UI widgets such as web views. For these you will have to build the project for either the iOS simulator or a handset. Which is where things get complicated. I've been unable to get console output from any of these devices. You think debugging with printf() statements is fun? Try debugging with pop-up alerts.

Builds are carried out on the Corona servers, meaning you need an internet connection at all times. For Android that's all you need (saving access to the SDK later to allow you to create a distribution key pair), but for iOS you'll need Xcode 3 installed. A paid subscription is technically only required to build App Store or Market versions of the final app, but I'd probably recommend getting it as soon as you've decide to commit to Corona, since it also gives you access to the daily builds, which in my case fixed a few compilation problems I came across.

In general, I think Corona is a great system for doing a certain subset of cross-platform development. It has the enormous potential to allow you to quickly assemble and test projects and deploy them for both iOS and Android. It's probably not a good fit for apps — as opposed to games — although I say this more out of the opinion that native apps should be built with native SDKs, rather than any kind of hard-won experience. If you are aware of Corona's limitations and manage expectations accordingly, you should find using it to be an incredibly productive experience.

Everyone Else has it Easy

I forget what we're blaming for diminishing attention spans these days. Is it still television? Or have we shifted the blame on to Twitter yet? Are we even still decrying the general inability to concentrate on one thing for more than a few minutes without our minds wandering, fingers and eyes not far behind, or is it just taken as a given that anything more substantial than bite sized chunks will go untasted?

I'm a writer, and those who practice every single other kind of artistic expression have it so much easier than I do. Among the finger painters designers I work with, Dribbble is becoming more popular. I am deeply envious of both it and them. I wish I could get feedback in a similar manner. Images lend themselves to quick inspection and comment. The visual is visceral, it elicits an emotional reaction (or lack thereof) immediately. Sure, a great first line does the same, but then you've got to follow it up with a second, and a third, and keep going until you've got where you want to take the reader. And let's face it — reading takes a lot of time and effort.

It's often been commented on on Writer's Cafe — my sometimes literary haunt of little choice — that the only writing that gets reviewed is the poetry. This isn't surprising. Poems tend to be short, hardly more than a single sparsely-covered page, and therefore quick to read, to form an opinion of, to finish with, sum up, and move on. (It doesn't help that the site is populated with writers — rather than readers — but that's another complaint.) There are few art forms which require such an investment of time from their consumers as the written word.

I publish the few things I write in order to get feedback so that I might become a better writer. I write short fiction because it allows me to experiment quickly, and I had hoped that the shorter form would encourage more reading and more feedback. That doesn't seem to have happened. So what's the solution? Simply, to go long. My one full-length piece of work has received more downloads — paid downloads, no less — that all my short pieces together. I'm sure there's some interesting psychology at play here: maybe by taking the time to publish to a store, and make the decision to charge, you're signalling to the potential reader that what you've written has value and is worthy of their precious time.

Maybe. Whatever. So it looks like I'm bringing my plans forward, skipping over the remainder of the learning to write through dozens of short stories part, and going straight to the first novel. Well, probably a novella. Let's not go crazy. And maybe I should actually write it, rather than writing about it...

A Quick Walk

I went out for a quick walk yesterday. Since my new route home from work has been taking me over the canal at the edge of Regents Park, I thought I'd take the time to have a wander and explore it. I headed west, arriving after a short while — and a single, rather confusing detour away from the canal side — later at Little Venice.

There I left Regents Canal curving southwards and followed the Grand Union further west, passing this collage / mural along the way.

My target was an intriguing patch of green which had previously leapt out at me from the map. Named "Meanwhile Gardens", it of course couldn't hope to live up to its name. Long and narrow, like most areas of communal land in London it featured rough tracks meandering through green hummocks. There was a concrete bowl of a skatepark, various assemblages of adventure playgrounds with swings and climbing frames, and a series of stagnant ponds, falling in steps of thick green weed. There was also this handy plaque, showing you where you were — spatially, in relation to the planets, and chronologically, in relation to the dinosaurs. Handy.

I followed the tow path further west, to the next easy exit point, which happened to be close to Kensal Green cemetery. Now, say what you like about the Victorians, but they certainly knew how to do death. The weather was just on the wrong side of bad for it to be really atmospheric, but there was a pleasing dampness in the air which leant a spring to the dark, pine-covered earth and brought out the green of the moss coating the granite tombs.

Then it was down Ladbroke Grove — somewhere I know chiefly through the writing of Michael Moorcock, and which had until then been as unreal to me as Tanelorn — and then home.

"The Worlds of Mervyn Peake"

The British Library has put together a small exhibition, The Worlds of Mervyn Peake — about a half dozen display cases against the far wall of the Library's cavernous atrium — to celebrate the author and illustrator's centenary. It presents a chronological tour through Peake's eventful life and work — from his early years in China, his work as a war artist, his time in London and as member of a artists' commune on Sark — using material including his own workbooks and correspondence. The later includes a few surprises, including a firm-but-fair assessment of the first draft of Titus Groan from Graham Greene, and a note from Caitlin Thomas wondering if Dylan couldn't borrow a decent suit.

I must admit that I knew little about Peake beyond Gormenghast, so the emphasis placed on his drawings came as a surprise. His work immediately after the Second World War, including sketches of those he found in Belsen, are particularly moving. Other parts of his work, such as his illustrations for an edition of Alice in Wonderland, I found a little disappointing — in this case, although technically brilliant, I thought they were a little too like the more famous ones by Tenniel. The sketches to the left come from an idea he had for a television programme which was never produced.

In all, well worth a look, whether or not you're familiar with Peake's work.

Garden Barge Square at Downings Road Moorings

If you've ever ventured down to the south side of the Thames just east of Tower Bridge, past the Design Museum, you can't have failed to notice a cluster of long boats and barges, sprouting intriguingly incongruous greenery, moored there. This is Garden Barge Square, and for years it has held a casual fascination for me as one of those private-but-in-plain-site parts of London, there for all to see but non-the-less inaccessible. Last month, as part of the National Gardens Scheme charity open day, the veil was lifted, so I went along to have a nose around.

I'm sure that it would make a wonderful setting for a scene or two in one of the London Novels which I'll probably never get round to writing. In the meantime, the sensation of standing among a traditional English cottage garden, with borders full of rose bushes, while being buffeted by the swell of a passing tourist boat, will stay with me for some time. I don't think I've ever felt seasick in a garden before.

Timesink Tower

I've been spending a stupid amount of time over the last couple of days playing Tiny Tower (thanks, Chloe, for introducing me to it. I must find some way to repay the favour...) so I thought I'd write up a quick analysis in a futile attempt to pretend that all those hours haven't been completely wasted. (And also because, due to my current project at work, I've been spending quite a bit of time recently thinking over what makes a game addictive and fun.)

The first thing to note is that Tiny Tower isn't a game. There is no way to lose, no "Game Over" state, and although you can make progress — we'll see how important this is in a moment — there is no way to win, to beat it. Instead, Tiny Tower is an entertainment, in the Farmville mould.

Gameplay (yes, I'll still call it "gameplay", despite the proceeding paragraph) is simple. You build a tower from either residential or business floors. "Bitizens" live on the residential floors and are assigned jobs in the businesses. Each has a set of stats matching their skills against each of the categories of business. Matching a bitizen with a job they're good at makes them happy — which I presume increases their efficiency somehow, maybe with faster restock times or better sales, I haven't been able to tell which.

There are two currencies employed in the game. One is coins. You use this to buy stock for the businesses and to purchase new floors for your tower. It's generated by the businesses selling their stock. The other currency is towerbux, and it has a far more insidious role.

It's perfectly possible to play Tiny Tower without ever using towerbux — but it would make for a slow, tedious process. In short, what towerbux do is they make the game fun. You pay towerbux to shorten the drawn-out processes of building floors, of restocking businesses, and of selling that stock. Sure, there are occasional bonus lift users who will perform these tasks, but their random appearances cannot be relied upon. (And, yes, you can leave the game and come back later to see how things are going — the app giving the appearance of running in the background — but that isn't the point.)

You get towerbux in one of two ways. The first is as a — often random — reward for performing some task, such as locating a bitizen or taking someone up in the lift, or as a bonus when purchasing a new floor. The second is by buying it through in-app purchase. Yep, we're in the land of freenium here.

So while you're playing the game — while you have the app open in your hand — what will you be doing? A small amount of your time will be spent on hitting the buttons to order more stock for your shop, but most of it will be taken up by pointless make-work tasks, predominately moving bitizens about in the lift. You earn a small amount of coins for this, but ultimately all it is doing is providing you with something to keep you busy while you're waiting either for some long task (restocking, building) to complete, or while you're waiting to earn enough money to buy your next floor.

So why have I been playing it so much? Why have I checked it a dozen times during the writing of this piece? Why will I continue playing it for the rest of today, and probably get caught checking it during work tomorrow? I wish I could put my finger on exactly what it was. There is a satisfying sense of achievement as you hear the money clinking in and watch your tower grow. There's something which makes you want to see what you can build next. There is something, ultimately, rewarding in the experience.

À la Recherche this Japanese Pupet Thing from When I was a Kid

Among the seemingly random collection of memories of my early years which have stuck with me are brief fragments of a TV show. It was SF, performed with puppets, and very definitely Japanese in style (although I wouldn't have recognised that at the time). There was a big red robot which was formed when some spaceships combined. My most abiding memory was of some bearded guy being killed by a space bug — I think this carried an emotional impact, which would explain why it stayed with me. For years I tried to find out what the show was called. And then came the Internet. One quick question of a TV forum and I had my answer: Star Fleet (X-Bomber in the original — we'll stick with Star Fleet, if only to avoid me making bad X-Bob-omber jokes).

So one trip to LoveFilm (whom my over-consumption of American content makes me want to keep calling "Netflix") later, and I've got the DVD of the first six episodes to watch. And I have to say I'm impressed. The visuals hold up well, with their distinctive styling and cartoony special effects. The continuing story arc is something I've always preferred over purely-episodic TV shows. Sure, the writing is sometimes cheesy, and many of the usual manga tropes are present, but it still tells an interesting story. Oh, and the synth rock. You mustn't forget the synth rock. In all: brilliant. I can't wait for the other discs to show up. What can I say? Six-year-old me had excellent taste.

[Image from Tim Maughan's Review]