Increasingly, patents are being used to tax developers
With the enormous success of the iOS platform and App Store comes danger – there are trolls under the bridge lying in wait for your apps
The last few months have seen a troubling increase in the number of iOS developers (and indeed developers on Android and other platforms) being targeted with claims of patent infringement regarding their apps. On iOS, most claims have centred around the use of In-App Purchasing, linking to other apps (on the App Store or on the web), or having any kind of form in your app that’s submitted electronically – but potentially any piece of functionality that’s even remotely covered by a patent is vulnerable.
Patent systems are designed to protect the right to benefit from innovations, and encourage commercialisation for the good of the economy as a result. That’s a sensible and positive goal. Where we enter murky water, however, is where the patent holder is interested only in profiting from the patent itself, rather than in producing any products or services using the innovations. Such patent holders are referred to as NPEs, or non-practising entities – but are often known as patent trolls.
The software industry is especially vulnerable to opportunistic, anticompetitive use of patents, because software patents themselves tend to be awarded too readily, and too broadly. A portion of the problem is the comparative youth of the industry, and the corresponding lack of understanding among those who don’t work within it. There are also, as always, political factors at work.
The stark reality is that a developer in receipt of an infringement claim has very few options – and perhaps just one: to settle. Patent licenses tend to require fees of a low-single-digit percentage of revenue from the product concerned, whereas the costs of fighting an infringement lawsuit in the notoriously cost-inflated US legal system is in the millions of dollars. Even challenging a patent’s validity (which does not place current lawsuits on hold) takes years, and costs tens of thousands of dollars.
For most developers, the system offers no practical means of legal defence; only bankruptcy. The protection and due process of law becomes little more than a sham when justice is available only to the super-rich, and where the threat of legal action is used as a protection racket by those with nothing to lose; nice app you have there – it’d be a shame if anything happened to it. Some protections may be available depending on the jurisdiction in which your business is founded and based, and the insulation of a limited liability company is still relevant, but both involve heavy sacrifices: leaving the US market in the former case, and potentially losing a business in which you’ve invested so much time and effort in the latter.
The question of the general validity, sense or morality of patents on software is a thorny one, and there are convincing arguments on either side. The issue can never be settled until the definition of obviousness reaches some semblance of parity between the patent awarding bodies and practising developers. Never has a system of open peer-review been more needed – but that’s only if you’re actually creating something based on the notional innovation.
To dip a hand into another’s wallet to take money you might have made (if you’d bothered to try) is surely just simple theft.
DISCLAIMER: The material contained within Dev_Zone is for informational purposes only, and Future Publishing Limited cannot accept any responsibility for errors or inaccuracies that occur. The material does not constitute legal advice and should not be relied on as a substitute for taking legal or other professional advice about your particular circumstances.
Matt Gemmell is an iPad, iPhone and Mac OS X developer specialising in user experience. He runs his own business, Instinctive Code, and frequently speaks at industry conferences.He has written hundreds of articles covering development and interface design at mattgemmell.com, and his clients include Apple and other Fortune 500 companies.
In a previous life, I trained as a graphic designer, so even though I ply my trade as a journalist these days, I’m always keenly interested in what’s happening in the world of pro design. And today something big happens: the release of Adobe Creative Cloud, a suite of apps and services for the photo manipulation, design, layout and more tools that millions of design practitioners use worldwide every day in Adobe’s Creative Suite.
I’m off through to London to talk to Adobe about Creative Cloud and some other fun stuff, but in the meantime you can check out reviews and previews from the pros on our sister site CreativeBloQ:
The main Adobe CS6 review
Regret is an unpleasant fact of life, but it doesn’t have to be that way for your users – it’s our job to make using apps a foolproof experience
Users blame themselves when things go wrong in an app, but the truth is, the fault usually lies with the developer
Few emotions have so pernicious an effect as regret. There’s a quality of self-loathing about it; an acknowledgement of an opportunity missed, or a negative consequence caused by our own action or inaction.
Regret can distort our very memory of events. If the train is on time four days in a row, but late on the day you must get into the office, you’ll remember it as being unreliable.
The worst aspect of regret, though, is that we feel it at all – instead of, say, anger. We personalise things, particularly failures. Frustrations that were visited upon us by external forces are often seen as due to our own shortcomings. This is particularly true when dealing with machines. We see ourselves as unable to understand the machine, rather than realising that it is the machine (or rather, its designer) that has failed to understand us.
When dealing with technology, most people have low self-esteem. That’s a tragedy of the modern age, and as developers it’s our duty to fight against it. But how? There are essentially two ways to banish regret: make sure nothing ever goes wrong, and if something does go wrong, make sure it’s reversible.
A lofty goal, certainly, but as developers, we’re akin to sorcerers. The reality of the app is what we want it to be. We have supreme control, and it’s our responsibility to try to offset regret. User errors themselves are inevitable, of course. We all make incorrect assumptions, or generalise inappropriately. We accidentally tap something when we meant to tap something else. We even tap deliberately, and then decide we shouldn’t have.
Errors will happen – but how often, and what course of action is available afterwards, is our department. As you design every feature, consider how you can make it mistake-proof. Don’t make dangerous, destructive actions easy, and don’t just badger the user with confirmation alerts. Destroying crucial data should be difficult to even initiate, much less actually carry out.
Every action the user takes is precious. They’re spending time in your app, and entrusting their effort and work to it. It’s our profession’s sacred trust, and we must honour it. Auto-save changes. Keep old versions. Restore context the next time. Remember choices, and default to them. Earn the user’s trust by bulletproofing their experience.
When things do go wrong, we go beyond trust and towards something like faith. The user is in free-fall, and it’s up to us to catch them, and set them gently down. If you can do that, you’ve probably gained a customer for life.
Implement Undo pervasively. Allow restoring to previous states. Maintain an editing history. Back up on the fly. Sync data to elsewhere in case of disaster (with permission). Don’t just warn about impending doom and then blithely allow the user to hang himself.
If you make mistakes during development, they’re your fault. If your users make mistakes when using your app, they’re almost certainly your fault too. Nobody said this was an easy line of work.
Human mistakes are inevitable, but they should be as unlikely as possible. If you can’t banish mistakes, neutralise their sting by making consequences avoidable. Life already supplies more than enough opportunities for regret.
Matt Gemmell is an iPad, iPhone and Mac OS X developer specialising in user experience. He runs his own business, Instinctive Code, and frequently speaks at industry conferences.He has written hundreds of articles covering development and interface design at mattgemmell.com, and his clients include Apple and other Fortune 500 companies.
Among those who care about such things, it’s traditional to call Apple ‘closed’ – usually in tones of disapproval or downright disgust. Their position is that because Apple does things its way using techniques and technologies that only it controls and that often only it has access to, it’s anything from misguided to evil.
This viewpoint isn’t a new one. At least part of it is rooted in the Apple of the nineties – the Apple that ignored the prevailing wisdom that pointed to Microsoft and said that, duh, success would come from licensing the Mac operating system, and/or allowing other companies to build licensed Macs as well. (Apple did dabble with allowing third parties to make Macs, but it was disastrous in the short term, and the programme was soon nixed.) Then, Apple really was an insular, almost parochial company; even making a Mac talk to a PC over a network was, depending on the setup, either difficult, expensive or impossible.
Today, anyone calling Apple closed often points to something to do with the iTunes ecosystem. With exceptions for deploying apps within, say, a company, anyone who creates an app for an iPhone, iPad or iPod touch has to sell it through the App Store, and either give it away for free or give Apple 30% of the money it makes. And at least until iOS 5, iCloud and iTunes Match came along, anyone who wanted to sync music to, back up or even just activate their iPhone had to connect it to a Mac or PC running Apple’s own iTunes software.
Let’s ignore the fact that this ‘closed’ nature brings many benefits – not least of which are stability, compatibility and a pleasant, non-geeky experience of using computers – and the fact that Google’s Android platform, the poster child for ‘open’ in the mobile and tablet markets today, is open only by a rather charitable definition.
Even ignoring those, I think the pejorative view that Apple is closed is both dated and not especially useful.
I’ve spent a lot of time recently experimenting with AirPlay – Apple’s system for streaming audio and video over a network – setting up speakers in all the rooms in my flat for multi-room audio. AirPlay had a difficult birth; the implementation was buggy and Apple was slow to certify products so they could be sold, both things that led to its widespread adoption being delayed. Even now, partly due to the high fee Apple charges to license AirPlay, we see companies putting AirPlay only in their high-end, expensive speakers.
But while AirPlay isn’t perfect, I think it’s a great example of how Apple gets ‘closed’ right. You could argue that it’s expensive for companies to join in and that this currently makes it an expensive system for customers to buy into, and if you did I wouldn’t argue with you. Companies can join in, though, and this creates a rich ecosystem of AirPlay speakers that lets me pick and choose exactly which ones I want to buy for particular situations.
If you were to buy into Sonos’s (excellent) wireless music system, for example, and wanted to put a speaker in your living room, one in the bedroom, and have one to take outside for a barbecue, your choices are limited. Unless you want to start inelegantly hooking dumb speakers up to one of Sonos’s AirPort Express-like adapters, you can only use the Play:3 or Play:5 speakers – and there’s no option for a portable speaker for that barbecue. With AirPlay, you could connect an Apple TV to your home cinema speakers in the living room, put Logitech’s UE Air Speaker in the bedroom (the dock lets you charge your iPhone as well) and then charge up the iHome iW1 to take outside with you when the weather’s nice.
This, to me, mixes the best of ‘open’ and ‘closed’. I can pick the best speakers for where I’ll use them from a panoply of manufacturers – I can’t wait for a wipe-clean AirPlay speaker for the kitchen and a waterproof one for the bathroom – but because Apple retains control over the AirPlay technology and only certifies those speakers that it effectively guarantees will work together, I get a rock-solid, easy to use system.
There’s no doubt that Apple puts its own interests just ahead of its customers’. And there will always be situations in which I and others would like to be able to exercise a little more control of our devices and what we can do with them, but I think the particular set of compromises Apple makes are the correct ones.

The new iPad is out, and we’re all marvelling at it here in the office. It’s a great machine, and an object of primal technological lust… but I think I’m going to stick with my iPad 2.
This isn’t advice I’d necessarily give to anyone else, though. To most normal people (ie. those who don’t spend all day reading about every little technological hop that occurs), my reasons for waiting probably won’t register with the same importance. If you told me that the Retina display was enough for you to upgrade, I wouldn’t disagree at all.
But I’m through the looking glass. I see the compromises that have come about in the new iPad – the slight extra thickness, the noticeable extra weight, the fact that it runs hotter than the iPad 2 – and I know that technology is on the way that could solve these problems, and that it should all be mainstream by the end of 2012. Again, I wouldn’t tell other people they should wait for these reasons, because none of it is certain, but I’m confident enough to commit myself to holding off.
The problem lies in the fact that the A5X, and the new iPad by extension, seems like a half-way house to me. It’s plenty powerful, no doubt, but my issue isn’t with its speed – it’s the way it’s made. The A5X is fabricated using the tail end of the current generation of chip-manufacturing technology, but the next generation is in the process of arriving.
When the first iPad arrived with the A4 chip powering it, it used ARM’s Cortex-A8 processor technology as its basis. When the iPad 2 arrived, the A5 came with it, upgrading to ARM’s Cortex-A9 technology. Improvements from the Cortex-A8 to the Cortex-A9 meant that even if the chip in the iPad 2 was still single-core, like its predecessor, it would have been around 30% faster, despite them both running at a speed of 1GHz. The fact that the A5 was dual-core meant that the improvement was much higher than that in the end. (It was actually necessary to upgrade to Cortex-A9 to become dual-core at all – it wasn’t supported by the Cortex-A8.)
I bring up this confusing technological history because ARM is in the middle of rolling out its next generation of processor tech: the Cortex-A15. One of the companies that's comitted to producing Cortex-A15-based chips is Samsung, which manufactures Apple's chips. In like-for-like tests, a Cortex-A15 chip is said to outperform a Cortex-A9 chip by as much as 40%, so if a hypothetical Apple A6 chip used this technology in a quad-core processor, the performance would be phenomenal.
But speed isn’t the most important advantage of the Cortex-A15 technology. As I said, the A5X is pretty fast as is, but to accommodate it and the Retina display screen in the new iPad, the battery capacity had to go up by around 70%. This meant an increase in size and weight, and the sheer power of the new graphics chip is almost certainly why the new iPad gets noticeably, and perhaps even uncomfortably, warmer than the older one.
Part of the reason for this is that the A5X is manufactured at 45nm, the same as the A4 was. This has meant that as more technology has been added to the chip, it’s ballooned in size – the A5X is over three times larger than the A4. But Cortex-A15 will be made with a smaller manufacturing process – probably 28nm. Chips created like this aren’t that common yet, but Nvidia’s latest graphics cards use it, heralding its arrival to the mass market. In a year, it’s likely to be a perfectly reasonable option for an Apple A6 chip.
The advantage of manufacturing at 28nm is that the chip itself can be smaller, but also more power efficient. Having a smaller chip can potentially free up space inside an iPad that could be used for the battery, but the battery capacity could also be reduced. The end result is that the next iPad could go back to the size and weight of the iPad 2, and yet be far more powerful than the new iPad.
And if the whole chip is being created at 28nm instead of 45nm, that would include the graphics chip – the primary culprit for the new iPad getting hotter than its predecessors. Going to a smaller manufacturing process would mean having the same graphics power, but without the toastiness.
Looking at the broader technological roadmap, I think the next iPad will have all of the advantages of the third-generation iPad, but will remove the compromises Apple had to make to get there from the iPad 2. That’s the iPad update I really want, so that’s the one I’ll wait for.
Disclaimer: I reserve the right to buckle and buy one at any time. That screen is really nice.
By now, you'll be aware that we love the game Hero Academy, awarding it five stars and our Editor's Choice award, and we produced a huge strategy guide for the game. We wanted to find out more about it, so we found some time to talk to Marcin Szymanski, the Lead Designer for Hero Academy from developer Robot Entertainment.
Robot Entertainment has also just announced a fourth team for Hero Academy – a team of orcs and goblins called The Tribe. You can find our more about the new additions at RE's website.
Tap!: Where did the idea for Hero Academy come from?
Marcin: I have always loved tactical games like Final Fantasy Tactics, Vandal Hearts, and Disgaea. When we started talking about making a smaller game, I jumped at the chance and put a pitch together with a few other developers here. We focussed on the multiplayer experience because our goal was to finish something relatively quickly, and we thought the asynchronous model was a perfect fit for that.
Tap!: Why make it for iOS first, instead of other platforms?
Marcin: Many of us are iOS gamers. Even those friends of ours who don't have a console or a gaming PC have an iPhone or iPad, so it felt like a great opportunity for us to pursue this market. We were very excited by the possibility of making a game that we could all play with our friends, and we felt we would be able to learn a lot by making a game for touch-enabled platforms. Finally, a few of us had worked on side projects for the iPhone, so we thought that experience would help us hit the ground running.
Tap!: Hero Academy is an extremely lean game – just the one mode, no narrative cutscenes or a single-player campaign. Was it designed to be like that from the start, or did you have more elements of it that were cut out to keep it focussed?
Marcin: The core vision statement was: "An asynchronous multiplayer tactics game that anyone can play." All of our decisions ultimately had to internalise this statement, and many things were modified or cut to make room for it. We did have some very early, rough plans for single-player content (various ideas ranging from metagame progression to a practice mode or team-based challenges), but we had to cut them in the interest of shipping the highest quality multiplayer game that we could.
Tap!: HA feels like it needs less investment of time to play than other similar strategy games, but it also throws you in at the deep end, without much training or explanation of all the intricacies. You've added more support for new players since launch, but do you think you've got enough information now?
Marcin: I think we still need a dynamic tutorial that can guide new players through their first game. Interestingly, most players get the hang of the game very quickly once they figure out any small part of it, but that first step has a lot of friction. A related issue is that many of our players create only a single game and keep checking for turns in that one game. So, perhaps we can come up with some way of better introducing players to the concept of async play, especially the benefits of having multiple games going at once. Of course, not every player wants to be overwhelmed by multiple games, and this is where some sort of offline content would do the game a lot of good.
Tap!: Were there any games that you drew inspiration from, on iOS or elsewhere?
Marcin: We drew heavy inspiration from polished games like Plants vs. Zombies and WarCraft, and, of course, from other tactics games. Our character visuals and animation style were definitely inspired by the amazing iOS game Battleheart. A lot of our attack and ability animations (and names) were inspired by any number of Final Fantasy games, haha.
Tap!: One of the great things about Hero Academy is the personality in the animations. Do you put a lot of effort into getting the players to engage with the avatars?
Marcin: Thank you, and, absolutely! We wanted to give the characters fun visuals and imply some personality. It was equally important for visual changes to correspond to gameplay changes as much as possible. We spent a lot of time working on various features for the animation system because it needed to communicate so much of the gameplay, such as when a unit is below 50% health and swaps to a ‘wounded’ idle animation.
Tap!: Looking at the games on Robot's website, the newer games are much smaller in scale than the likes of Age of Empires III. What's it like working on your own, more focussed game?
Marcin: It was an amazing experience. Also somewhat terrifying. On a larger project with a big team, you can always get help on a system or on a particularly complex problem. The issues we faced on HA were often very platform-specific or game-specific, so it was up to our relatively small team to figure it all out. On the plus side, we were able to run way faster than I've experienced in my professional career, and we generated some useful data for our studio about how to ship a game in a short time. And, we now have a solid tech and design base for future projects.
Tap!: Tell us about the last army you added, the Dwarves
Marcin: They are quite an explosive team, and I love the way their art fuses technology with the traditional Dwarven mythos (stout, bearded, maybe a little crazy). We are watching the community's reaction to their gameplay, as well as their balance, and will adjust things where it makes sense. So far, we're seeing a lot of variety in how players play and win games with (and against) the Dwarves, so the situation is encouraging so far.
Tap!: What’s been the philosophy behind designing the teams and their abilities?
Marcin: At a high level, I want each team to have a badass identity that players can become excited about. Our developer friends at Blizzard frequently talk about ‘concentrated coolness’ and this concept resonates with me deeply. Along with this high-level goal, we want to keep pushing the envelope with new mechanics and ways of bending the canonical rules of Hero Academy (for example, we have a variety of internal pitches that completely do away with AP costs for Spells, or allow units to be combined with each other, or drastically modify the contents of the starting deck). I wouldn't want the game's formula to become predictable or stagnant, so we will continue to push for these kinds of changes. And, of course, each team's units, abilities, and effects must remain accessible and understandable, both for the player using that team and other players confronting it. We're learning some good lessons in this arena (for example, we've received feedback that the Annihilator's ‘physical weakness’ debuff is difficult to parse for players) and will be working on ways to avoid such confusion in the future and hopefully to fix it where it exists.
Tap!: How do you make sure they're balanced (and are you confident that they are – do you intend to tweak the currently released teams any further)?
Marcin: We see balance as a moving target that evolves with the game. This means that, even though we don't think there's a perfect solution, we will continue adjusting teams and individual mechanics to fix glaring problems. We also don't want players to feel like they have to ‘pay to win’ – in our model, we want all teams to be different but equal. We iron the kinks out of the balance by playtesting the game daily, and fortunately a lot of our best players are addicted enough to play the game all weekend as well. So we generate a lot of internal data that helps us find major problems. Of course, nothing is better than seeing how the community interacts with the mechanics and finds overly powerful strategies.
Tap!: Can you tell us about the fourth team you've got planned? [Ed’s note: We talked to Robot Entertainment before the fourth team, The Tribe, was announced.]
Marcin: Good question! I can tell you this: the word I would use to describe the new team is ‘Relentless’. That's the closest to how it feels to play them, I think. We're also breaking a couple of rules with their mechanics, so I will be eager to see how our players like the new changes.
Tap!: What sort of strategies does the team there use when playing? Who's best at the game?
Marcin: Haha, well, one of the designers here was previously a balance tester at Ensemble Studios, so he spends time picking apart the game's mechanics and figuring out loopholes. We have a variety of strategies at play, since some of us gravitate more toward crystal-killing, or towards a particular team aesthetic, or any number of things. A lot of us go for unit attrition, though I personally prefer to go for a balanced approach that threatens enemy units while trying to hold Assault boosts.
Tap!: Letting players retake their go as many times as they like struck us as unusual for this type of game. What was the thinking behind it?
Marcin: Even before we started development, the Undo feature was considered a critical piece to implement. A touchscreen is an imprecise device, and we took a major cue from Scrabble in the sense that we wanted players to feel the freedom to experiment with all of their units and items. So, we implemented this feature very early and spent quite some time iterating on it. It turned out to be one of the most popular features in our internal playtests.
Tap!: Have you considered a kind of 'hardcore' mode where this option is removed?
Marcin: The Undo feature is such an integral part of the game that it's not likely we would ever add such a mode. In general, I don't like options for things like this because oftentimes they indicate a lack of direction. It also means players have to be taught about the differences and presented with a selection UI for it, which uses up some of the mental space they can give to our game. A hardcore mode for this game would probably be better as a standalone game that also embraces other hardcore concepts, such as a turn timer. Also, one of the most common pieces of feedback we receive is how much players like the Undo feature (along with Replays).
Tap!: How do you feel about the business model you have? What sort of percentage of players upgrade from the free version to the Dark Elves or Dwarves? Was there a consideration to just charge a couple of dollars and have done with it, instead of offering In-App Purchases in exchange for a few new pixels in the form of avatars/colour changes/taunts?
Marcin: We wanted Hero Academy to reach a large number of players. We wanted to get Robot's name out there as a quality mobile game developer, and we also needed a large player base to keep our matchmaking pool filled. That's partly why we focussed so much on the accessibility (on top of all the other major benefits of that), and also why we chose to release only a single, free version of the game. Based on many reports from other developers, charging even a dollar would have probably impacted our number of downloads too much for it to be worthwhile. As for the specific IAP we chose, we wanted to learn as much as possible about the App Store and about the business models supported by the mobile gaming market. We decided to include a grab bag of IAP for players of all types. We have one type of consumables and several kinds of permanent upgrades. We have visual-only items, and we have the gameplay-changing teams. In this way, we've learned many things about how to implement these kinds of systems and features, as well as how to tune our business model for our future games.
Tap!: Will there be an iPad-native version of Hero Academy?
Marcin: Yes, we're currently putting the finishing touches on our Universal version and will release it with a future update. [Ed’s note: This is now confirmed to be coming with The Tribe]
Tap!: Have you got any more iOS games planned?
Marcin: We're discussing how we can build on the momentum created by our release of Hero Academy. As usual, the main constraint is always balancing resources. However, we're very excited about mobile games.