Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

I've written about the Google Appengine (GAE) a couple of times before and the same goes for Apple Push Notifications (APN). For Doublemill I had to bring those two technologies together and it was a pain and pleasure at the same time.

Let me start with the pain! Apples Push Notifications in a restricted environment like the Google Appengine is no fun to implement! My first approach was to use notnoop's java-apn, which I've used before and works quite well. Unfortunately, there is currently no way of using a client certificate, which you'll need in order to talk to Apple's server on the Google Appengine. There are some javax.security classes missing on GAE.

That's where the pleasure part begins! Thanks to Urban Airship, it's easy to hook up your application running on Google Appengine to Apple's Push Notifications! And the best part - it's free (although not unlimited)! Urban Airshipe provides an easy to use REST interface, which you can call from your Java code on GAE with a good old HttpURLConnection. It uses Basic Auth over Https to ensure that only your application can send Push Notifications to your iPhone App.

I won't provide any code for you here, because it's the basic concept that's the most interesting part when bringing APN to GAE. The first thing you need to do, is store your user's deviceToken. You should do that each time the App launches, to ensure it's the correct token. That token, along with the information you want to present to your user, needs to be passed to Urban Airship's REST interface, everytime you want to send a notification. A Cron Job or Task on Google Appengine could handle that for you.

If your application is designed with notifications in mind, then it's quite easy to bring Apple Push Notifications to the Google Appengine, thanks to Urban Airship!

Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

In a previous blog post I highlighted a couple of gotchas you need to be aware of when implementing Apple Push Notifications. Unfortunately, I didn't really pay attention to one of them myself:

The first problem I ran into, had to do with my provisioning profile for development. I enabled APN in my Provisioning Portal, installed the certificate and implemented all the delegate methods according to the documentation, but somehow the method

- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error

was called with error code 3000 - "no valid 'aps-environment' entitlement string found for application". I was pretty sure, I setup everything correctly. However, I missed one little thing:

After you have generated your Client SSL certificate, create a new provisioning profile containing the App ID you wish to use for notifications.

This bit me after submitting Doublemill Premium to the App Store and being rejected for promoting Push Notifications in my App description, but according to Apple, not implementing it. During beta testing, everything worked fine. I had a correct implementation and the App was asking me for permission to use Push Notifications.

However, I did forget to create a new distribution provisioning profile for the App Store, after enabling Push Notifications for production. So, it didn't work for the reviewer at Apple. Forgetting about something like this is very painful, especially since I'm waiting for the 3rd round of review for the next release of Doublemill. That makes it 3 weeks since the initial submission.

When asking about this on the Apple Developer Forums, Mike was so kind to point out a neat trick on the command line, which helps you identify, whether APN for production is enabled:

codesign -dvvvv --entitlements - /path/to/App

<key>aps-environment</key>
<string>production</string>

If you see aps-environment=production, you should be save. Push notifications should work. If the key is missing, then you should create a new provisioning profile and rebuild you App with that.

It would be nice if Apple built this kind of checks into XCode or at least invalidate the provisioning profiles as soon as you enable Push Notifications in your App ID.

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.


Before flying off to WWDC last month, I watched a whole bunch of sessions from 2009. Among others a session on "Prototyping iPhone User Interfaces" by Bret Victor. If you haven't watched it and you've got access to the WWDC videos - stop right here and watch the video!

In his session, Bret shows how to prototype an interface only by interacting with screenshots! It's amazing that a simple screenshot on the device can show you so much more than by just looking at it in a document or print out. It inspired me to use his framework and the whole process for our own development.

Unfortunately, the code for the session isn't available and neither Bret nor the frameworks evangelist, mentioned in the presentation, got back to me about the code. After some digging, I found Michael Fey's blog, who was able to successfully reverse engineer the missing parts of source code, which were not shown in the presentation.

Michael's UIViewAdditions basically allow easy access to frame properties and give you a neat init method, which adds the passed UIView as a parent:

- (id)initWithParent:(UIView *)parent {
  self = [self initWithFrame:CGRectZero];
  if (!self)
    return nil;
  [parent addSubview:self];
  return self;
}
+ (id) viewWithParent:(UIView *)parent {
  return [[[self alloc] initWithParent:parent] autorelease];
}

There wasn't much left to do for me. I only coded the class Root, which is the parent of all UIImageView instances. It provides a couple of methods to slide images back and forth:

@synthesize pageIndex = _pageIndex;

- (id) initWithParent:(UIView *)parent {
  self = [super initWithParent:parent];
  if (self == nil) {
    return nil;
  }
  self.userInteractionEnabled = YES;
  self.size = self.window.size;
  [[UIImageView viewWithParent:self] setImageWithName:@"dailies"];
  self.pageIndex = 0;
  return self;
}

- (void)setPageIndex:(int)index {
  if (index < 0 || index >= [self.subviews count]) {
    return;
  }
  _pageIndex = index;
  for (int i = 0; i < [self.subviews count]; i++) {
    UIImageView *page = [self.subviews objectAtIndex:i];
    page.x = (i < _pageIndex) ? -self.width : (i > _pageIndex) ? self.width : 0;
  }
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
  self.pageIndex++;
}

With those two classes and a couple of screenshots, it is fairly easy to create an App that looks and feels almost real. I created a short demo video, which shows how easy it is to get a good feeling if your App is going to work or not:



Now don't forget those are only screenshots and the App might need to load stuff over the network or do some animation, hence it might not feel the same. However, this process of prototyping an UI is powerful enough to give you an idea, whether the workflow or the UI in general is going to "work" or needs some tweaking.

You can download the source code for the two classes, along with a sample project from github.

It was my first WWDC this year and I'm blown away in any aspect! In order to not sound like an Apple fan boy, I'll highlight 3 aspects, which every conference has and compare them to my previous developer conference experiences.

The speakers were all Apple engineers. They knew how to present and almost all of them were very entertaining and fun to listen to. Most important of all - they knew what they were talking about! This is something no conference I've ever been to can compete with - not even the Spring Source conferences! They were close, but mostly featured some pretty bad talks from none Spring Source consultants, which kind of ruined the experience!

This is one aspect that makes the conference worth attending. I could simply go up to the Core Animations guy and ask him why the stuff is not working as I expect it to. The best thing was, I got and answer that actually solved my problem!

Another aspect is the choice of topics and the quality of the presentations! Everything kind of fits in nicely to the whole App theme. You could listen to talks on Interface Design, followed by an in depth session on Core Animation and finish off with listening to the latest innovations on the new iPhone 4. The quality of each talk was amazing! This is the first conference ever, where I wasn't close to dozing off once! Every session was interesting and inspiring, although they sometimes overlapped in terms of content!

To be fair, I'm kind of new to the iPhone platform, so if everything was interesting for me. I don't know how that holds true for fellow developers working on iPhone Apps for a couple of years. Other conferences I attended had quality talks, too - no doubt! Devoxx, e.g. always had great talks, but there was mostly one or two a day and the rest was mostly boring.

Third and last is the organizational aspect of the conference. It's amazing how Apple manages to keep 5000 developers under control. The food, although not extensive, was very good. Soft drinks all through the day, as well as breakfast and lunch. Another thing that I was blown away is the Wifi. Apple managed to provide a fairly stable internet connection for 5000 developers with probably more than 10000 devices. It didn't always work, as you could see in Steve's keynote, but most of the time it was stable and fast.

Even though I had to travel almost a day, going back and forth to San Francisco and the conference tickets are super expensive, it's definitely worth it. So WWDC11, here I come!

Apress was kind enough to pass me a copy of this book, which I agreed to review in return.After the last book I reviewed, which was rather technical, I decided to go for a book with a tad more business angle. Personally, I was disappointed by this book, but that might not be the case for you.

Business of iPhone App Development covers exactly what the title promises: the whole process, beginning with the idea of an App over development to submitting it to the store. It's chopped up in 10 chapter, covering various steps of the process.

I'm not going into great detail explaining the content of the book. Instead, I'll write about what I didn't like. I think that should help you make a decision whether to get the book or not.

The reason why I didn't like this book is very simple: most of the information in this book can be obtained from the net or using common sense!

Let me elaborate: I think being able to obtain any information on the net these days is quite obvious. That doesn't mean you shouldn't buy this book. If you need a compact resource on topics like "Setting Up Xcode" or "Submission to the App Store", this book is definitely worth getting. If you have done this before, like me, you will be disappointed, because there's nothing new! If you are looking into more business-related topics, there's definitely topics worth reading. However, most of the technical content can be found in Apple's documentation or on stackoverflow.com. Since the book has a lot of technical chapters, I was a little bored revisiting information I already knew.

The more business-like chapters are definitely worth reading, especially if you are new to the whole App Store game. However, in my opinion a huge portion of the presented information are simple common sense! Using marketing channels like Twitter or Social Media like Facebook is standard these days and I believe there are no developers out there not knowing about those. However, some of the information seem like common sense, but it's great to have a resource to revisit from time to time, like e.g. App Store Rejection reasons. Another great chapter is "Protecting Your Intellectual Property", which you probably can't find anywhere else. It covers EULAs, licensing and trademarks.

Overall, Business of iPhone App Development encompasses a lot of information and the authors did a great job, trying to cover a lot of ground. However, I can only fully recommend this book to you, if you are new to the world of iPhone development. Otherwise, you might want to think about it twice.

Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

I'm implementing Apple Push Notifications (APN) for Doublemill Premium right now and ran into some gotchas, which I'm pretty sure are implemented somewhere else, but I'm gonna share them here with you. If you are new to APN, checkout Apple's documentation. It's pretty good and will get you quite far.

The first problem I ran into, had to do with my provisioning profile for development. I enabled APN in my Provisioning Portal, installed the certificate and implemented all the delegate methods according to the documentation, but somehow the method

- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error

was called with error code 3000 - "no valid 'aps-environment' entitlement string found for application". I was pretty sure, I setup everything correctly. However, I missed one little thing:

After you have generated your Client SSL certificate, create a new provisioning profile containing the App ID you wish to use for notifications.

That's what the Provisioning Portal tells you to do after you enabled APN. Your existing provisioning profiles are not being hooked up to APN, you really need to create new ones.

Another problem I ran into is a blocked Wifi port. Apple's documentation says:

If a cellular or WiFi connection is not available, neither the application:didRegisterForRemoteNotificationsWithDeviceToken: method or the application:didFailToRegisterForRemoteNotificationsWithError: method is called. For WiFi connections, this sometimes occurs when the device cannot connect with APNs over port 5223.

That also means neither of the methods is called when 5223 is blocked. Fortunately I came across a very helpful post on the Apple Developer Forums (sorry can't link to that here), which pointed me to a mobileconfig, enabling APN logging. If you have your phone connected and can see the log statements, you can find out if your port is blocked or something else is wrong. Don't forget to restart your phone after installing the mobileconfig, in order to enable the logging. For Doublemill the statements look something like this:

Connecting courier stream to sandbox.push.apple.com on port 5223

Connecting courier stream to push.apple.com on port 5223

Connecting to courier 2-courier.sandbox.push.apple.com

Connecting to courier 19-courier.push.apple.com

Connected to courier 2-courier.sandbox.push.apple.com (17.000.34.73)

Sending connect message with token 'xyz'

Connected to courier 19-courier.push.apple.com (17.000.36.88)
Sending connect message with token 'abc'

Recieved connected response OK

Sending filter message for enabled hashes { 34345 = "de.linsin.games.doublemill"; } and ignored hashes {}

...

Recieved connected response OK

These log statements are priceless, when hunting down the reason why you won't receive push notification in your application!

The last gotcha for today is one that I couldn't really find in Apple's documentation or at least I didn't really understand it that way. Anyways, if you distribute your App with an Ad-Hoc provisioning profile, which you would do for beta testing, the destination of your push notifications are not the sandbox, but the production. Come to think of it - it does make sense. However, you do need to create the production certificate and a new provisioning profile for it. Of course, your backend needs to be able to handle both destinations, as well!

Overall, APN is a cool feature and if you are running a server for your App anyways, it actually is for free! If your backend is running on Google App Engine, it's a different story, which I'll talk about in a future blog post.

I'm writing for the Synyx GmbH & Co. KG mobile solutions blog. From time to time, I'll cross post articles here, if I think they are of interest for you. If you'd like to read all of my other posts, subscribe to the Synyx Mobile Solutions Blog.


When you submit an App to the Apple App Store it has to go through a "rigorous quality check", conducted by Apple. Although there are plenty of resources out there, here's a short rundown of what we've learned ourselves so far:

• Marketing Apps are not allowed

If the sole purpose of your App is marketing, you'll have a hard time getting your App through. You need to add what Apple calls "user functionality". That could be something simple like a photo gallery or a feature to reserve a room or table.


• You cannot tease your users with features that they have to pay for

If you are offering a lite version of your App, you cannot add disabled functionality, which would be enabled in the paid version. A lite version usually is offered separately from a paid version, which means the user will constantly see disabled menu items or buttons, since the App will never be updated. Instead add a info section about the paid version in your App, which describes what the paid version offers.


• Don't ask your users to upgrade

You cannot add an alert in a free/lite version of your App, which asks users to upgrade or buy the paid version. Instead you should add a "buy me" button or a section in your App further describing what your paid version offers.


• Build a working App

You are definitely rejected if your App is buggy! If the reviewer thinks he found a bug, he'll reject your App. A crash is the worst case scenario, but it happens. However, don't depend on Apple as your QA, because the review times are too long to go back and forth this way.


• Don't infringe Trademarks or Copyrights

Don't mention Apple, Android or any other Trademark therefore - as long as you don't own it. You should also resist to use iPhone like icons or images.

If you respect all of these restrictions and gotchas, you should be save to get your App through the review process. I say "should", because it all appears to depend on the person who reviews your App. Let us know what you experienced, submitting your Apps, I bet there are a lot more of these gotchas.

Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

Doublemill is out the door and available for download in the App Store - finally! It has been more than two weeks since my submission. The reason why it took so long, besides Apple, which takes up to a week at the moment to review Apps, is my stupidity!

I'm using Objective-C bindings for YAJL to create and parse JSON in Doublemill's multiplayer feature. It comes with a Category for NSString, which basically makes it a two liner to create a JSON representation of a string:

#import "NSObject+YAJL.h"

NSDictionary *vals = [jsonResponse yajl_JSON];
[player fill:vals];

- (void)fill:(NSDictionary *)vals {
	NSString *key;
	for (key in vals) {
		[self setValue:[vals objectForKey:key] forKey:key];
	}
}

Okay it's not a two liner, but it's close! Anyways, in order to add this library to your project, one way is to download the build and add the static library to your Xcode project. It'll work seamlessly in the Simulator. If you want to deploy it to your iPhone or any iPhone, you need to add linker flags:

Under 'Other Linker Flags' in the Test target, add -ObjC and -all_load (So NSObject+YAJL category is loaded).

This is very common and no big deal actually. If you want to know more about why you need this, check out the Apple Developer Connection.

I added those flags for the my development environment and also for my beta testers. However, I totally missed this in my Xcode AppStore build configuration settings and since you cannot really test your final build, it went in review without those linker flags.

The reviewer at Apple found the bug, which even resulted in a crash of Doublemill. I'm grateful they found it, however I'm not really happy, that I had to wait another week to get Doublemill out the door. In the end it was my mistake and I'm sure in the future, I'll make sure to have those build profiles setup more carefully.

Last year, I worked on a Nine Men's Morris (Mühle) implementation for Android, called Doublemill. Since I'm an iPhone user, I decided to port the game to iPhone/iPod touch and the iPad. There are 3 versions: Doublemill Premium, Doublemill Lite and Doublemill for iPad.

I had to wait for a week, after submitting Doublemill Premium for review to the App Store, until Apple decided to have a look at it. Unfortunately, we were rejected - for a good reason! As it turned out, I didn't link my libraries correctly, which turned out to cause a crash every time you wanted to play online, but I digress...

It took me roughly 2-3 hours to find the bug, fix it and resubmit the App. Now I'm waiting for five days again.

Yesterday, I finished polishing Doublemill for iPad, after reworking the UI and implementing a nicer Player vs. Player experience. Since it was a rainy day and there was only Star Trek on TV, I decided to submit it for review, since it would take at least a week until they had a look at it. I want to be ready for the European start of the iPad and if there's anything wrong with Doublemill for iPad, it would take at least 2 weeks to get it into the App Store - that's what I thought!

After the usual email, you get after submitting, I instantly received another, saying my App is in review. Just like that - without waiting for a week. That got me really upset! I invested almost 4 weeks of my spare time, to gett Doublemill Premium ready and polished and I had to wait for a week until it was in review.

To me this is a clear signal, that iPad Apps are more important to Apple than iPhone Apps - at the moment. I hope this will balance again soon. It is understandable, that they want the iPad App market filled as soon as possible, but that's no reason to make the iPhone App developers wait more than a week. That takes us back to where we were a year ago: waiting and waiting and waiting - just to be rejected!

I recently bought an iPhone 3GS and while nothing is really new, just a lot faster, there's a menu in the settings which is called "Accessibility". I haven't noticed it before, but after reading through Apress' "The Business of iPhone App Development", I got curious. There is one setting, which is very interesting, called "White on Black".



This setting is for folks with any form of color-deficient vision. It helps them to still recognize the difference between certain colors. According to "The Business of iPhone App Development" roughly 1 out of 12 males of European decent are affected by this problem.

After reading this, I had to check how Doublemill looks like with this setting switched on. I'm proud to say, that it looks kinda cool and everything works as expected! See for yourself:



If you want to make your App accessible to the broadest audience possible, check if it works in Apple's "White on Black" mode.

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

I'm closing in on the first release of the paid version of Doublemill. The only thing missing is a beta test. I'm past the technical problems, which I encountered when I released a beta version of Doublemill Lite a couple of weeks ago. This is more about how to find people, willing to thoroughly and extensively test your App.

Unfortunately, I can't use Amazon's Mechanical Turk - although I'm willing to pay a small amount for people to find bugs in my App. Amazon doesn't let me use it without a US credit card, so I had to look for an alternative. I came accross iBetaTest.com. I used it for Doublemill Lite and I'm also using it for the paid version. Although the site has little flaws (it's still in beta itself), the idea is great and it works pretty well. However, there is still a problem: the people who are using the site and who are supposed to test your App.

After I added the beta for Doublemill, I received a lot of requests, mostly from testers which are not testing any other Apps or look like they have just signed up. I gave a couple of them the benefit of the doubt and let them in, only to experience, that I wasted my valuable device IDs.

At the time this blog was published, I have only received feedback from 2 of my 7 testers. The other just haven't replied. I know, that at least one has downloaded and signed up for the multiplayer feature, but hasn't provided feedback on any aspect of the App. That's just plain disappointing. After Doublemill Lite, this is the second time I wasted device IDs, it won't happen to me anymore.

After all, there's always something to learn from your mistakes: be picky on beta testers and choose people you know they'll give you valuable, honest and thorough feedback! It takes quite some time to setup a beta test and organize all device IDs, so don't neglect Q&A in your project planning.

I'm fortunate enough to have a couple of people around me, which help out with testing and give me exactly the feedback I need - although it's not always what I want to hear.

Last year I was working on a Nine Men's Morris mobile game called Doublemill. My job was to implement a REST-based server back-end on the Google App Engine. You might remember a couple of posts on that. My colleagues were responsible for coding the Android client. Since I'm an iPhone user and I'm not going to switch to Android anytime soon, I decided to port the game to the iPhone/iPod touch platform.

One week ago Doublemill Lite hit the App Store and it has been received very well, according to the download numbers. I'm pretty stunned by the magnitude of more downloads we have compared to the Google Marketplace. It could be that we only have full fledged paid version for Android out there. However, you can refund your money with Google within 24 hours, if you don't like the game, so basically every App is also a Lite version.

I believe in the App Store as a channel of distribution, although only after one week we already see the negative sides of it: user ratings. Doubemill Lite started off pretty good with 3-4 stars the first couple of days, but then rapidly dropped down to 1-2 stars. First, I was pretty bumped about it, but then realized that you are only asked to rate the App when deleting it from your phone. Considering, that less than 3% of people who downloaded the App also rated it, I guess most of the others might still happily play with Doublemill Lite.

We received some feedback, mostly about the controls, which we've already addressed and improved. There should be an update in the next couple of weeks, but at the moment I'm kinda handicapped, because my MacBook Pro died on me and I have to wait for my new one to arrive next week. With the soon to be released update, we've also added iPad compatibility, so you can have a virtual Nine Men's Morris Board sitting on your table.

There's also been progress on the premium version of Doublemill, which will go Beta any-time soon. So if you are interested in testing it, drop me a line and I'll hook you up!