One of the great things about distributing your app through Apple’s App Store is the massive global audience that can download your app. Another useful aspect is that you can dynamically change the price of your in-app purchases through iTunes Connect. This allows you to experiment with different price points in order to maximize your revenue. From a business standpoint, this is great. You must be careful, however, to integrate code that properly displays localized in-app purchase prices and accounts for price changes.
The International Dilemma
Let’s consider an example. Assume your app has a $4.99 in-app purchase. Your app probably displays some sort of storefront for selling your various in-app purchases. Although Apple displays a confirmation popup that includes the price, you most likely want to display the price on the button that initiates the transaction. Otherwise, users will be suspicious and unlikely to make the mystery purchase. Accordingly, you add a label that states the extra content costs $4.99.
Let’s further assume that you never change the price of the product. For your US customers, everything will be fine! The product will always cost $4.99, just like the button says. Your international users will have a bit of an issue, though. The price will be displayed in dollars, and there’s a good chance they don’t know the conversion rate to their own currency. At the very least, they don’t want to do the math! Sure, they can find out the price on the confirmation popup, but that’s not ideal.
The Local Problem with Dynamic Pricing
While there’s no problem for US users in the example above, what if you want to change the price to $2.99? Maybe you’ll sell enough incremental in-app purchases to offset the lower price. It’s easy enough to make the change on Apple’s servers via iTunes Connect. If you hard-coded $4.99 on the button, however, your users won’t know about the cheaper pricing until they see the confirmation.
Even worse, you might want to change the price to $6.99. If users tap on the $4.99 button, then see a $6.99 confirmation, they won’t be happy. It may lead to negative reviews.
The Solution
You need to query your available in-app purchases from Apple’s server, then grab the localized prices from the response. Specifically, here is the callback method you receive as part of the SKProductsRequestDelegate, along with the code to get each localized price.
- (void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response {
skProducts = response.products;
for (SKProduct * skProduct in skProducts) {
NSNumberFormatter *numberFormatter = [[NSNumberFormatter alloc] init];
[numberFormatter setFormatterBehavior:NSNumberFormatterBehavior10_4];
[numberFormatter setNumberStyle:NSNumberFormatterCurrencyStyle];
[numberFormatter setLocale:skProduct.priceLocale];
NSString *formattedString = [numberFormatter stringFromNumber:skProduct.price];
}
}
Note that at the end of the loop, you have a property formatted and localized string of the updated in-app purchase price. You could store these prices in an array for later or go ahead and place them on buttons now.
Final Thoughts
Dynamic in-app purchase pricing is pretty straightforward, but it’s easy to overlook. If you don’t set things up correctly from your app’s first release, you’re really in a bind. You may adjust your code in the future to grab pricing from the server, but not all of your users will necessarily update to your new version. That leaves you worrying about whether you can start changing your prices, or if your users that haven’t updated will have a bad experience. Save yourself the trouble. Make sure to use this code from the start!