IAP and Updating

[AppOwlDev]

I’ve just redesigned the menu scene for my app and a thought just came to me. My menu comprises of some buttons that lead to different math function scenes. Some of these buttons are disabled and are enabled through IAPs.

I have it setup right now so that when the IAP is purchased it triggers a variable (purchased.mathFunc1 = true) tied to a data holding module (purchased.lua), and then when ever the menu scene is loaded it checks the purchased.lua. If one of those purchased.mathFunc are true it enables the menu button for it. Very simple.

So my question is when I update my app, does that purchased.lua get over ridden back to the default of everything being false if nothing was changed in the purchased.lua? What about if I add more .mathFunc to it for new IAPs?

I’m asking because i’m wondering if I need to put a disclaimer telling people to use the restore purchases button after each update.

[ingemar]

I assume you’re saving the purchased table to a file somewhere, and then reading it on every app start, right?

Otherwise your users would already have to restore their purchases every time they restart the app.

Otherwise, no data files are overwritten when you update an app.

[AppOwlDev]

@ingemar

I assume you’re saving the purchased table to a file somewhere, and then reading it on every app start, right?

Otherwise your users would already have to restore their purchases every time they restart the app.

Otherwise, no data files are overwritten when you update an app.

I save the purchased flags for each IAP to a lua file I created called purchased that has the following code: 

local M = {} return M

Each IAP has it’s own flag, such as purchased.IAP1, purchased.IAP2, etc…

I’m just wondering if the purchased.lua gets over ridden on an update.

[ingemar]

If you only rely on a lua table without saving its contents to a file, then you already have a problem.

It’s all fine as long as the app is only closed to the background, but as soon as the user kills the app from the background all the settings in your table are lost forever.

You need to save your ‘purchased’ table to a file (preferably using json). Then when your app does a cold-start you read the file into your table to restore the settings.

The way it is now, your users will have to restore their purchases every time they kill the app.

[ingemar]

I assume you’re saving the purchased table to a file somewhere, and then reading it on every app start, right?

Otherwise your users would already have to restore their purchases every time they restart the app.

Otherwise, no data files are overwritten when you update an app.

[AppOwlDev]

@ingemar

I assume you’re saving the purchased table to a file somewhere, and then reading it on every app start, right?

Otherwise your users would already have to restore their purchases every time they restart the app.

Otherwise, no data files are overwritten when you update an app.

I save the purchased flags for each IAP to a lua file I created called purchased that has the following code: 

local M = {} return M

Each IAP has it’s own flag, such as purchased.IAP1, purchased.IAP2, etc…

I’m just wondering if the purchased.lua gets over ridden on an update.

[ingemar]

If you only rely on a lua table without saving its contents to a file, then you already have a problem.

It’s all fine as long as the app is only closed to the background, but as soon as the user kills the app from the background all the settings in your table are lost forever.

You need to save your ‘purchased’ table to a file (preferably using json). Then when your app does a cold-start you read the file into your table to restore the settings.

The way it is now, your users will have to restore their purchases every time they kill the app.