Matt Coneybeare

MC

App Store Rejection for Not Having In-App Purchase Restoration

| Comments

My most recent App Store submission for NYC Bikes (iTunes link not active yet) was rejected for what I see as a stupid reason: Not having a “Restore” button for In-App Purchases.

We found that while your app offers In-App Purchase(s) that can be restored, it does not include the required “Restore” feature to allow users to restore the previously purchased In-App Purchase(s),
as specified in Restoring Transactions section of the
In-App Purchase Programming Guide:

“…if your application supports product types that must be restorable, you must include an interface that allows users to restore these purchases.
This interface allows a user to add the product to other devices or, if the original device was wiped, to restore the transaction on the original device.”

To restore previously purchased In-App Purchase products, it would be appropriate to provide a “Restore” button and initiate the restore process when the “Restore” button is tapped by the user.

For more information about restoring transactions and verifying store receipt, please refer to the
In-App Purchase Programming Guide.

I think the feature is completely unnecessary. Apple knows which customer has purchased which items in the past, so why put the decision to buy/restore on the customer? When the App makes the first contact to buy an item and the non-renewable In-App Purchase has been detected as previously purchased, Apple should return a different dialog than the normal “Are you sure you want to purchase‚Ķ”, and should tell the customer “You have already purchased this item and can download for free”. Normally, that “already purchased” popup only occurs when the customer has already agreed to purchase it.

None-the-less, Apple requires it so it must be added. Introducing a “Restore” button (which is tapped maybe 1 out of 10,000 uses) into a minimal user interface is not ideal. For my simplified NYC Bikes app, I had no logical or seamless place to put the button, so I decided to implement the required feature in the system-wide Settings app as a simple boolean flag.

Restore Feature

Then, on every applicationDidLaunch and applicationWillEnterForeground call, I check for the presence of the setting, and fire off a restore if necessary.

1
2
3
4
5
6
- (void)checkForRestoredInAppPurchases {
  if ([[UASettingsController sharedInstance] boolForKey:UA_SETTINGS_RESTORE_PURCHASES]) {
    [[UASettingsController sharedInstance] setBool:NO forKey:UA_SETTINGS_RESTORE_PURCHASES];
    // Restore IAP now
  }
}

  • Feature implemented? ✓
  • No UI Damage? ✓

Until Apple fixes the flow surrounding In-App Purchases, the “Restore” feature requirement will likely persist. Use this Settings App method to avoid destroying your minimal UI with a rarely used “Restore” button.

Lastly, I run a small software company called Urban Apps. It pays the bills so I can take the time to write helpful posts like this one. If you found this posting helpful at all, I would really appreciate it if you would check out my Apps on the iTunes App Store.

Comments

My name is Matt Coneybeare, I design and develop for iOS (iPhone, iPad and iPod Touch), Mac OS X and the Web out of New York. In 2008 I started a software company called Urban Apps that has made some pretty popular apps such as Ambiance and Hourly News. My current Stack Overflow reputation is about 27k.

I was a Rockstar a decade ago, but then went back to school and collected a Bachelor's Degree in Computer Science from U.C. Berkeley. Now I am settled down with my beautiful wife Di and our two doggies Hamachi and Foxy. While coding, I walk several miles/day on my Treadmill Desk. When not at my desk, I love exploring New York City as a Yelp Elite, or training for marathons.

Contact information

Name
Matt Coneybeare
Email
Website
Twitter
Instagram
GitHub
Google+
LinkedIn