What is the best way to coordinate a price change with an app update?

I'm transitioning an app from paid upfront to free to download with In App Purchases. Those who previously purchased the app will have features unlocked that are not available to those who downloaded the app for free. Since the receipt does not include the purchase price, the only way to detect who paid for the app is based on the version number.


Unfortuantely App Store Connect does not have any way to tie a price change to a version update, so I'm trying to figure out the safest way to coordinate this. Here's my tentative plan:


  • Submit the new version for review and set it to "Manually release this version"
  • Once the new version is approved, remove the app from sale
  • Release the new version
  • Change the price and make the app available again


I'm open to any recommendations on how to ensure this works as well as possible. I have no idea how any of this will work—for example can I actually start the process of releasing an update while the app is removed from sale? If so, is it worth waiting a bit afterward, for that change to propagate, before I make the app available at the new price?

You may be overthinking the problem. The app's metadata will explain that the app requires IAP for advanced features. Therefore, you could just wait for the app to be approved and change the price on that day. There may be a very few people who buy the 'free version' app before the price is reduced to free - but they were warned by the metadata that the features require an IAP.

That's a good point, thank you. (And those folks could always ask Apple for a refund, which they would hopefully be granted.)


I also have concerns about the opposite problem though. When an app update is released, I know it can take an unpredictable amount of time to propagate. For example, say I release the update, then change the price, and the price change goes into effect before the update propagates everywhere. If a bunch of people download it for free during that time, how does that affect the "original_application_version" in the receipt? I don't know if that propagation time has any connection to the receipt version or not.


If a few people get lucky and have a bunch of features unlocked for free, that's fine, no big deal. But without knowing how this works I worry that I'll run into the occasional issue where propagation takes several hours, and potentially hundreds of people download the old version for free. I'd love to know beforehand whether that's a valid concern and if there's anything I can do to minimize it!

Downloads will happen very quickly after a new version is launched but only for users who already own the app. New sales - the pnly users who will be affected by a price change - will continue at the same rate as before.


Look at it as a percent of sales that are lost.


The update goes live at t. The price change goes live at t+delta. delta may be 24 hours. The app is on sale for T. T will be about 3 year. You will lose delta/T or 0.1%.

What is the best way to coordinate a price change with an app update?
 
 
Q