It was 4am on a Saturday in 2013 and I was sleeping. My iPhone was sitting on my bedside table, plugged in in silent mode. It buzzed once. I probably didn’t hear it. A few minutes go by and it buzzed again. I stirred, glanced at the lock screen dimly lighting my room — an email. Not important, it could wait. I closed my eyes again fully intending to continue snoozing. The phone buzzed again. This time I looked at it in a bit more detail.

Your Battle.Net password was successfully changed.

Suddenly I was a wide awake. How was my Battle.Net account password changed? I noticed the badge on my Mail.app — hundreds of emails. That was strange, and stranger still, they were all in Chinese from random email addresses. Then came another email:

Your Battle.Net Account has been suspended.

I was confused, dazed, still sleepy. Then it happened. I haven’t felt truly fearful many times in my life, but I can honestly say this was one of those times:

Your iCloud password has been successfully changed.

That was it. I sat upright, my wife pulled the duvet over her face disapprovingly. How in the hell has someone managed to reset my password?

It was probably less than ten seconds and I was out of bed, downstairs in front of my computer trying to figure out what the hell was happening.

The iCloud email stating that my password had been reset showed the originating IP address. A quick IP lookup showed it came from somewhere in China. It would seem that black-market WoW gold sellers will do a lot to get their hands on some gold to sell.

I was panicking, my iCloud account is probably the single most important account I have — my email, my devices, my developer account… it contains my saved bank and debit/credit card details for use with the App Store. If they wanted to, they could go into the Find My iPhone website and click the convenient buttons to remotely wipe every device I had signed into iCloud. My iPhone, my Mac, my iPad… If they had done that I would have lost all access.

I needed to start damage control. First thing I did was reset my iCloud password using the security questions and the recovery email that I had set to a Gmail account.

Almost immediately after I reset the password, I got another email saying it had been reset again. These people meant business.

So I tried again; I reset the password using the same method; but this time, as fast as my internet connection would allow me, I changed the security questions, birthdate and recovery email. False information for all of them.

I waited for what felt like the longest few minutes of my life. No email. Ok. Good.

The Battle.Net account was still an issue, so I checked up on it. Blizzard had locked it due to “suspicious activity”. If only Apple had done the same?

What Went Wrong?

It was a rookie mistake which I will never make again — using the same password across multiple accounts.

The only thing I can trace this back to was when I logged into my Battle.Net account on a public wifi in a pub a few days earlier — probably a victim of a Man-in-the-middle attack.

The hackers used the password to get into my Battle.Net account to steal all my gold. (I had no gold anyway, so jokes on them).

Once the Battle.Net account was locked, they used the same password to get into the email account linked to the Battle.Net account.

It seems the first thing they did in both cases was to reset the password to prevent me from locking them out. Blizzard did the right thing and locked the account to prevent further damage. Apple seemed less inclined to lock the account.

The Aftermath

I now use 1Password to generate and safely store different passwords for each site I use. Sometimes it can be a little more inconvenient, as I now don’t actually know any of my passwords and need to retrieve them from 1Password when I need them. The browser plugins and the app help in this regard.

I also use 2 factor authentication wherever possible.

I would definitely recommend 1Password to anyone looking to increase their online security.

Last week Apple announced the new Apple TV with an App Store and an SDK allowing developers to make games and apps. They also announced the Siri Remote; a new remote to interact with the new apps and games that will appear on the Apple TV.

But the question everyone has been asking is: will it be good enough to use for gaming?

There appears to be two camps divided down the middle on this topic. Those that feel the remote will suffice for the type of casual gaming that iOS is known for, and those that were hoping for a gaming renaissance of sorts without having to go all-in on a current-generation gaming console or PC.

First, lets take a bit of a stroll down memory lane. Apple was once a bastion of gaming, with the Apple ][, for example. People could choose from the many commercially available games, type in BASIC code from popular magazines, or simply make one themselves if they had the know-how.

But Apple haven't always been successful with gaming in the past. We need only look at the failed Pippin, or the more recent lacklustre attempt at dispelling the "Macs don't play games" cliché at 2007's WWDC event where EA announced they were bringing some of their most popular games to the Mac. In the form of lazy, buggy, badly-performing Transgaming Cider ports. Then promptly forgot the Mac existed before bringing their online store Origin (filled to the teeth with The Sims expansions) in an attempt to compete with Valve's Steam. Anyway...

Then came along the iPhone, iPod touch and iOS and with it the type of casual gaming that was previously reserved for Facebook apps. Apple care about games again. Each year they consistently demonstrate the improved graphics capabilities of the hardware and the games made to show it off - like Epic's Infinity Blade.

It's probably fair to say Apple conquered the mobile gaming market. But it's a different type of gaming than you'd find on, say, the Nintendo DS or Sony PSP. And it comes down to the games UI, I think. Mobile games on iOS are simplistic, making use of few on-screen controlls or the devices motion sensors, whereas mobile games from Nintendo or Sony focus on physical controls allowing for precision. This is key.

The only place left for Apple to try their hand at games was the living room. Apple TV to the rescue ...Right?

At WWDC 2013, Apple announced MFi game controllers for iOS. This was huge (well, for me, at least). When I heard this announcement the only thing I could think of was an Apple TV with an SDK and these controllers! Boom, instant console competitor. But it took Apple another 2 years before that happened.

And then they went and shot themselves in the foot, so to speak.

In the days after the announcement, the marketing material/documentation for the Apple TV SDK stated that developers would be able to make their games require an MFi game controller. But Apple did a 180° and decided to nip that in the bud. Now the documentation reads

Your game must support the Apple TV remote. Your game may not require the use of a controller.

I was fortunate enough to get hold of the Apple TV Dev Kit, and spent a weekend bringing Provenance to tvOS. As a result, I had first-hand experience of what it is like trying to support the Siri Remote in an application that has a complex control scheme.

The answer to the question 'is the Siri Remote is good enough for gaming?' is ... maybe.

If your game is like an iOS game and requires nothing more than motion control and no more than 2 buttons, then the Siri Remote is fine. If your game is like Provenance and has complex controls with 3 buttons or more, then no, the Siri Remote is not going to cut it.

The Siri Remote exposes two pushable buttons and a touch pad (technically three buttons, but one of them is the Menu/Pause button, which is almost always used to bring up in-game UI and not for controlling the game itself). One of the pushable buttons is the touch pad click, complicating things further. Trying to push a button with a thumb that is also trying to control the movement of an in-game character is difficult at best. That leaves one button that is not hindered by the touch pad. It's certainly impractical. Developers don't get access to the other physical buttons on the remote: the home button, volume buttons and the Siri button.

For Provenance, this isn't such a big issue. It's not an App Store app, and likely never will be, so I don't have to worry about it being rejected because it requires a controller better than the Siri Remote.

But think about those developers who were hoping they wouldn't have to compromise their game in order to comply with a seemingly arbitrary rule or fear a rejection and wasted time, money and effort. For these developers, maybe it's just not worth the hassle of trying to accommodate the Siri Remote. Maybe it's best if they just don't bring their game to the Apple TV. Then what? No games, no sales, Apple TV falls into the pit of obscurity with the Pippin?

Apple, if you're listening (lol, right?) please revert your decision on not allowing devs to require game controllers for their games. The users that would get frustrated that a game requires a remote, would probably already have one, if not be willing to buy one. The users that don't want to game that way with the Apple TV won't care that a game requires a controller because they don't want to game that way anyway!

Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.

Steve Jobs

A Little Too Familiar

Last week an app appeared on the App Store under the name of "Homebrew Indie Games". This app, at first glance, seemed like any other legitimate app on the app store, however, on closer inspection it looked a little too familiar.

_{Assimilate running in Homebrew (left) and Provenance (right) (Click for a larger version of each)}

Homebrew Indie Games was first brought to my attention by @pheraph on twitter. This app claimed to bundle 18 'free' homebrew games for retro consoles such as SNES, NES, Genesis and GBA.

Coincidentally those are some of the same systems supported by Provenance, my Open Source emulator front-end.

Attribution

Provenance is made possible by the hard work done by the developers of the included emulators and the OpenEmu and RetroArch teams. I'm more than happy to acknowledge their work, because A) they worked very hard to bring these emulators and libraries to life, and B) because the open source licenses require me to do so.

And that is one of the things Homebrew's developer didn't do when he took the source code to Provenance, bundled a few homebrew games with it and sold it on the App Store for $2.99.

The second, and arguably more serious, violation of the Open Source licenses was that Homebrew was being sold. Most of the emulators used within Provenance are under strict non-commercial licenses, which forbids anyone to sell that code. Homebrew's developer was all too happy to ignore these license terms and profit from the hard work done by other people, while taking the credit for it at the same time.

Nowhere did Homebrew's developer state that the code:

• was derived from Provenance
• included the emulators from:
  • Genesis Plus GX
  • SNES9x
  • FCEU
  • VisualBoy Advance
  • Gambatte
• included code from OpenEmu
• included code from LibRetro (RetroArch)
• included 18 homebrew games licensed under a Creative Commons, Attribution, Non-Commercial, No-Derivatives license

Similarities? More Like Identicalities!

I believe the initial complaint to Homebrew's developer was sent by RetoArch after they thought he'd possibly misappropriated their code without attribution and sold it. In an effort to prove Homebrew was not using RetroArch, the developer did probably the most self-damning thing he could have done and sent some of the source files from Homebrew to RetroArch for inspection. RetroArch noticed the OpenEmu code and told them and OpenEmu told me.

It was immediately obvious that the code in Homebrew was exactly the same as the code in Provenance, with the minor exception that the class names had been changed to remove the PV prefix and replace it with HB... _{so crafty}

Take a look and decide for yourself:

_{Four diff'ed source files from Provenance and HB. Provenance is on the right, Homebrew on the left in each image. Click for larger versions.}

In fact, one of the funnier parts is where they had obviously done a search for core and replaced it with engine as you can see in last image above where <QuartzCore/QuartzCore.h> was changed to <QuartzEngine/QuartzEngine.h>. That code would not compile, generating a "header not found" error, making it plain as day that the search and replace was done only before sending the code to RetroArch, and not before compiling.

DMCA Takedown

With this evidence, it was 100% clear that Homebrew's developer had not written the code they were claiming as their own, and so on the recommendation of the OpenEmu team, I submitted a DMCA complaint to Apple.

It took a day of waiting, but Apple eventually issued the DMCA complaint to Homebrew's developer, and the app disappeared from the App Store.

A couple of hours later I received a somewhat bitter email from Homebrew's developer telling me they'd already removed Homebrew from the App Store and that it had been unplublished hours before receiving the DMCA notice. I don't know how true that is, but I take it as a victory for Open Source that the app is no longer for sale.

Final Thoughts

Open Source doesn't mean "do what you want", despite many people thinking that it does. Open Source is about community, sharing, attribution and trust. Developers working together towards common goals and sharing solutions so that the community benefits from their hard work. Developers of Open Source projects are most commonly doing so in their own free time and not being paid for it. They do it out of love for the project and the community that builds around it.

When someone violates that trust and community spirit, stealing hard work from people in an effort to profit, the community is hurt. Developers become less engaged and more reluctant to provide free (as in speech) code to benefit the community.

So in the future, if you plan to use Open Source code, please read the license accompanying the code and abide by its terms, it's there for a reason.

It's alright.

Have an array full of objects and would like to get, for example, all the names from those objects without having to iterate?

You have a Person object that has a property name and you have an array full of Persons and want all their names. You could create a mutable array, iterate the array of Persons, access the name property, store it in your new array, etc. etc. etc.

With Key value Coding, you can ask the array for the values for a given key and it will return a new array containing all the values for each object.

[personArray valueForKey:@"name"];

Voila! A new array containing all the names of each Person object!

For completeness, here's a rather contrived, self-contained, compilable example:

#import <Foundation/Foundation.h>

@interface Person : NSObject

@property (nonatomic, copy) NSString *name;

@end

@implementation Person

- (id)initWithName:(NSString *)name
{
    if ((self = [super init]))
    {
        self.name = name;
    }

    return self;
}

@end

int main(int argc, char *argv[]) {
    @autoreleasepool {

        NSMutableArray *personArray = [NSMutableArray array];

        for (NSInteger i = 1; i < 21; i++)
        {
            Person *obj = [[Person alloc] initWithName:[NSString stringWithFormat:@"obj %zd", i]];
            [personArray addObject:obj];
        }

        NSLog(@"%@", [personArray valueForKey:@"name"]);
    }
}

and the output:

KVCExample[79283:507] (
    "obj 1",
    "obj 2",
    "obj 3",
    "obj 4",
    "obj 5",
    "obj 6",
    "obj 7",
    "obj 8",
    "obj 9",
    "obj 10",
    "obj 11",
    "obj 12",
    "obj 13",
    "obj 14",
    "obj 15",
    "obj 16",
    "obj 17",
    "obj 18",
    "obj 19",
    "obj 20"
)