Tag Archives: Apple

Handling Game Center With iOS Multitasking

Apple’s Game Kit Programming Guide contains the following passage:

A game that supports multitasking and Game Center must take additional steps when authenticating the local player. When your game is in the background, the status of the authenticated player may change. A player can use the Game Center app to sign out. Another player might sign in before your game returns to the foreground.

Multitasking is available from iOS 4.0 onwards, though not all devices running 4.0 support multitasking. Game Center was added in iOS 4.1.

So what exactly should my game do when the Game Center player changes behind it’s back? (Note: I’m concentrating on achievements here, as Pawns does not have leaderboards.)

The simplest method that also allows for offline play is:

  • The iOS game tracks achievements that were earned on that device, and stores that information locally.
  • If Game Center is available, achievements are also pushed to the server.
  • All achievements are pushed to the server, not just as they are earned, but whenever a Game Center player is authenticated. This handles the case where the player may have earned some achievements offline.

In short: make your game work offline, then push achievements to Game Center (one-way) whenever it is available without worrying about which player is now logged in.

This method is straightforward but will lead to two glaring side effects:

  1. If a player logs into a second Game Center profile, the new profile will automatically get some or all of the achievements that were earned on the first profile.
  2. Since this is a one-way synchronization (i.e. from game to Game Center) a player with two devices may see some achievements on Game Center but not on one of the devices.

We can try to fix these issues but it quickly gets complicated. (If you aren’t interested in a discussion of the complications, feel free to scroll down to the next section: The Experiment.)

For example, fixing the first requires you to be strict about which achievements are earned by which player. You could read the achievements back from Game Center after every profile switch, but then you have to handle the case where the player earned some achievements offline- this requires merging the online and offline lists. If you do that you’ve also solved the second problem– a nice feature, but I personally think it’s pointless unless the player’s entire saved progress (saved games, list of finished levels, etc.) is also stored in the cloud using iCloud, Dropbox, or some other service.

The situation is even more complicated if the game itself supports multiple local user profiles (as opposed to games that treat everyone on the device as the same player.) Note that when the user switches to a new local profile there’s no way to switch their Game Center profile for them automatically. We can only do the reverse: switch local profiles when the Game Center player has changed. This approach would work especially well for an online-only game.

In short, there are a lot of decisions to make unless we opt for the simple, “stupid” approach. Being naturally lazy, my inclination was to do this and hope that players (and Apple) would put up with the side-effects. But try as I might I couldn’t find any blogs or forum posts describing how other developers handle this, and that made me very nervous.

The Experiment

I decided to see how other game developers handle this. I spent a happy evening playing six iOS games that I’d already earned achievements in, but as a different Game Center player. I also switched to a second device to see if any of them read the player’s Game Center achievements back from Apple server.

It was a tough job, but someone had to do it.

The results? Judging from the side effects, the following five games use the simple achievements model I described above:

All of them had the side effect where the original profile’s achievements get copied to the new profile. This was even true for Plants vs Zombies, which lets you switch local profiles. The local profiles are completely ignorant of which Game Center profile you are logged into.

The one game which didn’t take the easy way out was Space Miner. After switching to the second Game Center profile, Space Miner warned me whenever I tried to load a saved game that had been saved by a different Game Center player. (It was my choice whether to go ahead and load the saved game or cancel.) In addition, it seemed that some but not all of the old achievements were copied to the new Game Center profile! I’m guessing that the achievements specific to a single campaign of Space Miner were NOT copied to the new profile, but achievements that you’d earn over multiple games were copied. I don’t claim to understand the nuances of Space Miner’s design just from this test, but clearly the developers went above and beyond to try to intelligently reconcile local saved games and achievements with Game Center’s achievements.

None of the 6 games ever seemed to read achievements back from Game Center. When I played on the second device, only my Game Center account showed the achievements that had not been earned on that device. (This looked especially odd in Pit Droids, where the achievement “Hutt Flats Unlocked” was shown in Game Center, even though the Hutt Flats puzzles were still locked on that device.)

Note that none of the six games I tested store their saved games in the cloud for access on more than one device. Such a game would not take the simple approach I described here. I believe the easiest approach there would be to force the user to select local or cloud storage for each saved game to avoid having to merge them, but with effort it should be possible to synchronize the two more seamlessly.


It appears that most games simply take the straightforward approach: make and display achievements as if the game were offline, and push achievements to Game Center (one-way) whenever it is available. This wasn’t too surprising for games that have no local player profiles to switch between. I wasn’t so sure what to expect for games that do have them, but in retrospect it makes sense. Developers are simply counting on the fact that players just aren’t likely to switch to a different Game Center profile.

Unity iPhone vs. Apple’s Developer License: Time to Worry?

For those of us using Unity iPhone, Apple’s new developer licensing terms are cause for concern. Specifically section 3.3.1, which states:

3.3.1. Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This has widely been interpreted as an attempt by Apple to prevent developers from cross-compiling Flash and/or Google Android games for iPhone. John Gruber has a good analysis of this which is somewhat sympathetic to Apple’s position. For unsympathetic opinions, simply swing a dead cat to hit a few. 🙂

(If Gruber is correct then I have to take issue with Apple’s thinking. If a company like Adobe tries to create their own platform on top of Apple’s, I believe Apple’s best defense is to keep adding popular features. That forces middleware companies to either support those features and become more Apple-like, or fall behind. But that’s a topic for another day.)

So should Unity iPhone developers be concerned? Yes, of course. Unity Technologies is urgently trying to get clarification from Apple on this. But until we know the score, there are many reasons to be hopeful for a favorable outcome.

1. Many of the top iPhone games are from companies like Popcap who release cross-platform casual games all the time. Many of these companies do not write their games from scratch for every platform. They target their own internal framework which itself supports multiple platforms. Apple is going to have a real problem if companies like Popcap and Telltale aren’t allowed to do this.

2. Unity Technologies is heavily invested in this issue. If in the end comes down to a matter of what language the game is scripted in, or some other technicality, they are probably going to find a way to get around it.

3. Disallowing middleware like Unity isn’t straightforward, particularly for games. If the final project is built in XCode, and follows the UI guidelines appropriate for that app’s category (e.g. utilities are generally expected to follow Apple guidelines and use the Cocoa controls; but games almost always use a custom user interface) then the product becomes indistinguishable from “native” code from the user’s point of view. It’s hard to imagine that Apple would reverse-engineer games in order to distinguish Unity iPhone games from others.

Of course, Apple has been willfully arbitrary before, so this argument doesn’t hold THAT much water, but it’s a point to consider.

4. People who use Unity are well-positioned to jump to another market if Apple locks this one down. It’s hard to overstate this point. Competing platforms like Android are going to have a field day with this, as it reinforces their message that Apple’s closed system is bad for developers. Google would welcome disenfranchised iPhone developers with open arms. And an Android edition of Unity is already in the works.

The burden is on Apple now to clarify or possibly revise the policy. Personally I think they are going to interpret it narrowly or possibly even retreat from it. It seems to me like a classic case of lawyers reflexively setting up something that in retrospect is difficult to enforce and hurts Apple more than it helps.

Here’s hoping the situation gets resolved quickly.