Moving an app from Paid to Free

I’ve seen quite a few people saying that it isn’t possible to move an iOS app from paid to being free with an in-app purchase to unlock the full functionality. Fortunately they’re wrong.

“Traditionally” I would have had to remove version one from sale and offer a completely new app, which would have meant that existing users would have to pay again to get the same functionality. Or I’d have to support two apps. Or I’d keep the same app in the store and all existing users would get downgraded to the free version. None of these solutions seemed fair to existing users.

What I wanted was for people who had bought version one to get the full, unlocked version and for new users to be promoted for the paid upgrade.

Since iOS 7 came out in 2013 that it entirely possible. I’ll explain how it’s done here. This isn’t just some theoretical “I’ve seen the documentation” claim – I’ve done it with one of my own apps, Rootn Tootn.

The really short answer: take a look at the session 308 video from WWDC 2013. That’s the only information from Apple that explains how to do it. They have documented the API calls that are required but the actual process is left as an exercise for the interested student. And there are quite a few steps if you want to do it properly.

Firstly you need to get the app receipt. Before iOS 7 this only made sense for IAP but now they are available for all purchases and come in the same format as receipts from the Mac App Store.

Receipts have a number of useful features. In the past they have been used to validate purchase, and they can still be used for this. What’s interesting with the new receipts is that they include both the original purchase and the version number of that original purchase. This means that we can decide whether a user gets the paid functionally by looking for either an in app purchase or a purchase date before a particular time or, more likely, before a particular version.

When you download an app you should get a receipt automatically but you can also use the SKReceiptRefreshRequest class to force one to be generated. (This is also useful during development where, obviously, there is no receipt.)

Once the refresh has completed, you use [NSBundle appStoreReceiptURL:] to access the receipt.

Once you have the receipt the bad news starts.

It’s not in a user friendly format. And Apple do not provide any APIs to read it. Check out Apple’s documentation:

The outermost portion (labeled Receipt in the figure) is a PKCS #7 container, as defined by RFC 2315, with its payload encoded using ASN.1 (Abstract Syntax Notation One), as defined by ITU-T X.690. The payload is composed of a set of receipt attributes. Each receipt attribute contains a type, a version, and a value.

If security is important to you, you should probably write your own code to do this. ASN.1 is a standard format and it’s not that hard.

There are apps that generate the validation code, such as

Tighten Pro and Receigen. I can’t vouch for either of them but the reviews seems positive.

There are also Open Source projects that do the same thing. I’ve used RMStore; there’s also VerifyStoreReceiptiOS. The main disadvantage of these is that, as standard, open code it makes it easier for crackers to reverse engineer how you remember that a purchase has been made.

And there you have it. It is possible. It’s just a lot harder than you might imagine. Remember this when someone tells you that it can’t be done.

Double Trouble

One of the great things about WordPress is the community and the number of great plugins that can do amazing things with little effort.

But all that code, as any good developer will tell you, is a liability. How do you pick a plugin that not only meets your requirements now, but will both continue to do so? WordPress advances. APIs change. Plugins need love too.

Many moons ago I settled upon Flickr Gallery, a plugin that allows you to import Flickr images just by adding a short-code to posts. I thought there was value in keeping all my public photos in one place and, at that time, WordPress had poor media management facilities. The plugin seemed popular and well supported.

Flash forward to 2015 and, well, it doesn’t work. It hasn’t been updated for nearly five years and where I should see pictures I only see blanks.

But I’m a developer. How hard can it be to fix?

Groan! Have I ever said how much I hate web development?

Anyway… two hours later I find that there are not one but two problems. I find this after fixing the first problem in a server running on my local machine but find that it still doesn’t work here.

The first problem is that Flickr now requires SSL access to its API. In code terms, open phpFlickr.php and change the following lines:

 var $rest_endpoint = 'http://api.flickr.com/services/rest/';
 var $upload_endpoint = 'http://api.flickr.com/services/upload/';
 var $replace_endpoint = 'http://api.flickr.com/services/replace/';

To:

 var $rest_endpoint = 'https://api.flickr.com/services/rest/';
 var $upload_endpoint = 'https://api.flickr.com/services/upload/';
 var $replace_endpoint = 'https://api.flickr.com/services/replace/';

I found the cause of the second problem when I realised that none of the flickr code was getting called. It turns out that I have the Jetpack plugin and that also uses the “flickr” shortcode, though the syntax for using it is slightly different.

(I find it odd that there’s no error or warning flagging the conflict. This took far longer to track down than it needed to.)

I tried disabling that option in the Jetpack plugin but that didn’t work. In the end, I added the following code to flickr-gallery.php, just before the “add_shortcode(‘flickr’…” line:

if (shortcode_exists('flickr')) {
    remove_shortcode('flickr');
}

Very much cheating… but it does work.

I’m trying to figure out if there’s a way of distributing the change in a more user-friendly format.

“Preview” is damaged and can’t be opened.

“Preview” is damaged and can’t be opened. You should move it to the Trash.

"Preview" is damaged.

This was the rather surprising error message that I’ve been getting when I try to open a PDF from the Finder since I upgraded to OS X Yosemite. It’s bad enough when you get an error message, but one suggesting that you delete a frequently used app is inconvenient to say the least!

Since I found it, I’ve been using a workaround: start Preview.app and open the file manually.

But there’s a better answer. Apparently it just has a duff “quarantine” attribute set. To get rid of it and get things back to normal simply do the following in a Terminal window:

/Users/stephend $ cd /Applications 
/Applications $ xattr -l Preview.app
com.apple.quarantine: 0006;53563f06;Acorn;
/Applications $

If you see the same thing, proceed to the next step:

/Applications $ sudo xattr -d com.apple.quarantine Preview.app
Password:****

And that’s all. Now opening a PDF from the Finder should work. It’s bizarre.

I raised Radar 19384558 with Apple. Please dupe if you see the same thing. Thanks to Gus Mueller (developer of Acorn) for the support.

Update: It seems that a couple of other apps also have the same, incorrect attributes:

/Applications $ xattr -l *.app Utilities/*.app | grep Acorn       
Mail.app: com.apple.quarantine: 0006;53563f06;Acorn;
iPhoto.app: com.apple.quarantine: 0006;53563f06;Acorn;

I have also removed those tags, though I’ve not seen any problems with them so far.

Stillness

When I think of “Stillness,” this weeks PhotoFriday challenge, I tend to think of a lake; an apparently unmoving body of water. (A lot of the other entries, to my eyes at least, don’t represent “Stillness.” Of course, mine may well miss the mark for them…)

Whatever its merits, this one was taken near Spooner Lake, which is very near Lake Tahoe.

I didn’t have an entry in the last challenge, so there’s no need to vote for me(!).

Incidentally, there was another PhotoFriday challenge with the theme “Stillness.” You can see my previous entry here. Tragically, I nearly used the same image again!

2014

It’s important to have a Top 10 list. I know this as every other site has one. I don’t want to miss out. So here are the top ten most read posts here this year, with the year they were originally published in parenthesis:

  1. QA Mindf**k
  2. Do Apple take 40% in the EU? (2011)
  3. Learning Swift
  4. iOS Developer Program: from individual to company (2011)
  5. How do I do “X” in Swift?
  6. AQGridView to UICollectionView (2013)
  7. iPhone Dev: Saving State (2010)
  8. NSFetchedResultsController and iCloud
  9. Why you need a crash reporter (2011)
  10. Sophia Smith (2006)

If there’s a lesson here in increasing readership it’s simple: get retweeted by people with lots of followers.

Honourable mentions go to the following as they were written this year but didn’t make it into the “most read” list:

14. Recruitment Tests
15. Two Years
16. Java and Yosemite
21. Starting Coding
23. Swift Hate
31. Lucky number two

I started with the intention of writing at least one blog a week. You’ll note that I utterly failed. I didn’t even get to the end of January with that!

The biggest surprises — since they were both written over a decade ago — were:

17. Italy, 2001
19. Oracle 8i for Linux Installation HOWTO (last edit was 2003)

I’m not going to make any promises or predictions about next year, other than I’ll be moving the site to a new web host (the old one closing down). But whatever happens, here’s to a great 2015.

Photography, opinions and other random ramblings by Stephen Darlington