Recently, Apple introduced several new developer stuff including Xcode 4, ARC, LLVM Compiler 3.0 and iOS 5. From some of the questions on Stack overflow, I could understand that, most of the ARC related confusions arise due to the fact that, developers don’t know if “ABC” is a feature/restriction of LLVM 3.0 or iOS 5 or ARC.

Retain cycles, auto-release pools, @autorelease blocks, oh man! So many new things? What am I going to do? You are right. ARC, or Objective-C Automatic Reference Counting is almost as magical as the iPad. No really!

In this post, I’ve made an attempt to demystify the air around this. Before starting, I’ll have to warn you that, this is a fairly long post. If you are too bored, Instapaper this article and read it later. But, hopefully, at the end of this, I believe, you will have a better understanding on how ARC works and be able to work around the innumerable errors it spits out when you convert your project.

Having said that, let’s get started.

What is ARC

ARC is a feature of the new LLVM 3.0 compiler that helps you to write code without worrying much about memory management. Memory management can be broadly classified into two, garbage collected and reference counted models. Before going to the details, let’s briefly discuss these two models and understand why ARC is even needed.

Problems with the current model.

The current memory model we use in Objective-C is manual reference counting on iOS and Garbage collection on Mac.

There are certain problems with both these memory models which probably was the reason why ARC was developed.

Garbage collection

Garbage collection is a higher level language feature probably introduced in Java (or technically, Java Virtual Machine) and implemented in a variety of other programming platforms including Microsoft’s Common Language Runtime. While Garbage collection worked well for higher level languages, Objective-C, which is still C under the hood, didn’t really fly high. Pointers (or rather references) in other languages like Java were actually objects that managed retain count and automatically releases itself when the count reaches zero. One of the design goals of C was to be optimized for performance and not “easy of use”. While pointer objects (read smart pointers) are great object oriented abstractions, they have an adverse effect on the performance of the code and since Objective-C was intended primarily for native programming where developers are used to use pointers, pointers within a structure, pointer to a pointer (for dereferencing a out parameter), it was just too difficult to introduce something like a smart pointer that would require a lot of mindset change from the developers who prefer a deterministic memory management model (Reference counting) over a non-deterministic memory management model (Garbage collection). Nevertheless, GC (Generational GC) was introduced in Objective-C 2.0 for Mac. While Generational GC doesn’t suffer from “Stop the world” issues like the mark and sweep alogrithm, they don’t collect every released variable and an occasional mark and sweep collection is still needed.

Reference Counting

The memory management model used in iOS is called as reference counting model, or more precisely, manual reference counting.
In manual reference counting model, you as a developer, have to deallocate every object you allocated. When you don’t do this, you either leak memory or over release it, causing a crash. While that counting sounds easy, Most of the memory leaks happen when you transfer ownership of objects across scope boundaries. That’s a creator method that allocates an object for you and expects the caller to deallocate it. To circumvent this problem, Objective-C introduced a concept called autorelease. auto-released variables are added to the auto-release pool and are released at the end of the runloop. While this sounds too good, auto-release pools do incur an additional overhead.

For example, comparing the two code blocks,

{
    NSDictionary *dict = [[NSDictionary alloc] init];
    // do something with the dictionary here
    // I'm done with the dictionary, I don't need it anymore
    [dict release];
    // more code
}

and

{
    NSDictionary *dict = [NSDictionary dictionary]; // auto-released object
    // do something with the dictionary here
    // I'm done with the dictionary, I don't need it anymore
 
    // more code
}

the first block is an example of optimized use of memory where as the second depends on auto-release pools. While this block of code doesn’t really incur significant memory overhead, code like these slowly adds together and makes your reference counted model heavily dependent on auto-release pools. That is, objects that you know could be deallocated, will still linger around in the auto-release pool for a little longer.

Automatic Reference Counting

Say hello to ARC. ARC is a compiler feature that auto inserts retain and release for you. So in the first code block of the above example, you no longer have to write the release method and ARC auto-inserts for you before compilation.

{
    NSDictionary *dict = [[NSDictionary alloc] init];
    // do something with the dictionary here
    // I'm done with the dictionary, I don't need it anymore
    [dict release]; // ARC inserted
    // more code
}

When you create an autoreleased object, like in the second block of code, ARC compiler is clever enough not to add a release call. Sound great, so how should I go about doing this ARC thing? Just delete all release/retain codes and pray? Unfortunately, it isn’t that easy. ARC is not just some auto insert or macro expander kind of tool. It forces you to think in terms of object graphs instead of memory allocation, retain or release. Let’s delve a little deeper into ARC.

Compiler level feature

ARC is a compiler level feature. I repeat. ARC IS A COMPILER LEVEL FEATURE. This means, when you use ARC, you don’t have to worry about upgrading your deployment target and so on. However, only the latest LLVM 3.0 compiler supports ARC. If you are still stuck with GCC, you are out of luck. (Meh!) Some more points that you should know about ARC are,

• ARC is backward compatible with libraries and framework compiled with under non-ARC.
• ARC can be used within your project on a file-by-file basis. So you can mix and match ARC code with non-ARC code.
• You can also integrate ARC compiled libraries into your project that doesn’t use ARC and vice-versa.
• You use a compiler switch to turn ARC on and off.
• (The keyword here is compiler switch)
• You can also set the complete target to build with ARC by default (and use non-ARC compiler only when instructed so.) This is shown in the illustration below.
• 

The two main compiler switches that you would often use are when you build your application with a third party library that is not ARC compliant and vice versa, are

• -fno-objc-arc
• -fobjc-arc

-f is the switch and no-objc-arc and objc-arc are the options that you are turning on. As evident from the names, the first one turns off ARC and the second turns on.

For example, if your application is ARC enabled but a third party library is not, you use the first switch -fno-objc-arc to exclude the third party library. Conversely, if your application is not yet ARC enabled (gasp!) but the third party library you are integrating is, you use the second switch -fobjc-arc You add these flags to the project from the Build phases tab as shown below.

Also a run time feature

Wait! You just told me (and repeated) that ARC is a compiler level feature? Now what? Sorry, I hear you, but, unfortunately, things aren’t that easy and it doesn’t just stop here. ARC also backs up on a runtime feature called zero-ing weak references. Oh, damn, another keyword! I should have introduced this before. But that’s ok. We will revisit about the run-time dependency of ARC, a little later in this post.

ARC Ownership qualifiers

As I showed you earlier, ARC automatically inserts releases and retains in your code in a pre-compilation step. But for ARC to know when to release your objects and when to retain them, you need to somehow tell the life of your variables. You use ownership qualifiers for that. A strong understanding of ownerships is vital to understand and use ARC properly. Once you understand this concept, you will be thinking in terms of object graphs instead of retain/release. Secondly, when you use ARC, all variables local or ivars are initialized to nil automatically for you. This means, there is little chance of having a dangling reference in your application.

• __strong
• __weak
• __unsafe_unretained
• __autoreleasing

The first qualifier, __strong, is the default and you might not even be using this explicitly. It is use to tell the ARC compiler that, the declared variable “owns” the reference. The opposite of this is __weak, which tells the ARC compiler that the declared variable doesn’t own the reference.

The __weak is synonymous to the “assign” modifier. You normally use assign modifier for IBOutlets and delegates. Under ARC, this is replaced with __weak. However, there is a caveat. __weak requires you to deploy the app on a runtime that supports zero-ing weak references. This includes, iOS 5 and Lion. Snow Leopard and older operating systems or iOS 4 and older operating systems don’t support zero-ing weak references. This obviously means you cannot use __weak ownership modifiers if you plan to deploy to older operating systems. Fret not. ARC includes another ownership qualifier, __unsafe_unretained that is synonymous to __weak, except that when the pointer is de-referenced, it is not set to nil, but remains dangling. A while ago, I told something about zero-ing weak references? When the runtime supports zero-ing weak references, your __weak variables are automatically set to nil when they are released. This is the only feature that requires a higher deployment target (iOS 5/Lion). Otherwise, you are good to deploy on iOS 4/Snow Leopard.

A couple other important things to know about __weak vs __unsafe_unretained is that, the compiler doesn’t allow you to use __weak when your deployment target is set to a operating system that doesn’t support zero-ing weak references. The Convert to Objective-C ARC wizard uses __weak only when your deployment target supports zero-ing weak references. So if your deployment target is iOS 4, the Objective-C convert ion wizard will replace assign modifiers with __unsafe_unretained instead of __weak.

The last ownership qualifier, __auto_releasing is used mostly when passing a reference to a function for writing out. You would use this in places where you normally use pointer indirection like returning a NSError object via an out parameter.

Properties in your header file can also have the above ownership qualifiers except the __auto_releasing. When applied to properties, ARC automatically generates the correct code in dealloc to release them when the object dies.

Lastly, and more importantly, all of ARC managed objects are initialized to nil when they are created. So, again, no more dangling pointers because you forgot a initialize statement. However, do note that this initialization doesn’t initialize primitive data types. So a declaration like,

int a;

might contain a garbage value for a.

Whew! That’s pretty taxing. Take a break. We just started.

ARC knows more Objective-C than you

ARC also taps into a the Objective-C language naming conventions and infers the ownership of the returned object.

In Objective-C, a method that stats with any one of the following prefix,

• init,
• alloc,
• copy,
• mutableCopy and
• new

are considered to be transferring ownership of the returned object to the caller.
This means, in your application, when you create a method, ARC automatically infers whether to return a autoreleased object or a +1 retained object from your method name. In fact, in most cases, instead of returning auto-release objects, ARC just inserts a manual release in the calling code, automatically for you. However, there is a small caveat. Let’s assume that you have a method that starts with “copy”, as in

-(NSString*) copyRightString;

ARC assumes that it would transfer the ownership of the returned string to the caller and inserts a release automatically. Everything works well, if both the called method and the calling method are compiled using ARC.

But if your “copyRightString” method is in a third party library that isn’t compiled with ARC, you will over-release the returned string. This is because, on the calling code, ARC compiler inserts a release to balance out the retain count bumped up by the “copy” method. Conversely, if the third party library is compiled with ARC and your method isn’t, you will have a memory leak. You can however override this behavior by adding one of the following attribute to your methods.

• NS_RETURNS_NON_RETAINED
• NS_RETURNS_RETAINED

So your method will now look like this.

-(NSString*) copyRightString NS_RETURNS_NON_RETAINED;

You can also rename the method name to copyrightString (note the case) or getCopyRightString instead of adding an attribute. However, I wouldn’t recommend the former method as it breaks the cocoa naming conventions (prefixing a method with “get” or “set” is Java-ish)

You will see methods having the NS_RETURNS_* prefixes throughout the header files in Apple’s own UIKit.framework or the foundation classes. Now that you know what happens behind the scenes and how compiler treats these decorations, you can solve crazy memory issues, like a crash when you call a copyRightString in your method in a third party library.

With that, let’s get ready for climbing the next peak.

Toll-free bridging

ARC doesn’t manage Core Foundation objects. They say, there is no free lunch. ARC, takes it one step further. There is no free-casting between Core Foundation objects and equivalent Objective-C objects (NS* objects). Yes, that’s right. You cannot cast a Core Foundation object to an equivalent Objective-C object (NS* object) without telling ARC how to manage ownerships.

Let’s now see how to specify ownership transfers when you cast a Core Foundation object.
The following ownership transfer modifiers should be provided when you cast a Objective-C object to a Core Foundation object.

• __bridge
• __bridge_retained
• __bridge_transfer

When you migrate a project to ARC, you would have seen error messages like the one below.

ARC Error because of a missing bridge attribute in a Toll-free bridging code

You might also have proceeded by accepting the suggestions provided by the LLVM compiler. But now, let’s dig deeper and understand the “why” behind it.

The modifier, __bridge tells the ARC compiler that, it’s a plain simple, bridging cast. That means, you ask the ARC compiler to do nothing extra when the transfer is made. You might think, if that is the case, Apple could have made this the default choice. But it was not made probably because, it’s to preposterous to make such an assumption. Making such a bold assumption means, you would easily leak memory as there isn’t a easier way to tell when you are actually releasing a Core Foundation object unlike a Objective-C object.

The second modifier, __bridge_retained is used to tell the ARC compiler that the Objective-C object should be transferred to Core Foundation by bumping the retain count by 1 and it should be treated as if it is a newly created object (as opposed to a auto-released object). You use this modifier if the method was probably named like a creation method (starting with init, copy, mutableCopy etc.,) or if you are going to release the Objective-C object inside of Core Foundation using methods like CFRelease.

The last modifier, __bridge_transfer is used to tell the ARC compiler that the Core Foundation object is to be transferred to ARC with a retain count of 1. This is used if you created a Core Foundation object using one of the CF***Create methods and want the ARC compiler to handle the memory management for you. That’s you are transferring a Core Foundation object to ARC with a retain count of 1.

As a side note on this, avoid using __bridge_retained and __bridge_transfer to trick the compiler to add retain and releases for you. Use it to improve your code readability and minimizing the number of manual memory management calls. (Move on if you don’t understand this line. You will start understanding this automatically when you start using this in your own code)

How does ARC work internally?

ARC ain’t magic, if you know how it works. But a little knowledge is a dangerous thing. Knowing how the ARC compiler works will help you more in understanding the error messages and compiler warnings spat out by it.

The ARC compiler has two main parts, a front end compiler and an optimizer.

ARC front end

The ARC front end compiler checks for every “owned” Objective-C object and inserts release appropriately. By owned object, I mean, an object whose ownership qualifier has been set. For example, if the “owned” object is a local variable, ARC front end compiler inserts a release at the end of the scope. This is because, by default all local variables are “strong” ly owned. If the object is a instance variable, the ARC front end compiler inserts a release statement in the dealloc method, if the ownership type is strong. For unsafe_unretained or weak ownership ARC doesn’t do anything. It also takes care of calling the [super dealloc] for you and intact ARC compiler doesn’t allow you to explicitly call dealloc.

The ARC front end compiler also takes care of generating errors when it encounters a variable (local or instance) whose ownership qualifier is not set or when you explicitly calling dealloc.

ARC optimizer

The function of the ARC optimizer is to optimize the retain and release statements by removing them if they are inserted multiple times by the ARC front end compiler. It is this optimizer that ensures that performance is not affected by calling retain and release multiple times.

The actual Migration using Xcode 4.2

Xcode 4.2 has a wizard to automatically migrate your code for use with the ARC compiler. This means, the wizard rewrites some of your code, removes calls to retain/release and removes dealloc methods and calls to [super dealloc] for you.

The first step is to open your project, select Edit -> Refactor -> Convert to Objective-C ARC from the menu.

Migrating to Objective-C ARC using Xcode 4.2

When you select this option, you will be asked to select a target. If you have only one target, it’s fine. If you have multiple targets in your application, you have to perform the ARC migration on every target. After you select a target, the wizard by default selects all source code files that belong to that project for ARC migration. If you are using third party libraries that are not yet ARC ready, you can uncheck those files in this step. This is illustrated in the screenshot below.

Selecting your files for ARC exclusion

In the above project, since I know that ASIHttpRequest is not yet ARC compatible, I’m selecting them and command-clicking them to show the option to uncheck all of them. When you do this, the wizard automatically adds a -fno-objc-arc compiler flag for all these files.

The next step is to start the pre-checking process. The pre-checking process compiles the project and analyzes for potential problems before performing the actual migration. You might almost and always get a error message like this.

The dreaded error message!

Of course, 58 errors in this screenshot is actually quite low. You should expect anywhere in the range of 300+ for a mid sized project. But fret not, they aren’t complicated at all to fix.

Common ARC migration errors

The number of errors that might prevent you from converting your project to ARC is usually high if your code is “old” or if it doesn’t adhere to Objective-C design patterns. For example, accessing a iVar. While it’s technically ok, you should almost and always use properties to access them outside of init and dealloc methods. If you have been using properties, ARC migration would be painless. If you were old skool, you have to feel the pain now. In this last section, I’ll show you the most commonly occurring errors when you migrate your project.

Cast of Objective-C pointer to C Pointer type

This error is generated because ARC doesn’t do toll-free bridging for you. As I explained before in the section, Toll-free bridging, requires the developer to explicitly specify ownership transfer qualifiers.
Use the various ownership transfer qualifiers I showed you before to fix this problem.

performSelector may cause a leak because its selector is unknown

We now know that Objective-C ARC compiler knows more Objective-C than you. This error message is because of that. The ARC compiler tries to identify the method family and determine whether to add a retain or release to the returned value from the caller code. This means, if your method starts with init, alloc, copy, mutableCopy or new, the ARC compiler will add a release to the calling code after the variable scope ends. Since are using a selector to call a method dynamically at runtime, ARC doesn’t really know if the method called returns a +1 retained object or a auto-released object. As such, ARC cannot reliably insert a retain or release to the returned object after its scope ends. This warning is shown to warn you of potential memory leaks.

If you are sure that your code works fine without memory leaks, you can ignore this warning. To suppress this warning, you can turn off the compiler flag -Warc-performSelector-leaks warning on a line by line basis like this.

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
    [self performSelector:self.mySel];
 #pragma clang diagnostic pop

Unfortunately, you cannot annotate a dynamic selector using __attribute__ ((objc_method_family(*))).

Receiver type “*” doesn’t declare the method with selector “*”

ARC mandates that every method you call should be declared properly. With GCC, this was a warning. But LLVM makes this step mandatory since ARC needs to accurately identify and that is why you see an error like this.

Error that you see when you don't declare a receiver type

This error is also because of the fact that ARC needs to identify the method family to determine if it has to add a retain or release to the returned object. For example, in the above code, the method, returnMyGreatObject might return a NS_RETURNS_RETAINED. In this case, the ARC compiler has to insert a release after the returned object goes out of scope. The ARC compiler can know this only when you declare it formally. This is why, under ARC method declarations are mandatory. If you have been declaring methods formally under GCC, even when the compiler didn’t enforce (so that the code was aesthetically beautiful) you wouldn’t see this error at all. As I said before, the number of ARC migration errors is directly proportional to the quality of code you write. Fixing this error is fairly simple and all you have to do is to declare every method formally in the header file or on a private category extension.

Common workarounds that you use in ARC on code that otherwise looks normal

In some cases, while using ARC, you might end up writing code that looks as if it’s written to “please” the ARC compiler rather than writing natural code. Unfortunately, nothing can be done to this and we all have to live with this. The next two sections explain when you might need to write unnecessary code like this to please the compiler.

Capturing “*” strongly is likely to lead to a retain cycle

ARC and retain cycles

The last category of warning message is shown when a retain cycle is detected in your code. An example is shown below.

This code was probably leaking the request object before ARC and increasing your memory footprint. But, thanks to ARC. You now know that code like these cause retain cycles that cannot be released automatically. Circumventing a retain cycle issue almost and always ends up breaking the cycle with a weak reference.

Fixing this error is fairly simple and in this case, you can get a weak reference to the request object and copy it to the block. Within the block, convert it again to a strong reference. This is illustrated below.

Workaround for ARC and retain cycle issue

In the above code block, you can also replace references to __unsafe_unretained with __weak if you are deploying to a runtime that supports zero-ing weak references.

Avoiding retain cycles using __block

Sometimes, you need an object to live till as long as the completion handler on it can live. For example, a Block based UIAlertView can call a completion handler after the user presses a button on the UIAlertView.
For example,

UIAlertView *alertView = [UIAlertView alertViewWithTitle:@"Test" buttons:[NSArray arrayWithObjects:@"Ok", @"Cancel", nil] completionHandler:^(int tappedButtonIndex)  {
 
	// do something based on the button tapped on alertView
}];
[alertView show];

In the above case, the alertView gets deallocated by ARC as soon as it’s shown and the call to completionHandler never gets executed (or even crashes).
To prevent this, you can use the __block decoration on UIAlertView declaration and copy it inside the block like

__block UIAlertView *alertView = [UIAlertView alertViewWithTitle:@"Test" buttons:[NSArray arrayWithObjects:@"Ok", @"Cancel", nil] completionHandler:^(int tappedButtonIndex)  {
 
	// do something based on the button tapped on alertView
	alertView = nil;
}];
[alertView show];

ARC takes care of releasing it when you nil it inside the completionHandler. You will find this pattern used a lot when you work with completionHandlers in TwTweetComposeViewController or even UIViewController presentViewController:animated:completion: methods.

That last question

When should you migrate?

NOW

The performance benefits you get by using ARC is remarkable. Apple claims that the @autoreleasepool is over 6 times faster than NSAutoReleasePool objects used in your non-ARC code. This is because, @autoreleasepools don’t allocate objects and all it does is must bump up the pointer retain counts. Similarly, NSObjects’ retain and release are optimized that you can expect a performance boost of anywhere around 2.5x. The third important performance benefit you will see is in methods that return autoreleased object. Under ARC, this variable is no longer transferred using the auto-release pool and what instead happens is a ownership transfer. Again this is upto 20x faster.

Hence, don’t wait till your dependent third party frameworks are migrated to ARC. You can always exclude them and go ahead and convert your code to ARC now.

Where to go from here?

• WWDC 2011 – Session 322 Introduction to Automatic Reference Counting
• WWDC 2011 – Session 322 Objective-C Advancements in depth
• Stop: You are warned. This link is only for hard code geeks. http://clang.llvm.org/docs/AutomaticReferenceCounting.html
• WWDC 2011 – Session 308 – Blocks and Grand Central Dispatch in Practice

One last word, treat this post as a living document. I’ll be updating the last few sections on new workarounds as and when I find a fix for them.

–
Mugunth

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

Related posts:

1. MKStoreKit 4.0 – Supporting Auto Renewable Subscriptions MKStoreKit started off in a pet project a couple of...

Couple of weeks ago, I wrote a clean, fast networking toolkit for iOS and Mac written for the LLVM Compiler 3.0 with ARC.
Reception was very good that it was the “most-watched” repository on Github last week. Early adopters have sent me innumerable emails on how fast their network operations are, and how responsive their app is after integrating MKNetworkKit.
MKNetworkKit is faster (and it makes your app feel smoother and faster with seamless transparent caching) in reality. There are two things that makes MKNetworkKit faster.
First, it’s ARC based and the awesome LLVM 3.0 compiler brings in a ton of performance benefits. Using the @autoreleasepool block instead of NSAutoReleasePool in MKNetworkOperation alone should improve the performance by a huge factor (Apple claims it to be 6 times faster). If you still haven’t migrated to ARC because you want to support those iOS 3.x users, read this post by Matt Gemmell first.

Second important performance benefit is seamless and transparent caching. By transparent caching, I mean, caching that involves zero overhead from the developer (That’s you).

Let me, in this post, brief you about how this seamless caching might help you. First, an example. You are refreshing a twitter stream. A GET request for that looks similar to

GET http://twitter.com/mugunthkumar/statuses

Caching your responses, the wrong way

Some developers cache responses using Core Data. STOP IT

Using Core Data for caching is like using the military to kill bedbugs in your bedroom. DON’T DO IT.

The problem when you implement Core Data is, you should program your view controllers to work with two kinds of data structures. One, JSON/XML from server and the other, Core Data NSManagedObjects. Some “clever” developers “take it to the next level” by just programming their view controllers to work with only Core Data. The design goes like this. The network layer talks to the server and updates Core Data Store. Once the store is updated, send a NSNotification to “refresh” view controllers.
This may sound clever to many. But it’s completely WRONG. I REPEAT. COMPLETELY WRONG. Core Data (or even structured SQL storage) is not meant for that. Core Data is a structured storage for persisting/serializing Object graphs in your application. Don’t use it for storing objects that have a low life time. Thumbnail images, list of tweets etc., just don’t belong there. Secondly, this would require you to read and write to flash memory on the iDevice which have a limited read/write cycle. Finally, reading and writing to disk (in this case, Core Data) is a very ugly way to transfer data from one class to another (in this case, from your Network Layer to View Controllers)

Say hello to MKNetworkKit

MKNetworkKit calls the SAME completion handler with cached data if you are making the call for the second time. When the network connectivity is proper, MKNetworkKit calls your completion handler twice. First with the cached data and again after fetching the latest data from server. As such, you can design your view controllers to work with just ONE kind of data, data from server. If you have an app that doesn’t cache and doesn’t work offline, just replace your networking library with MKNetworkKit and you get caching for free. Not even a single line of code change is required on your view controllers. Caching is transparent. Your view controllers needs to work with the same data structure, no matter whether the data is from cache or server.

Behind the scenes

MKNetworkKit caching is super light-weight and it caches your responses in a NSMutableDictionary. Doesn’t that lead to high memory usage? Yes. of-course, but MKNetworkKit is clever. It observes the UIApplicationDidReceiveMemoryWarningNotification and flushes the dictionary to disk. The next time you make a request to the cached URL, the cached data is brought back to memory. So in-effect, it has a in-memory cache and disk cache and uses a least recently used algorithm to flush items to disk. The MKNetworkEngine class has methods that can be over-ridden to control the cache cost.

Just override the method

-(int) cacheMemoryCost;

and return a higher/lower value based on your application’s requirements.

MKNetworkKit caching works like a intermediate proxy server by intercepting the response headers. So, when a second GET request to the same URL is made, MKNetworkKit behaves the following way.

1) For GET requests that sent a ETag in the header previously (for example, requests to Amazon S3 servers), MKNetworkKit sends a second request as a HEAD request (even if you specify as GET) with IF-NONE-MATCHheader. Most servers that send ETag (like Amazon S3) responds to IF-NONE-MATCH by sending the real data only when it has been changed. Otherwise, they return a 304 Not Modified which MKNetworkKit safely ignores. So data transfer is really not huge. Even this request is honored only after 1 day. So, repeated requests to the same thumbnail image doesn’t even hit the server.

2) For any GET request that contained a Cache-Control:max-age=in the header, MKNetworkKit honors that and makes the second request only after the expiry date. For dynamically generated requests, you should set Cache-Control on server. This not only helps MKNetworkKit, but most proxy servers along the way.

3) For requests that contained a Last-Modified field in the header, MKNetworkKit sends a “IF-MODIFIED-SINCE” HEAD request. This again works like the IF-NONE-MATCH. The server, either sends the complete data or a 304 Not Modified.

4) For servers that implement Cache-Control: no-cache, MKNetworkKit goes one step ahead and makes a second request only after a minute (60 sec). So repeated refreshes to often refreshed page will not exactly hit the server. For example, refreshing foursquare check-ins. It’s rare for these information to change within the next 60 sec.

5) For performance reasons, when the response type is an image, and the response headers doesn’t have any cache control information, MKNetworkKit assumes an expiry date of 7 days.

The last two are not an RFC standard. But these optimizations make network operations fast on a mobile devices even if the server isn’t implemented in an optimized way. All POST, PUT, HEAD and DELETE requests are ignored and not cached.

And, of course, you can customize all these behaviors by editing the values in MKNetworkKit.h

Freezing Operations

Another very important feature of MKNetworkKit is operation freezing. Imagine that, your customer take an awesome photo with your own “Instagram-killer” app, but since he is at a remote exotic place, 3G connectivity is poor and uploading the photo fails. Without MKNetworkKit, you should remember the photo related meta data, store the photo’s NSData in a file and upload the operation the next time the app is launched. Painful!
With MKNetworkKit, you mark the photo upload operation is “freezable”. This means, in the event of network failure, your operations are automatically serialized (frozen beneath snow) and restored the next time the app launches, all for free.

MKNetworkOperation *op = [myEngine operationWithPath:@"/imageUpload" params:paramsDict httpMethod:@"POST"];
[op setFreezable:YES]; // ONE EXTRA LINE
[myEngine enqueOperation:op];

You can mark any POST/PUT/DELETE operation as freezable. GET operations are not freezable and MKNetworkKit ignores your call to setFreezable: if your operation is a “GET” operation.

Advanced Tips

Friction-free authentication

MKNetworkOperation *op = [myEngine operationWithPath:@"/letmein"];
[op setUserName:@"mugunth" password:@"mYsEkReTpAsSwOrD"]; // ONE EXTRA LINE
[op setUserName:@"mugunth" password:@"mYsEkReTpAsSwOrD" basicAuth:YES]; // OR THIS LINE
[myEngine enqueOperation:op];

When your server uses HTTP Basic auth or Digest auth or even Windows NTLM authentication, all you need to do is to set your username and password and MKNetworkKit auto-magically authenticates your request!. For NTLM authentication, just ensure your username is “domain\username”. There is no separate method setDomain: or something.

You can also set basicAuth:YES to send the credentials even before receiving the authentication challenge. However, this works only if your server uses HTTP Basic Authentication.

Custom Authentication

If your server uses HTML Form authentication, you can override the authHandler block and provide custom auth mechanisms.

MKNetworkOperation *op = [myEngine operationWithPath:@"/letmein"];
op.authHandler = ^(NSURLAuthenticationChallenge *cred) { 
// show a web view controller or do whatever you want and finally, when you have a credentials ready, just call 
[challenge.sender useCredential:credential forAuthenticationChallenge:challenge];
};
[myEngine enqueOperation:op];

Overriding MKNetworkEngine

Tweaking the URL building methods with MKNetworkEngine is easy. Let me start by giving you an example. Imagine that you have a server which authenticates a logged in user and after authentication, it expects a Authorization header to be set with an access token.
You need to have a factory method that creates URLs customized to your web service. This could include adding a authorization header in our case. You can do this by overriding the method,

-(void) enqueueOperation:(MKNetworkOperation*) operation;

For example, in the above case, you can check your engine subclass for an access token and add it to the operation’s header in this method (if you have one).

Overriding MKNetworkOperation

Sometimes, you might do custom error handling based on the response from your server. For example, your server might send a valid HTTP response (status code 200) which could be an internal error, like “Invalid User”. Business logic errors are better handled with your own application level error codes. You overriding MKNetworkOperation to customize the success/failure reporting. I would highly recommend doing this along with designing your server to send error codes for error conditions.

The following methods are to be overridden for customizing error handling.

-(void) operationSucceeded;
-(void) operationFailedWithError:(NSError*) error;

For example, in the previous case, you can override operationSucceeded, inspect the response and if the response was indeed a business logic error (“Invalid User”), you can call the [super operationFailedWithError:[Your custom error class for "Invalid User"]];
Otherwise, call [super operationSucceeded].

You can also override operationFailedWithError to introspect the actual cause of the error, if your server sends any error related information in the dictionary.

The reason for overriding at this level is to minimize error handling at view controller layer. So your presentation layer, UIViewController subclasses will be cleaner to read.

If you have subclassed the MKNetworkOperation and want the factory method in your engine subclass, operationWithURLString:params:httpMethod to prepare an operation of your subclass. To register your operation subclass with the engine, you can call the registerOperationSubclass: method.

-(void) registerOperationSubclass:(Class) aClass;

Your code fragment might look like,

[self.myEngine registerOperationSubclass:[MyAppNetworkOperation class]];

Image Cache with MKNetworkEngine

MKNetworkEngine has a handy method to load images from a server. It’s built-in cache mechanism ensures, your images are cached without using any third-party image cache libraries. That means your code base is even leaner.
You can use the following method of MKNetworkEngine to load images.

-(void) imageAtURL:(NSURL *)url onCompletion:(MKNKImageBlock) imageFetchedBlock;

MKNKImageBlock is defined like this.

typedef void (^MKNKImageBlock) (UIImage* fetchedImage, NSURL* url, BOOL isInCache);

So your calling code will look like,

    [ApplicationDelegate.myAppEngine imageAtURL:[NSURL URLWithString:@"http://example.com/image.png"] onCompletion:^(UIImage *fetchedImage, NSURL *fetchedURL, BOOL isInCache) {
        self.imageView.image = fetchedImage;
    }];

If you are loading images onto a imageView inside a tableview cell, you can check if the completed URL is same as the passed URL

    [ApplicationDelegate.myAppEngine imageAtURL:[NSURL URLWithString:@"http://example.com/image.png"] onCompletion:^(UIImage *fetchedImage, NSURL *fetchedURL, BOOL isInCache) {
	if(originalURL == fetchedURL)
        cell.imageView.image = fetchedImage;
    }];

This check is necessary as tableview cells might be recycled and a cell might end up getting images from multiple network operations.

You might also want to read my other elaborate post on Image Caching with MKNetworkKit

Lastly, if you are fading in your images like those fancy apps, add your fade-in logic if the image is loaded from server and not from cache.

Source Code

MKNetworkKit on Github

MKNetworkKit might look simple, but it’s incredibly powerful. Use it in your apps and tell me how it scores. My next blog post would be on how to write a better RESTful server that serves a mobile device. Watch this space, subscribe to my feed or follow me on twitter.

Interested in learning in-depth features of Objective-C and iOS? You should get my book.

Amazon - http://mk.sg/ios5book

iBooks - http://mk.sg/ibook

Wiley – http://mk.sg/book

Book Depository – http://mk.sg/bdbook
–
Mugunth

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

Related posts:

1. iOS Tutorial: Image Cache and Loading Thumbnails using MKNetworkKit If you have been following me on Twitter or reading...
2. iOS Framework: Introducing MKNetworkKit How awesome would it be if a networking framework automatically...

Release early, release often is a philosophy where you release the product as soon as possible and rapidly iterate it to perfection by listening to your customers. A polished release, on the other hand is where your product, in its initial version is solid, lacks obvious bugs and has just enough features to satisfy a majority of your consumers. Most software companies adopt either one of this and that choice is not superficial. In fact, it roots down to the heart of the company’s ideologies.
Before you launch your next big product, website, app, read this and decide which side you are on.

Philosophy followed by them

Release early, release often, has always been the mantra of Linux kernel, software from Microsoft and plenty other open source software. Microsoft (and Microsoft developers) followed this philosophy since its inception. The Windows Operating System, in the initial version (1.0) did not support overlapping windows which was a breakthrough feature on the then contemporary Macintosh. Despite that, a few years later, Microsoft was able to catch up with the competition by following the release early, release often philosophy. In 1995, the same race happened between Microsoft and Netscape with browsers. IE 1.0 was no where near Netscape, but a couple of years later, the fourth iteration of the browser, IE 4 nailed it.

In late 90s, when the web became popular, updating your software (web application) became even easier and web application developers, continued to follow the same mantra.

The workflow of a web developer used to be like this.

Make a shitty website
Improve your website
check your visitor count
…
Improve your website
check your visitor count
…
…
Once your reach a satisfactory level, mark your release as final (remove that beta/gamma tag).

Later in 2004, when Google introduced their Gmail, it was known for the perpetual beta in the logo.
Flickr moved from alpha to beta to gamma(!) in 2006!

Philosophy followed by Apple

Apple on the other hand polish their products to perfection. May be it’s their “Think different” culture or may be it’s the ingrained attitude of the late founder, Steve Jobs, to make “insanely great” products relegating profits or business strategies.

The first version of iOS (then called as iPhone OS), did not even have MMS, included in even the dumbest phones out there. Yet, every feature that was available, worked really really well. The first iPod, despite being available only for Mac users, was a runaway success.

Consumer mindset outside of Software

Let’s for a moment think outside of Software. Let’s take movies for example. Every single release of a movie, whether it is The Jurassic Park and its sequels or The Matrix and its sequels or Steve Jobs’s own Toy Story and its sequels never had “versions”.
The movies were great right from the first release and the producers and directors never “planned” to make their movie incrementally better. Of course there were sequels, but they were not “bug fixes” or incremental updates to the original movie. The same holds good for physical commodities like cars or cameras. Remember, the world had cars, cameras and movies, much before Software. So, how and why did people got accustomed to this way of life, when it comes to Software? Will you accept if your new car, in its “version 1.0″ doesn’t speed up beyond 60? Will you accept if the car manufacturer promises a free “engine update” in the “near future”?

The reason was partly because, at least in the past, software was considered “Magical”. The first spreadsheet program (Lotus 1-2-3) can “sort” the marks of student in ascending order and made the process of calculating the rank among students in a class, super easy, fast and reliable. What usually took days, was accomplished within seconds using Software. Other commodities did not provide this level of satisfaction.

When something performs well on one area, human beings tend to be lenient in evaluating its performance else where. That “something” can be anything. A beautiful blonde girl who is “not so smart” or a restaurant that serves tasty food, but looks shoddy (or the other way round). This is precisely what happened to user’s perception of Software decades ago and unfortunately, has been continuing till now. A software that does one thing (sorting in this case) properly, but crashes often was still acceptable.

How Apple changed your consumers

Apple, on the other hand, tend to think differently. They never use the “beta” tag. (And when they do, it is still better than the competition). Look at the iterative changes that happens to any of their product. It, mostly remains same. The first iPod, still looks closely similar to the latest generation iPod classic and the first iPhone looks closely similar to the latest iPhone, the iPhone 4S and Mac OS X 10.0, looks closely similar to Mac OS X Lion. Leave software, even the light bulb invented by Edison a century ago, looks very similar in shape and size compared to the tungsten filament light bulb today. Contrarily, compare that to the control panel on Windows 95 to Windows 7 and the upcoming Windows 8 beta. It’s clear that, Microsoft didn’t nail it and they still haven’t nailed it.

With iPod, iPhone, iPad and several other products, Apple has proved that, Software can be done right, right from the initial version and has re-wired users’ brain to expect quality products even when it is Software. This can be seen on the ratings of same apps from the same companies on Apple App Store and Android Market Place. Ratings on Market Place is usually higher than on App Store even if the Android version is buggier. Apple users expect quality. They don’t tolerate sh*t.

These two philosophical differences might have stemmed from the thought process of Steve Jobs and Bill Gates who shaped the early software industry. Steve was a perfectionist. Anything less than the ultimate is a shitty product. Bill on the other hand was different. He was more focussed on the monetary aspects of things (that doesn’t automatically mean it’s bad) at the expense of quality.

What should you do?

The release early, release often mantra has created a notion that Software is unreliable and often buggy. Since most software are like that, consumers, more than not, aren’t willing to pay for Software just as easy as they would for anything else. When we learn this, we complain that, their attitude is wrong. We even go as far as comparing the cost of a Starbucks coffee to an app and say people don’t pay for software that costs a fraction of the price of a coffee. It’s not that people don’t want to pay. It’s more like, people are not interested in paying for something that they are afraid, might not work as advertised. To consumers, buying a software is more like taking a risk than buying a coffee. With Windows, the risk was viruses. With online, cloud only, web applications, it was privacy. With App Store, Apple has shown them, what trustworthy computing is mitigating a huge risk considerably. With App Store, the risk a customer takes is paying for a software that doesn’t work as advertised (or doesn’t meet the quality expectations).

While Apple was not doing well in late 90s, the industry thrived well on release early, release often mantra. It often worked since, funding the software product was easy when it was iteratively developed. But, it’s 2011 now. If you are making a iOS app, remember that your target audience are iPhone/iPad users. They don’t tolerate sh*t. The App Store is filled with high quality apps and if your app doesn’t meet that quality expectations, don’t expect a run away success. Make a polished product from day 1. If you are running low on budget/funding, don’t write software in the first place. If you were a movie producer, you can’t make a movie with half the money, release it and build upon that. Neither movies, nor cars or any other commodities are made like that. Don’t make a 0.8b release and expect users to tolerate it. Don’t promise *big* features on upcoming release. Some companies that I admire are Tapbots, Panic Software (they make the awesome FTP client, Transmit), AgileBits (the guys behind 1password). All of their products are “insanely great” right from day 1. Just because, something can be changed easily, doesn’t mean you should be changed frequently (iterated) even after release. Movies too had iterations, and cars had prototypes, but they existed only within the studio or the factory and never made it to the customers. You and me, the common man, doesn’t even know of their existence. Why can’t we build software like that? Why should you ship a product that’s not complete?

Let’s kill the notion that software can be made great only by rapid iteration. Make your next product an example of that.

–
Mugunth

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

No related posts.

On the Inter-webs, it’s very easy to find a piece of code that abuses singletons or a blog post that bitches why singletons are bad. Trust me, singletons are not bad. A singleton is a double edged sword. It’s up to you to use it the way it was intended to be used. In this post, I’ll talk about some often encountered problems where singletons are used in a wrong way and then provide you suggestions on how to overcome them.

While the examples I give here are iOS specific, Singleton is a design pattern. That means, you could apply this knowledge in pretty much any programming language.

Common (ab)use cases for a Singleton

You might find situations when you need to store the global state of the application somewhere. To store this state let’s create a singleton class called XYZManager.

The other common use case is you need a class that will probably be used inasmuch as every view of your application. So, let’s use a singleton.

Fortunately or unfortunately, using a singleton seems to solve both these problems, but will end you up in hot soup sometimes later during the project’s lifetime. Let’s see why.

Problem 1: Sharing global state

If you find yourself in a situation where your app has lots of global state and every class reads/writes to this state, you have made a terrible mistake in designing your app.

A rule of thumb for a good object-oriented design is to limit global state variables. Using a singleton solely to store your state variables is as bad as using global variables in your app. A singleton is not designed for that.

Of course, state variables cannot be completely removed in a software. Before you create such a variable, you should be doubly sure that the variable is truly global in your business domain.

Example

Let me give you an example. When you develop an app that talks to a web service, the only “state” variable I could think of is your access token. Using a Singleton to encapsulate calls to web service that remembers the access token is fine. But if you store the response strings from one method and use it in another method and then release it in yet another method, you are doing it wrong.

Let me quote a common example of this from iOS. You have a master-detail view. The details view can be reached only from the master view. The details view has an “Up/Down” segmented button that shows the previous/next content without having the user go back and forth. So let’s fetch the detailed content on a background thread and store it in a NSMutableArray in our singleton and whenever next button is tapped, increment the current index and update the UI. Neat and elegant, right? WRONG. It’s not the singleton’s responsibility to store data required by a few of the view controllers in your app. The problem with this method is, you cannot make an educated guess on when to release this NSMutableArray. A “clever” technique is to release it when the master view is unloaded. But then these “techniques” tightly couple the singleton with view controllers and affects reusability. Later on, if your business requirements change and you have to use the detailed view elsewhere, you will not be able to.

Another case is when you write a method in a singleton assuming that, so-and-so variable will have so-and-so values, when the control reaches there. If you have done this, you have tightly coupled your singleton with various other classes. This is something that’s very very hard to unit test.

Finally, because singletons don’t die and live till the end of the program, storing chunks of data like this results in a potential memory leak.

Problem 2: Managing state externally

A singleton’s state should be managed by one and only one class, self. If a view controller or another class changes the internal state variables of a singleton, you are doing it wrong. The getters of the singleton’s state variables can be public, but the setters should always be private. A good example from Cocoa is UIDevice class. It manages a wealth of state about the device, but nearly every state is marked readonly. When a state is changed, it often something that controls the behavior of the singleton.

If a singleton doesn’t manage any state, then you don’t actually need a singleton. What you need is a Façade object.

Problem 3: Dependent singletons

In your app, it’s “kinda” ok to have “too many” singletons, but ensure that they don’t talk to each other directly or indirectly. For example, you can have a FacebookManager, a TwitterManager and several other similar manager classes., but they shouldn’t communicate with each other. In other words, a singleton shouldn’t call methods in another singleton. For example, a method named, publishFeed in FacebookManager shouldn’t call publishTweet of TwitterManager. If you are doing this and cannot find a way out of this, merge them into one singleton. After all, they probably might be the “same” in your business domain. When you refactor considering this, you will find that your project with “too many” singletons actually has only one or two “real” singletons.

Another reason why you shouldn’t depend on a singleton method from another singleton is that, singletons are lazily loaded. You have no authoritative way to ascertain the order in which they are initialized (or the order in which they are torn down).

Problem 4: Delegates in a singleton

Asingleton is a global class. No one single class should “own” the delegate of a singleton. To notify state changes, observe them through KVO or NSNotificationCenter. PS: The very first version of MKStoreKit had this problem.

Mediator Pattern

If you still need two singletons to talk to each other, yet being independent, write a mediator class that handles this communication. Like in our previous case, if we have a FacebookManager and a TwitterManager and you want to publish an entry with one method call, write a mediator that “knows” how to publish to Facebook and how to publish to Twitter.

Ok, nuff said, When should I use singletons then?

Now that we know when not to use a singleton, let’s talk about some cases where you should be using them.

Singletons are good

Singletons are actually good, if you use them the right way. Every framework you have ever used, has a handful of singleton classes. iOS too have a few. UIDevice, UIApplication are some example. When you program for iOS, just look at how Apple uses them. A quick rule of thumb for your reference.

1. Never change the state of a singleton from a class/method outside it.
2. Never allow two or more singletons to talk to each other.
3. Never write a method in a singleton that assumes/expects the state of a variable to be set to a particular value by another method. That’s methodB shouldn’t mandate that methodA should be called before it’s called.

Only a class that’s truly a singleton in your business domain will satisfy all these points. If any one of the above point sounds illogical to you, what you need is something else and not a singleton.

Thus, Singletons ain’t bad after all. If you are convinced, pick up my Xcode 4 singleton template.

–
Mugunth

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

No related posts.

MKStoreKit, as you probably know is a framework for implementing In App Purchases in your app. It supports virtually every feature you could tell and every business model you could (or even Lodsys) ever think of. It supports, Auto-renewable subscriptions, Consumables, non-renewable subscriptions, and good old non-consumables and a whole lot others.

The biggest gripe among the developer community is that there is no easy to use, step by step guide on how to use it. There are reasons why I couldn’t publish one.

Why no demo?

First and foremost, a working demonstration app implementing MKStoreKit requires an app to be setup on AppStore and this app cannot obviously be published. Conversely, I cannot open source an app that makes money for me through In App Purchases.

If you have an App on iTunes Connect without publishing it, Apple will send you a polite email after 2 or 3 months asking you to publish. Failing which, they remove it for you and will no longer allow you to create an App by the same name. Deleting the app obviously removes associated In App Purchases and the demonstration code will no longer work. It simply doesn’t make sense to play cat and mouse with Apple and create dummy apps for a demonstration software.

Design of MKStoreKit

However, MKStoreKit has been designed keeping this in mind. The whole integration shouldn’t take more than an hour or so. Implementing the MKStoreKit into your app is as simple as 10 or 15 lines of code.

Step 1: Initialization The first step is the initialize it in the AppDelegate using the code,

[MKStoreManager sharedManager];

Step 2: The Plist magic The second step is to set up your configurations in the plist file, which I think is quite obvious. There are three keys in the plist, one containing an array of non-consumables, one containing an array of consumables and another an array of auto-renewable subscriptions.

Step 3: Configuring for Non consumables Non-consumables need no extra configuration. Just enter the list of product ids in the plist file.

Step 4: Configuring for consumables For Consumables, you need to tell MKStoreKit, which product it belongs to and the quantity it adds.
For example, com.mycompany.myapp.eggbasket1 = 10 eggs, and com.mycompany.myapp.eggbasket2 = 100 eggs, you need to tell MKStoreKit that both these are the same product “Egg” and they add 10 and 100 eggs respectively.

This is precisely what the keys Count and Name stands for.

Step 5: (Auto-renewable subscriptions) For auto-renewable subscriptions, you need to tell the subscription length. MKStoreKit automatically keeps track of subscription expiry and notifies you through NSNotificationCenter if they expire. Since, Apple doesn’t keep track of subscription length, it’s your responsibility (which MKStoreKit takes care of) as a developer to remember those subscription length somewhere in your app.

Step 6: (Shared Secret) If you use auto-renewable subscriptions, you need to enter set your shared secret. You should do this in MKStoreKitConfigs.h. If you don’t do this step, MKStoreKit cannot notify you of subscription expiry. Shared Secret is used for subscription verification and it’s compulsory to set this if you use auto-renewable subscriptions.

Step 7: The real purchase
The real purchase code is a one liner.

 [[MKStoreManager sharedManager] buyFeature:<strong>@"com.mycompany.myapp.feature1"</strong> 
                                    onComplete:^(NSString* purchasedFeature)
     {
         NSLog(@"Purchased: %@", purchasedFeature);
		// provide your product to the user here.
		// if it's a subscription, allow user to use now.
		// remembering this purchase is taken care of by MKStoreKit.
     }
                                   onCancelled:^
     {
         // User cancels the transaction, you can log this using any analytics software like Flurry.
     }];

Everything happens behind the scenes, automatically. For every kind of product, whether it’s a consumable or non-consumable, this code is same.

Step 8: Expiry notifications for auto-renewable subscriptions Subscribing to subscriptions revoked notifications (only for auto-renewable subscriptions).

	[[NSNotificationCenter defaultCenter] addObserver:self 
selector:@selector (subscriptionExpired:) 
name: kSubscriptionsInvalidNotification 
object:nil];

It’s the configuration part that’s hard. So, as I promised that was under 10 lines right? One line in your AppDelegate, 4 or 5 lines in your Store ViewController and 2 lines to listen for subscription expiry notification. That wasn’t hard, was it?

Going forward

Lion

MKStoreKit will soon be released with full support for Lion
Currently, I think it should automatically work, though I haven’t tested it. If you are using it, do let me know.

iCloud

Adding iCloud integration. With iCloud, your purchases will be remembered on iCloud rather than Keychain, which means, you don’t need to restore transactions on every device. iCloud will do it for you automatically.

The code for this is ready, but the NDA prevents me to push it to Github. Wait till Sep 5th (hopefully)

If you have any other feature requests, or want me to look at your changes, do send me a pull request for the code on Github
http://github.com/mugunthkumar/MKStoreKit

Hope MKStoreKit helps you and your business. Do consider a paypal donation to mugunth.kumar@gmail.com.

Thanks,
–
Mugunth

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

Related posts:

1. MKStoreKit 4.0 – Supporting Auto Renewable Subscriptions MKStoreKit started off in a pet project a couple of...
2. In App Purchases: Troubleshooting Code=0 “Cannot connect to iTunes Store” (SKErrorUnknown) When using MKStoreKit or any other equivalent framework or regular...

MKStoreKit started off in a pet project a couple of years ago and I wrote the first version in 2009.
Since then, it has seen tremendous adoption rates that, it has been the “go-to” framework for implementing In-App purchases in any iOS app today.

On iOS 4.3, Apple added a new type of subscription framework called, auto-renewable subscriptions.

Today, I’m adding this support to MKStoreKit along with several new features. If you have been following me on Twitter (@mugunthkumar) or on Github, you would have gotten the code a week ago.
Now that, I’m done with my testing it’s finally ready for some real-world adoption in your projects.

What’s New

1. The main feature includes support for Auto-renewable subscriptions.
2. The second important change is to move configuration related changes to a separate file,

   MKStoreKitConfigs.h and
   MKStoreKitConfigs.plist

   The plist contains a list of products you support and MKStoreKit automatically reads this and creates StoreKit requests on your behalf. This feature was partly inspired by a issue raised here by a contributor, dfabulich. But I didn’t like adding a datasource to MKStoreKit for various reasons. I think this method is cleaner than that. MKStoreKit now behaves like a standalone drop-in package.

3. MKStoreKitDelegate removed in favour of Blocks
4. Keychain support using SFHFKeychainUtils
   

   How to use

   The most important change to MKStoreKit is the use of a plist file instead of Macro strings for your product ids.
   The following screenshot shows the plist file organization.
   
   There are three main sections, Consumables, Non-consumables and Subscriptions. You specify your product inside each category based on how you added them on iTunes connect.
   After that, MKStoreKit does the rest.
   Non-consumable and Subscriptions are straight forward. I think I might need to explain a bit about Consumable support.

   Every consumable entry in this plist needs to be a dictionary with “Count” and “Name” defined. Imagine that your app is a fish tank app with eggs, plants and fishes as consumables. Fishes are going to be sold on a per-fish basis. However, you might be interested in selling eggs as discounted basket. To allow this business model, I’ve added a new entry called unique name to every consumable.

   If your products, for example,

   com.myfishapp.eggbasket50 = $2
   com.myfishapp.eggbasket500 = $15
   com.myfishapp.eggbasket5000 = $ 125

   are in fact same in your business (in this case they are all eggs, just that the count is different and subsidized for bulk purchases), you can define them on plist as individual consumable mapping to the same name.
   MKStoreKit will then treat all these products as same when remembering purchases.

   So instead of you remember how many fish eggs this person has purchased, you can leave that task to MKStoreKit. You get a nice wrapper around them and call these methods on MKStoreKit

   - (BOOL) canConsumeProduct:(NSString*) productName quantity:(int) quantity;

   to check for product availability and

   - (BOOL) consumeProduct:(NSString*) productName quantity:(int) quantity;

   to notify MKStoreKit to deduct the consumable’s balance.

   This support was originally added to MKStoreKit 3.5, but it didn’t support product bundles. MKStoreKit v4 adds support for this.

   Subscriptions expiry notification

   MKStoreKit automatically posts notifications when your auto-renewable subscriptions are renewed or failed validation (expired). Observe the following notifications,

   kSubscriptionsPurchasedNotification
   kSubscriptionsInvalidNotification

   on your view controller or AppDelegate and take corresponding actions.

   A note for MKStoreKit 3 users

   MKStoreKit 4 uses keychain to remember purchases. This is partly to support In-App purchases on the upcoming operating system, OS X Lion. On iOS, all apps are sand-boxed and outside access to NSUserDefaults is not possible (unless the device is jail-broken). So remembering purchases on NSUserDefaults was *good enough*. On Lion, however, NSUserDefaults file is just another plist that could be edited on any text editor and technically “buy” our in-app feature. To circumvent this piracy, MKStoreKit 4 will use keychain instead of NSUserDefaults.
   As such if you have any consumables, they will not be automatically migrated to keychain store by MKStoreKit. You should do that part yourself. Non-consumables and Subscriptions doesn’t have this issue.

   Source Code

   The complete source is available on Github

   Demo Project

   There isn’t a demo project available because of the nature in which In-App purchases work.
   The only way would be to create a dummy project from my iTunes store account and create IAP. But that would add maintenance nightmare for me. However, since MKStoreKit is self-contained, you shouldn’t normally have trouble integrating it into the product.

   Licensing

   It’s licensed under Zlib as I feel that’s the most open license ever.

   A word on third-party components

   MKStoreKit uses the following third-party components.

   1. JSONKit by John Engelhart (BSD or Apache Licensed)
   2. NSData base64 encoding additions by Matt Gallagher (Zlib license)
   3. SFHFKeychianUtils by Buzz Andersen

   Final words

   I’m still making some touchups and final set of changes. But I think they will mostly be *cosmetic* (code refactoring). Feel free to pull/fork MKStoreKit and leave your feedback.

   Support me

   Hourly rates of a iPhone developer is skyrocket high. I believe this code would have saved your coding hours by at least a day. You can consider supporting further development by funding me through PayPal.  My PayPal email is mugunth.kumar@gmail.com
   –
   Mugunth

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

Related posts:

1. Using MKStoreKit in your apps MKStoreKit, as you probably know is a framework for implementing...
2. In App Purchases: Troubleshooting Code=0 “Cannot connect to iTunes Store” (SKErrorUnknown) When using MKStoreKit or any other equivalent framework or regular...
3. Migrating your code to Objective-C ARC Recently, Apple introduced several new developer stuff including Xcode 4,...

Information architecture on mobile

Aesthetics vs Interaction Design

Custom themes/colors vs custom UI elements

Problems with a custom interaction pattern over HIG

“Hint UI” text wastes precious space.

Hint Text on a App Screenshot

Beluga, showing a "friendly text"

Avoid them as far as possible on the iPhone app. You have only 416 pixels to play with (20 goes off for status bar and another 44 for the navigation bar). The screen size is too limited to carry all those noise elements. Again, this is a often used paradigm on the web by web designers trying to “help out” users. On any iPhone app there is just one call to action, usually on the top right corner or if it were a page with a toolbar, it would be four or five. You don’t need a hint overlays on iPhone. If you think, you need, your UI requires a complete overhaul.

A mini tutorial pops up at random meddling with your workflow

Bloomberg's friendly text appears only when you interact with it

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

No related posts.

If you are a iOS developer and make your daily bread by writing iOS apps, these are three software applications that can dramatically improve your productivity and quality of your coding.

1) Code Pilot

My first favorite software is a XCode plugin called Code Pilot. It is a nifty plugin that, I would say, is QuickSilver for XCode. Jump into a file, or a method within a file within a couple of keystrokes. It matches your keystroke with files in your project using a special regex that you can type ABCTVC for going to ABCTableViewController.h or you can type cellFIP for cellForRowAtIndexPath. Its really smart and really helpful and it doesn’t need any customization. Just install the plugin and you are good to go.

Get it here

http://codepilot.cc/

A drawback of this tool is that, it’s currently available only for XCode 3 and no information on XCode 4 support is known as of now.

2) Accessorizer

Writing Model classes for your project can never be this easy. Just write your class variables. Accessorizer automatically generates @property, @synthesize for you.

Accessorizer can also generate a variety of code blocks that includes Key-Value Coding, Keved Archiving, dealloc blocks, Case statements for enums, Singleton classes and a lot more. It also recognizes IBOutlets and generates viewDidUnload code for them. Accessorizer is a swiss army knife for a iOS developer.

Get it here

http://www.kevincallahan.org/software/accessorizer.html

It’s also available on Mac App Store.

A drawback of this tool is that, it’s quite complicated to customize it initially and get things started. Early users, especially users who are new to iOS platform might be baffled with the number of available options and customizations in the software. Fear not, it isn’t that complicated as it seems. Once you set it up properly, it’s a breeze to generate code.

3) SnippetsApp

While there are many apps, both cheap and expensive ones, this particular app by Lucky Ants is the best in my view. You can create code snippets right from XCode, or insert code snippets from library into your project all within a couple of keystrokes. The work flow is just right for a user relying heavily on keyboard shortcuts.

http://www.snippetsapp.com/

A drawback of this tool is that it doesn’t offer any kind of syncing of your code snippets across your devices as of now, although developers have promised a sync feature soon.

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

No related posts.

Few days ago, I wrote a post on my review on Windows Phone. While I have been a Microsoft basher (no not really), Windows Phone is one product that surprised me (and I think most other bloggers as well) and took the smart phone UI to the next level. While Microsoft has been known to make killer user interfaces like Microsoft Fluent UI aka Ribbon, and the famous Start Menu on Windows 95, they haven’t been doing much recently. While they don’t innovate fast enough like Apple, Windows Phone is a whole new innovative product that looks new, refreshing and even “threatening” to competition that, even Apple was forced to make some of its features like Find My Phone of MobileMe free.

Windows Phone is the next major platform

Windows Phone is all set to be the next major platform in the Mobile Space. While it will be second to Apple at least for several years to come, It’ll still garner market share from new smartphone users and competitors like Blackberry and Android. It should be noted that, even while Android is free and can be customized by device manufactures, most companies except Sony Ericsson have vouched for or shown some kind of support for this new Microsoft Operating System. Samsung will be shipping more Windows Phone devices than Android (and even it’s own Bada) in 2011, while Motorola is interested in making Windows Phone devices despite lawsuit. Given all these, as successful developers, I strongly think it’s high time to start porting apps to Windows Phone. Even the mighty Rovio Mobile is making a Windows Phone 7 port of Angry Birds after dissing Microsoft. More info here. To developers like us, it’s another platform that comes with a whole new gold rush. Why not utilize it?

Recently, I ported one of my app, iCash SG and it’s now in the 2nd free app in the Navigation Category and is within the top 40 free apps in Singapore MarketPlace.

I’ll be speaking from those experiences focussing on equivalent techniques between the two operating systems.

Analogies between the two Operating Systems

The two operating systems have many things in similar. For example, both support push notifications, both do not support true multi-tasking unlike Android and both of them are highly restricted compared to classical desktop operating systems. As a developer myself, I’ve tried to de-mystify the different buzzwords used in the Windows Phone forums/blogs and get yourself accustomed with their iOS equivalents.

UITabbar <==> Panorama/Pivot

An app that might be using a tab bar controller on iOS will probably be using a Panorama Control. iOS provides a UITabBarController to support displaying views that are NOT co-related and a drill-down navigation stack through the UINavigationController for displaying increasingly detailed information. On Windows Phone, you would normally use a panorama control for a UI that would use a UITabBarController.

A panorama is a control with a long horizontal canvas extending beyond the screen bounds. Navigation is supported by a flick gesture. Panorama is recommended for showing views that are NOT co-related to each other. For displaying contents that are the same but filtered based on a specific criteria, you must use a Pivot Control.

A good example is the built in Music and Videos hub. When you launch this app, you see a panoramic view that shows the different “parts” of the application like radio, history, music, video etc., When you tap on the “music” item, your music will be organized based on Artists, Album, Playlists etc, using a Pivot Control. In your application as well, when you are displaying co-related content, use a Pivot Control, otherwise, use a Panorama.

NavigationController <==> NavigationService

Lots of differences here. UINavigationController is something that you add into you app. But on Windows Phone, the operating system provides a service called NavigationService. You use this service to navigate between views in your app. In a sophisticated app, you can also use Silverlight’s powerful Navigation framework class called UriMapper. While you “push” views into a navigation stack on iOS, you “navigate” to a page which is addressed using a Uri, just like how you navigate to a page on a website. While on the surface NavigationService looks very easy to use compared to UINavigationController, it’s not. On Windows Phone 7, you can also navigate out of your app and navigate back in when the user press the back key on the phone. So the design of every page should behave in a “stateless” way. While it’s quite a challenge to design pages like that, If you are depending on information from a previous page, you should cache this when the user navigates out of your page. If this is not done properly, your app might crash when the said page is brought back from, say tombstoned state. Should I say that, such a crash would get your app rejected?

UITableView <==> ListBox

Arguably, The most commonly used control on the iOS is a UITableView. The analogous control to this is a ListBox. However, implementation wise, there are quite a lot of difference behind the scenes. You populate a UITableView using delegate methods, while you populate a ListBox by calling adding contents directly into it’s member Items. A simple code snippet would be

mainListBox.Items.Add(myObject)

Note that, this object can be any model object of your class. On the iOS, you “customize” the look and feel of the UITableView by customizing each cell with a custom UITableViewCell. On Windows Phone, you do it by a powerful concept called Data binding. Data binding is ahuge concept in itself, that separate books are written for that. However, in this post, I’ll touch upon a few basic concepts on how to display the different entities in the model using this technique.

Building your Interface

You can build your interface on Windows Phone using Visual Studio or programmatically in C#. The interface  code is a internally XML based (called XAML) which is again similar to XCode’s Interface builder’s XIB files. For better MVC isolation, interface should generally be created using Visual Studio just like how you create Views using Interface Builder. Alternatively, you can also use  Microsoft Expression Blend, which is more matured product than XCode’s designer, the Interface Builder. Actually, whatever Interface builder can do can be done using Visual Studio, but Microsoft Expression Blend augments what Visual Studio can do to your interface while maintaining compatibility in the generated XAML. In most cases, ExpressionBlend is used to build animation driven user interfaces without writing a single line of code, which is usually done programmatically on iOS using CoreAnimation/QuartzCore framework. So if you were wondering how to do that cool animation you do iOS, look no further, Expression Blend is your friend.

UITableViewCell <==> Data Templates

On iOS, the UITableView is usually customized by creating custom UITableViewCell classes. Customized table view cells is arguably the most used step when you write a iOS app. I could even go further and say, if you know to customize a UITableViewCell on the iOS, you already know more than 50% of iOS programming.

On Windows Phone, you do the equivalent by “applying” a data template to the listbox to which you added the items. This template is again written in XAML and can either be hand-coded or can be generated using tools like Microsoft Expression Blend The cool idea of using this tool is that Expression Blend tool is a tool designed and made for designers and programmers usually don’t have to worry about the look and feel of the app.

For better reusability, you can write the data templates as a UserControl and use them instead of directly applying an adhoc template to the listbox.

Isolated Storage <==> NSHomeDirectory()

On Windows Phone, your app specific files are stored in a sandboxed environment much like the iOS. Microsoft’s equivalent of this sandbox is called as IsolatedStorage. Files can be read or written only within the confinements of IsolatedStorage.

One thing to remember here is that, IsolatedStorage by default doesn’t provide you a cache directory like iOS’ NSCachesDirectory. So if your application is going to create large number of cache files, it’s up to the programmer to create a separate cache folder and empty it at periodic intervals.

NSUserDefaults <==> IsolatedStorage.ApplicationSettings

The IsloatedStorage also maintains a LocalSettings file which can be accessed through IsolatedStorage.ApplicationSettings. This is the place where you write your setting related information. Using this is much similar to how you use NSUserDefaults on iOS.

Push Notifications

Windows Phone supports four types of notifications.

Toast notifications are notification with alert which are similar to iOS’ notifications with a prompt. However, unlike iOS, users are free to “ignore” your toast notification since it’s not shown as a modal alert.

Tile notifications are notification with a text and badge count to update the tile. This is similar to the badge update on iOS. However, tile notifications are ignored completely by the operating system when the app is not pinned to the home view. So while on the iOS, updating just the badge is a pretty good silent indicator, on Windows Phone it might not.

Raw notifications are  something new to the platform. This notification is used to update your apps’ internal state from your server. Remember that, when your app is not running, this is completely ignored. May be in a later version or so, Windows Phone will allow us to “wake” our app from a tomb-stoned state using a raw notification.

A huge and very important diff from iOS is that Microsoft’s push notification implementation will actually let you know if the notification has been delivered successfully whereas iOS is more like a fire and forget kind.

Local Notifications <==> TileSchedule

On iOS , local notifications can do pretty much everything like a push notification. However, on Windows Phone, you can only update the tile image using a “TileSchedule“. As on date of writing, even the tile text or the badge count cannot be updated by a TileSchedule. So if you are writing a weather app, be sure to have tile images for every possible weather conditions. Hopefully, Microsoft might come up with more sophisticated features that can be done using this TileSchedule in a subsequent release of the OS.

How can Microsoft make Windows Phone better for developers

Realtime information from Camera/Camera overlay view.  This is a very serious omission and as such, Augmented Reality apps cannot be done and apps that do real time video analytics like barcode readers, business card scanners also are impossible.

Not much support for Local notifications. Using a schedule you can only update the tile image but not the tile count or it’s title.

No proper URL routing support. For example your app cannot handle all “abc://” urls like how you do on iOS.

The developer API is not as matured as iOS. With iOS, you can virtually do whatever Apple has done in its apps, which is not the case with Windows Phone. For example, I couldn’t even figure out how to display the alphabet index like the one you see on the People’s hub. Microsoft has been a company that doesn’t release every API or UI element it uses. For example, on Windows 95, you cannot, at least easily with the tools provided back then (VB 4), build a software that looks native like, say, Windows Explorer or the Internet Explorer. The same applies to Windows Phone 7 today. The default tools available from Microsoft doesn’t allow you to create page animations at least easily. I used this silverlight-toolkit for page animations and even then it doesn’t look as native as how Microsoft do it themselves. Being a indie developer on Microsoft platforms is not as easy as it is on Apple. As on date, to create a slick looking UI like, say the built-in mail app, you might need third-party controls like the telerik, which would set you back by 2000$. Things remain the same as how it was on Windows a decade ago.  Hopefully, Microsoft understands this and opens up their APIs and UI elements. I don’t think it makes any sense to depend on third party controls for building a product that looks like the native ones. Apple on the other hand helps indie developers by their WWDC sessions, and giving away lots of source code for free.

As such, just like how every application on Windows look different, every app on Windows Phone will look different unlike iOS.

What Windows Phone has that iOS doesn’t

Hubs Integration is a very important and new concept on Windows Phone and some of the apps you write can integrate itself within the built in hubs. For example if you are writing a radio application, it makes more sense to integrate itself into Music and Videos hub than as a standalone app. Similarly, you can integrate your app within the photos hub as photo editors or if you are a content provider for music, you can provide Album art or lyrics right into the Music hub for the currently playing music.

Similarly, I strongly believe that Microsoft will open up People hub integration and so if you make a twitter client, you can sync your twitter information with the People hub. These are some extra things that you must note while developing for Windows Phone as they have no equivalent.

While there are much more to write, and compare, I think, I’ll write about them in another blog post and hope the post helps in kickstarting with your Windows Phone development.

Do tweet this or share this post if you find it useful.

–

Mugunth

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

Related posts:

1. Designing usable mobile apps Another usability related blog from me after a long time...

Update 4: (8th July 2011) MKStoreKit 4.0, an updated version of the one presented here is available. Please check it out and use 4.0 instead of this.

Around last year this time, I wrote a singleton class, MKStoreKit, and a blog post, wrapping Apple’s StoreKit framework and it has been quite popular. From the email responses I receive, I could say, it’s been in use in more than thousands of apps on the AppStore. It has been very successful toolkit that, it was referred as the “goto” toolkit for in-app purchases.

A WordPress Statistics showing that MKStoreKit is a more popular keyword for Search

Developers even search for MKStoreKit (might be they heard it through word-of-mouth). Now, I think, it’s time to re-write it from the scratch. Since MKStoreKit is quite successful, I think it’s time to introduce some “standards” into the framework.

What’s new in 3.0

MKStoreKit 3.0 adds support for product availability notifications, cancelled transaction notification, restore transactions, server product model support, super easy consumable support and built in ability to display product titles along with their localized price. We will look at them one by one in this post.

Products available notification

MKStoreKit 3.0 can notify the delegate handler when Apple’s storekit framework returns

- (void)productFetchComplete;
// variable that tracks the state of StoreManager's product availability
BOOL isProductsAvailable;

Handle this delegate and refresh your views that shows your list of in-app products. There is also a variable called isProductsAvailable. If this is false, you can show a spinner till you get the productFetchComplete delegate returns. If it’s “YES”, you can call necessary functions.to display your products. MKStoreKit 3.0 has another function to format the product name with their localized name, description and currency.

- (NSMutableArray*) purchasableObjectsDescription;

When you call [[MKStoreManager sharedManager] purchaseableObjectsDescription] you wil get a array of strings which you can straight away use it for displaying on your table view. With little tweaks to that method, you can customize it to display however you want. Note that this returned array will be empty when isProductsAvailable is “NO”

Restore transactions with ease

First and foremost request was for adding the ability to restore purchases.

- (void) restorePreviousTransactions;

Just call [[MKStoreManager sharedManager] restorePreviousTransactions] from your IBAction for the restore button.

Super easy consumable support

The new version of MKStoreKit has a very easy and slick support for Consumables. It automatically keeps track of the quantity of the consumable quantity and you can use helper methods within MKStoreKit to check if the user has enough quantity of the consumable for use.

- (BOOL) canConsumeProduct:(NSString*) productIdentifier quantity:(int) quantity;
- (BOOL) consumeProduct:(NSString*) productIdentifier quantity:(int) quantity;

Now you don’t get all these features for free. You need to customize MKStoreKit by telling which of your product is a consumable and which one is a non-consumable. And for each consumable product id, you must configure it to tell MKStoreKit the actual virtual count associated with it.

For example, you might have a “Fish Tank” where users can buy “eggs”. You have a “small” basket, “medium” basket. You need to tell MKStoreKit, how many “eggs” each consumable contain so that you can use the built in helper methods to consume them and to check if the user has “enough” items to consume. While it all looks complicated outside, I have introduced some naming convention standards that makes life easy here.

Naming a product identifier with a trailing number tells MKStoreKit to treat it as a consumable.

So in this fish tank case, you can have
com.mycompany.myfishtankapp.fish1 as a non-consumable and
com.mycompany.myfishtankapp.eggs.small.5 as a consumable that gives “5″ eggs to the user to consume.

If you follow this simple naming convention when you create your consumables, it will be super easy to use with MKStoreKit 3.0

Support for cancelled transaction delegate

The next big request was to add support for cancelled transactions. The time it takes for Apple’s storekit framework to show the In-App purchase prompt. While developers show a simple spinner, it wasn’t possible to stop or hide the spinner when the user cancels the transaction. MKStoreKit 3.0 adds a new delegate method that notifies you of a cancelled transaction.

- (void)transactionCanceled;
// as a matter of UX, don't show a "User Canceled transaction" alert view here
// use this only to "enable/disable your UI or hide your activity indicator view etc.,

Support for server product model

The new and improved MKStoreKit 3.0 also supports Server Product Model and improved support for consumables. Configuring your server for server product model is super easy with the PHP scripts bundled with MKStoreKit. Just change the SERVER_PRODUCT_MODEL macro to 1 and MKStoreKit will ping your servers for receipt verification. What’s more? The PHP code for verifying receipts is also bundled with MKStoreKit 3.0.

#define SERVER_PRODUCT_MODEL 0

Links to my old posts

1. iPhone Tutorial – In-App Purchases
2. iPhone Tutorial – Enabling reviewers to use your In-App purchases for free

As a matter of fact, the source code links on the old posts will be removed 1 month from the today and MKStoreKit 3.0 will be the only supported version (if everything goes well). In case you need the old code, you can drop me an email, but it will not be supported.

Source code

The source code for MKStoreKit 3.1 is attached here.
MKStoreKit v3.1
Update 3: (8th July 2011) MKStoreKit 4.0, an updated version of the one presented here is available. Please check it out and use 4.0 instead of this.
Update 2 (4th Dec 2010): MKStoreKit will not initialize and use up memory when you run from simulator.
Update 1 (24th Nov 2010): Minor compilation bug kFeatureBId missing fixed. Please download latest files again.

Support me

Hourly rates of a iPhone developer is skyrocket high. I believe this code would have saved your coding hours by at least a day. You can consider supporting further development by funding me through PayPal.  My PayPal email is mugunth.kumar@gmail.com

Follow me on Twitter

©2012 MKBlog. All Rights Reserved.

• Tweet

Related posts:

1. MKStoreKit 4.0 – Supporting Auto Renewable Subscriptions MKStoreKit started off in a pet project a couple of...
2. Using MKStoreKit in your apps MKStoreKit, as you probably know is a framework for implementing...
3. In App Purchases: Troubleshooting Code=0 “Cannot connect to iTunes Store” (SKErrorUnknown) When using MKStoreKit or any other equivalent framework or regular...