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.

Private Properties in Objective-C

When a co-worker asked me if there's a way to declare a Objective-C property to be private, I could come up with an answer. Even after googling for a while, I couldn't find an example, easy enough to understand. Every time I have to search for something more than a couple of minutes and I can't find a definite source for an answer, I think it's worth a blog post.

Declaring a private property is easy, once you understood the concept of Categories and Extensions:

A category can add methods to any class, including the root class. Methods added to NSObject become available to all classes that are linked to your code.

Maybe you've used this before to enhance the functionality of a framework class. I've used it e.g. to add a shuffle method to NSArray. Extensions take the concept of a category one step further:

Class extensions are like “anonymous” categories, except that the methods they declare must be implemented in the main @implementation block for the corresponding class.

With an extension, you can easily implement private property declarations:



The @private declaration takes care of protecting the instance variable age, only the Person implementation is allowed to access it. The class extension in Person.m declares the property and it's being synthesized just the way you would with a public property.

Due to the anonymous nature of the class extension, nobody including the Person.h file can see the synthesized getters and setters, hence a private property.

Improve your dealloc method

If you are programming for any iOS device, chances are high, you've came across properties. They give you these tedious accessor methods for free and in addition to that some nice memory management features.

While explaining a colleague how to implement dealloc, he pointed me to the excellent Objective-C guide of Cocoa Dev Central.

You can see a pretty straightforward implementation of an Objective-C class there, with an implementation of dealloc, the way you are used to. However, since we have synthesized getters and setters, we can simply write the following:

Basically, the implementation of the accessor at runtime handle memory management for us here, which I think is pretty neat.