303

This is my last blog post here on blogger.com! You'll find my new thoughts, projects and development ramblings at http://dlinsin.github.com. I migrated to blogger.com in late 2005 and was always quite happy with it. More than 5 years and exactly 502 posts later it's time to move on to something new. Subscribe to my new blog feed, check my stuff on github or follow me on Twitter.

UI Test Automation with Instruments

One of the most impressive talks for me at WWDC 2010 was session 306 - "Automating Use Interface Testing with Instruments". I've been wanting to check it out ever since iOS 4 was released. A couple of weeks ago, I finally had a chance to give it a test ride with "I think I spider", one of the Apps I developed.

All you need to get started is an App, Instruments and some basic JavaScript skills. Apple provides a set of JavaScript libraries, that you can use to drive your tests and simulate user interaction. Your custom test scripts are run using the Automation Instrument in Apple's Instruments App, targeting your App either in the Simulator or on an actual device.

You can test almost every aspect of user interaction, using Apple's JavaScript library. No matter if you want to test shaking, device orientation or the basics like tapping and swiping, you can do all that using basic JavaScript function calls. Apple's documentation is quite solid, as most of them are, and explains the process in detail.

For "I think I spider" I covered the basic use cases in terms of UI, to make sure it still works after adding new features. Here is a basic example of the JavaScript involved to test "opening" the book, after starting the App:



You can see that the JavaScript API is quite easy to use and yet very powerful! After setting this up in the Automation Instrument and running it, you can see the Simulator firing up and tapping the UIImageView with the accessibility label "startscreen" after it became available. It then tests, if the main screen of the App was loaded and either passes or fails the test.

In order to make our App testable, I had to set the accessibility labels on the elements we wanted to reference from the script. That was the only change I had to make in our code. Since you should take accessibility into consideration anyways, it was a reasonable effort.

Apple did an awesome job giving us developers the ability to catch regressions and make our life easier. However, there is room for improvement, which has been nicely summarized by Air Source. For us, a missing UIALogger.warn function in the JavaScript library was the biggest downside. Sometimes it's okay for a test to fail under certain conditions, but you still want to get a warning about it. I use UIALogger.logMessage for those cases as a workaround, but it's quite easy to miss those lines, since they don't stand out.

Overall, I think it's a huge improvement to have a UI testing tool for iOS Apps at hand. There is room for improvement, but the current state of UI Test Automation is already priceless!

Word Buzz Lite

When we first planned Word Buzz, we didn't want to release a free version. It has a more exclusive feeling to it, if you can't test before you try. However, to boost your user base, there's nothing better than a free version. So here it is: Word Buzz Lite.

It's a universal App with no limitation except for one: no Game Center! It's not our decision, but more of Apple's technical limitation to only allow one App (bundle id) per Game Center instance. Another difference is the number of free built-in themes. The free version comes with only one free theme and more available through in-app purchases.

When developing Doublemill, which is a separate App for iPhone and iPad, I decided to use different XCode projects for the lite, premium and iPad version, hence different source bases for the three Apps. For Word Buzz, we decided to use a different strategy. A multi-target project for full and lite version, which are both universal Apps.

Having different source bases has a couple of drawbacks, which I experienced the hard way. One of it is fixing bugs! It's is a copy-paste task, with all its pitfalls and pain in testing. In addition to that, XCode's support for handling multiple projects isn't exactly supporting you. However, evolving the 3 different Apps, was easy and didn't affect the others in any way.

Developing a multi-target project comes with its own set of challenges. You are basically programming based on a preprocessor conditional inclusion or exclusion, which I've explained in an earlier blog post. For Word Buzz is was quite easy to cut out the additional themes and the Game Center support. However, I can imagine it can become quite complicated if you want to exclude sophisticated features. XCode comes with awesome support for multiple targets and its Organizer can still handle releases for two different versions, although it's one source base. In order to get me started, I used Chris Fletcher's blog post on building a lite version for your iPhone App. It covers the basics and brings you up to speed.

When it comes to evolving Word Buzz, we needed to shift our minds from the source-based to a SCM-based evolution model. We needed to maintain different branches, which would get quite complicated from time to time. Thanks to Git and github, we never experienced any problems bringing the various versions (branches) back together. Once you've changed your mental model to a DSCM system, it's hard to switch back, at least for me.

We are quite happy to have used multiple targets. Everything is covered under the hood of one XCode project and fixes go right into both versions. Check out Word Buzz Lite and let us know what you think!

Why Word Buzz doesn't support iOS 3.1

Word Buzz supports 3.2+, which means it doesn't support iOS 3 on iPhone. Although, my software developer ego doesn't like the fact, that we don't support the older versions of iOS, it was the right decision to do so.

It was a business decision to not support iOS 3.1, that's the short story. Rumors have it, that there are less than 10% of iOS 3.x devices out there - including iPads. That's a small enough number, to justify locking out the folks, which haven't upgraded yet.

The long story is, that we simply didn't develop with iOS 3.1 in mind. The are so many new features in iOS 3.2, which we wanted to use, that we couldn't just port it back. Let me give you a few examples:

Since iOS 3.2 you can use custom fonts in an easy and simple fashion. You add an array to your Info.plist called UIAppFonts and each item contains the filename of the font you put into your App bundle. There has been no easy way of accomplishing this before iOS 3.2, so we didn't want to sacrifice design and roll-out the 3.1 version with a system font.

Another great new feature in iOS 3.2 are Gesture Recognizers. If you don't know what I'm talking about stop right here and go read up on it - you are missing out! Although, Word Buzz doesn't use Gesture Recognizers extensively, we didn't wanna g back to the 19th century and use those old UITouch event handling stuff.

Those were just the two most obvious examples out of many! We sat down and tried to make Word Buzz run on our iPhone 3G, which still runs 3.1.3, but after a day worth of coding, we gave up. We'd love to make it run, but we'll rather invest in future proofing Word Buzz, using Blocks and GCD! We can't wait to drop iOS 3.2 support!

Word Buzz to support Game Center

Today furryfishApps is proud to announce, that Word Buzz now supports Game Center. A lot of work went into making this happen and we learned quite a bit on the way. I won't go into technical detail here, but rather cover what we've implemented.

Word Buzz lets you share your highscore and achievements on Game Center. It comes with over 16 different themes (set of words) and a lot more available for download. Each of those themes gets its own score, which will be added to your overall highscore. The sum of all highscores is shared on Game Center.

Why didn't we just share the highscore of each theme? We couldn't! Game Center lets you only share up to 20 different highscores, which is probably reasonable. It might be a bit confusing to have 40 different highscore lists.

Word Buzz is available on all iOS devices. You can play on your iPhone as well as on your iPad or iPod touch. Unfortunately, there is no way with Game Center to sync more than 20 highscores between devices. That means, you cannot just pick up with your iPad, where you left off with your iPhone. We are working on a homegrown solution, but until that happens, it's best to stick on one device.

When playing Word Buzz, you can unlock over 10 different achievements. All of them are shared on Game Center automatically, as soon as you unlock them.

What happens if you are offline? Don't worry! Your achievements and highscores are safely stored on the device and uploaded to Game Center as soon as you sign in!

Go challenge your friends and enjoy Word Buzz with Game Center.

Game Center Presentation at Cocoa Heads Karlsruhe

On Wednesday, I'll be giving a presentation on Apple's Game Center at the local CocoaHeads Group, here in Karlsruhe.

Game Center is Apple's social gaming network, that lets you invite friends to play, share your highscore and achievements through leaderboards and it even auto-matches you with other players for online-multiplayer games.

If you are interested in Game Center, drop by RetroGames on Wednesday 24th of November at 19:00.

Universal App - Word Buzz goes iPhone/iPod touch

We have been working on bringing Word Buzz to iPhone and iPod touch for more than a month now. We started out with an iPad only version, because in the beginning we thought the concept of Word Buzz wouldn't work on a smaller device. After a none-stop coding weekend and a heavy testing session, we knew it would work and started hacking on iPhone and iPod touch support.

We decided to build a universal App, because of pervasive Game Center support and a unique selling point! The latter is a no brainer: you are willing to spend a couple more bugs, if you get an iPad version for free. The former is a technical limitation of Game Center. You can only hook up your leaderboards and achievements with one App Id.

Although it was easy enough to port Word Buzz to iPhone and iPod touch, we ran into a couple of pitfalls and one of them is worth sharing with you: the default device of your universal App! What does that mean? Well, if you want to have different xib files in your App for iPhone and iPad, you need to qualify them with a suffix -iPhone / -iPad. In your Info.plist, you configure your alternate main xib with NSMainNibFile~iphone / NSMainNibFile~ipad. Since we started out with an iPad App, we decided to make iPad the default, meaning my alternate main xib configuration in Info.plist was NSMainNibFile~iphone and point to MainWindow-iPhone.xib.

This works great for iPhone and iPads, but it doesn't work for iPod touches and it also doesn't work with iOS 3.x. Somehow iPod touches (even with iOS 4) and iPhones with iOS 3.x don't respect the NSMainNibFile~iphone configuration in Info.plist. They always use the NSMainNibFile config without any suffix.

We only found out about this after testing on an actual device, which shows how important testing on each and every device is. We decided to make iPhone / iPod touch devices the default and qualify every iPad resource with -iPad, just like Apple actually intended it to be done.

Word Buzz for iPad is available on the App Store, the iPhone / iPod touch version is coming in a couple of days as a free update. Let us know what you think about it in the comments or on Twitter.

Word Buzz getting a better Twitter integration!

If you follow our tweets, which you should, you might have seen that we have been working hard on a better Twitter integration for Word Buzz. When looking around on github, I found a lot of frameworks for Twitter and iOS, but only Stefan's was lightweight and easy enough to integrate it into Word Buzz.

Most of the frameworks are full blown Twitter engines, which is not what we need for Word Buzz. Our requirements are simple: share your achievements (maybe your highscore in the future) with your followers. In addition to that, Twitter is our support channel. We wanted to allow posting public messages to @WordBuzzApp from within the App. Sounds easy, right? No need to pull in a full fledged Twitter engine for that!

Stefan's provides an API, which is really easy to use and integrate. There are no 3rd party dependencies, no need to fiddle with your linker flags - just an API to use! It even comes with a reasonable UI in Twitter style colors. Unfortunately, there was no iPad UI, which we had to implement myself. However, it was easy enough to come up with a Xib for iPad. Stefan's API provides delegate protocols, which you can implement to handle events such as "authentication succeeded". This way it's easy to separate the Twitter logic from your own code. The UIViewControllers provided, handle the most basic tasks like checking if you entered enough information to process with authentication.

We are using xAuth for authentication, which Twitter has to enable for your App. It took a couple of days until they came around to let us in, but it was the best solutions. Stefan's API provides xAuth out of the box and it works seamlessly. We added a Keychain integration to save your credentials and a flag in Settings.app to reset them.

Overall, it took us about 1 days to natively integrate Twitter into Word Buzz - thanks to Stefan's API! If anybody is interested, we are happy to provide the iPad UI and the Keychain integration.

What's new?

For the past couple of weeks it has been rather quiet here on my blog and there's a reason for that, as you can imagine.

First of all, I'd like to announce our new company furryfishApps, which I've co-founded with my wife Sutini. My future private endeavors in terms of iOS development will all take place under the hood of furryfishApps. Sutini is in charge of all the marketing, social media and publicity tasks, which are so important, but we developers never have time for. I'm glad to have her on board!

We are still in the midst of figuring out what to put on our website, but we already have an awesome logo and you can follow us on Twitter.


Our first App is a fast and engaging spelling game called Word Buzz! It's your job to spell a bunch of words as fast as possible, without making any mistake. You'll be scored on how fast you can spell and there are a whole lot of achievements for you to unlock. Go grab it here on the App Store. We welcome any feedback on Twitter or Email.

Word Buzz is iPad only at the moment, but an iPod/iPhone version with Game Center support is underway. I'll have some posts coming up soon on how the development of Word Buzz came along. It was a pretty exciting ride, as you can imagine.

APN Device Tokens

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 enable Apple Push Notifications (APN) for your App, your device generates a unique device token and pass it to the didRegisterForRemoteNotificationsWithDeviceToken method in your App delegate. Usually, you'll hand the token to your server in order for it to push notifications to your device.

There are different tokens for production and sandbox, depending on which provisioning profile you build/sign your App with. One more gotcha, you need to be aware of when it comes to those device tokens: don't mix production and sandbox tokens!

If you try to send a push notification to the production servers, using a device token meant for the sandbox, Apple's servers totally block all other notification, which you are trying to send with the same connection. If you have a scheduled push notification like we do with "I think I spider", one wrong device token ruins the fun for everyone!

We decided to separate our production and test environment and use preprocessor conditional inclusion to point to different urls in our App. Unfortunately, we had to learn the hard way how tedious this gotcha can be to track down!

Supported by:
Sherweb - Hosted Exchange Hosting
Vircom - Email Security Software

I think I Spider

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.

I'm proud to present, that our first own App has made it to the App Store last week. It's a beautiful mobile interface to the web site http://ithinkispider.com. You can find out more over at the Synyx Mobile Solutions Blog, or just hit the App icon and download it for free from the App Store!

My lovely mister singing club!

Testing Apps with In App Purchases in Simulator

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.


If you add a store to your app and use In App Purchases to collect your payments, there are a couple of limitations your have to live with. One of those limitations is not being able to fully test your App in the iPhone Simulator:

Store Kit does not operate in iPhone Simulator. When running your application in iPhone Simulator, Store Kit logs a warning if your application attempts to retrieve the payment queue. Testing the store must be done on actual devices.

Although, there is not way to test Store Kit itself, you can still test the parts of your App that use and build on the information retrieved from Store Kit. You can use a preprocessor conditional inclusion to determine, whether you are running on the simulator and then "mock" the Store Kit calls or don't execute them at all.



Keep in mind: this might not work for your App, however, it did work for my Apps and it's better than not testing your code at all. The optimal solution would definitely be to connect to the In App Purchase Sandbox environment from the Simulator.

Apple Push Notifications on Google Appengine

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!

Push Notifications in Production

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.

UI Prototyping iPhone Apps

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:



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:



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.

WWDC10

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!

Book Review: The Business of iPhone App Development

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.

Apple Push Notifications 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.

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.

Lessons learned - iPhone Review

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.

iPad Apps have priority

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!