I want to change my app from a paid version to a free with ads. However, I don't want the people that originally paid for the app to get the ads.
I was thinking I could include a new update that has extra code that sets up some UserDefaults saying the version doesn't have ads and then do the update to the free version. But that doesn't seem like a very reliable solution.
I think, it depends on minimum OS version, that your program can be run on. For iOS 5.0 and later you can try to use iCloud to store some flag about purchased version. It allows you to set this flag not only for one device, but for the user's account.
Or you can store this info in the keychain to get it later. But in this case your user will not be able to have no ADs on some other device with his(her) account.
Anyway, as far as I know, you need to create an update for your app first to write this flag anywhere. And only in some time make an update with ADs.
I will be glad to see comments if someone has another thoughts about this issue.
It seems there is no reliable method to detect whether someone paid for your app or downloaded it later when the price has been changed to free. For this reason I have decided to create two separate entries in the app store.
Related
I have a mechanism reading the Appstore version and forcing the user to update the app. For doing this, I use the following URI: https://itunes.apple.com/lookup?bundleId=xxxxxx
It used to work, but with the last release of my app, I have noticed that it wasn't forcing the update anymore, despite the new version was on the store (the Update button was visible on the store page).
I decided to not update it and let the weekend pass, and today my app was already up-to-date when I opened it. I suppose my phone updated it automatically, unfortunately, so I cannot be sure that my app would have forced the user to do it, but I suppose so.
My guess is that the link I'm using in my app and whatever API iOS is using to automatically update, need time to know the latest version that is already available on the store.
Does anyone have any information about this?
I am experiencing a strange issue.
New app version was released to appstore, containing new variable stored in user defaults and some minor updates. technically, we are creating new variable, which is an array of values in user defaults, and appending some items in the array. For append, we are using values which were already in place in the previous version (e.g. user_id, device_id and one more string parameter, all 3 were received from backend on 1st registration).
It was (obviously) tested before release. Testing strategy:
A. We were building adhoc old version (say #1) and new version (say #2), installing v1 on the devices and updating it to v2 (by simply downloading new adhoc v2 and installing it on top of v1).
Then, we published v2 to appstore, and issued one more test:
B. We were building same adhoc old version (say #1) installing v1 on the devices and updating it from the appstore, by
B.1 in-app update functionality - following the link to appstore and
B.2 just downloading most recent version from appstore.
Both were fine and both are still fine. Works perfectly.
Now, users are reporting old appstore-installed v.1, updated from appstore to v.2, is crashing after update (almost immediately when it is started).
Only difference we can observe is that when tested, appstore version was installed over adhoc, and now it is appstore over appstore.
Was anybody ever facing the same issue? What is the difference in update process "adhoc -> appstore" versus "appstore -> appstore"? Could it be related to the fact that appstore update is cleaning up all the info from user defaults and thus we need to repeat the application reg process (get all the data again like in the first clean install)?
I still have no crash reports in hand, so I am asking for some advices which can help me to solve the issue faster.
Thanks everyone in advance!
...looks like the issue is linked to GoogleUtilities: we have v7.2 in our current build, however previous build was of v7.4, and - as I found out recently, there is an issue related. TWIMC see https://github.com/google/GoogleUtilities/pull/37 for details.
It is still TBC now, we'll be checking in the next 1-2 days, and I will post some updates here. If indeed related to library version, then it has nothing to do with the app distribution (whatever if it is adhoc or appstore based).
Will apple reject an app for doing things like putting up a screen that says: "We've added lots of new features.You need to update before using this app..."? I'm unsure if this is a nosy thing to do but it may be something I need if I ever create lots of new features that need widespread frontend adoption.
This is fine. Clash of Clans for example will not let you play if it detects a newer version on the Appstore. Many online-related apps need to be up to date.
Also, you don't need to force all updates. You could simply force critical updates only.
I have an app in the iTunes Store and sales have slowed so want to convert it to a free app from a paid app. The new app will contain an option to buy, using In App Purchase. I was considering using a flag / pre processor macro to then allow full features for those that buy using the IAP, and limit features for those who have not.
The problem will be if I add this new pre processor macro to the new update, those who have previously paid for the app will not be able to use full features, as they would not have used the IAP to "unlock" the full app.
Does anyone have any suggestions to overcome this problem.
I have a few ideas, but in my mind they are not fool proof.
Thanks for assistance.
Pondering exactly the same issue here. The only thing i found workable (under most use cases) is to look-up gamestate information at when the new_free_iAP version starts.
If there is no iAP state, AND if games exist, AND the playtime counter > 0, i will make the assumption that the user bought this and will preseed his/her iAP configuration information to indicate that this was iPurchased. The only users left out would be buyers who NEVER started the app.
Not fool proof, but better than none. Ugly state to manage, nasty testing for this. And of course, this is a variable geometry solution : if I did not have reliable persisted state in the current version, i would not know where to start.
I have an app published on the AppStore.
I plan to change the minimal requirement of my app to iOS 5.x because there's an issue that only exists in iOS4 and it has been fixed in iOS5.
Is there any easy way to check what iOS version used by my existed users?
I want to know the statistics so I can decide whether to change the min requirement is OK or not
Thanks!
The only way to check this would be if you had already written code to send usage statistics such as [UIDevice currentDevice].systemVersion, [UIDevice currentDevice].localizedModel, [UIDevice currentDevice].systemName, etc to yourself (a webserver/db you control) in your current App.
If it is not currently coded in your live App, then there is no way to determine this information. It may be a good idea however to program this in to your next update for future situations such as this.
You need to add code for this, such as analytics or sending back, you also need to be careful with analytics as Apple discourages sending device information, but OS should be ok. The answer is no, not without recompiling, perhaps crash reports might give you an idea, but there's nothing else you can do.
Perhaps you would care to ask how to fix the issue instead?
you might use some service like TestFlight to track what version people are using.