Swift - IOS - Limited time features - ios

I want to make a limited time promotion of my app, if you download in that day there should be no advertising forever, how do I implement it?
I can put the in app purchase free but i want something more automatic
I already implemented in-app purchase but I don't know if I can automatize it with a code like
if (date==27/07/2016){
purchase()
if (purchase ok)
popup("congratulations")}
Apple allows code like this for in-app purchases?Which class I have to use to check day/month/year?
In alternative to in-app purchases I was thinking about NSUserDefaults but if the user deletes and redownloads the app he loses the feature,and i don't know what will happen with future updates
What can I use in alternative to in-app purchase to remove ads in a permanent way?

Have two IAPs, both for the same thing. One is free, one not. Only have the button get the free one on the promo date.

Related

iOS In App Purchase: Changing from subscription to one time purchase

I am having a programmer code my iOS app, which he has done great. However, due to a new competitor we have decided to change from our current revenue model with In-App Purchases as subscription based to just having users pay a one-time fee. He tells me it'll take a lot of hours to make that change. Is it really true that there is no easy way around changing the code from having renewable purchases to simply have one-time purchases?
Well, this is a very objective question. It's impossible to tell you with any certainty without reviewing the actual code, but here are a few of the obstacles your developer may face:
The methods to buy a subscription is slightly different to buying a non-consumable product, however the app will need to continue to provide content users who are currently paying for a subscription. There is no way to change a subscription to a non-consumable product in iTunes Connect, and you may need to, or should ask and remind the user to cancel their subscription to prevent further renewals (you can't do this yourself or in the app, you can only link to the subscriptions page in their iTunes settings).
The app will need to check for either the subscription product (active or expired) or the non-consumable product has been purchased in order to provide the content. Support for this will need to be on the start of the app, purchase of a product and on the restore in-app purchases function.
There may be further complexities too, particularly if your app uses a backend API that syncs purchase information with a user account.
In conclusion, it's non-trivial, if your developer says it will take a lot of hours, I would be inclined to believe him.

iOS7 - what kind of In-App purchase is this?

The IAP never expires. It is linked to a UUID in a KeyChain. The UUID is used in a database and other places as an identifer, and is critical to functionality.
If they upgrade to a newer iPhone and reuse the Apple ID, then the IAP follows them. The UUID shouldn't be changing in this case. Everything is cool so far.
But I don't want the IAP to be shared across multiple devices sharing the same Apple ID. I want them to pay for the IAP because every new device with the IAP represents a cost to me.
So I'm at a dilemma on how to classify it:
It isn't a consumable because you never need more than one and you don't use it up.
It could be a non-consumable, however, those need to be restored based on Apple ID. Here I get screwed with the Restore Purchases requirement. Basically, any Joe Schmoe can give out his Apple ID to his friends, and everybody gets the IAP for free. I don't want the IAP transferred to multiple devices.
It could be a non-renewing subscription, but it never expires, so they never need to add additional subscriptions. Can I specify the subscription lasts for a very long time (like 20 years) and limit them to purchasing one? The Apple guidelines aren't very specific on this.
It's not an auto-renewable subscription for multiple reasons detailed above.
It is a non-consumable. If you expect the Apple ID will be used across multiple devices, just price your IAP accordingly to account for this.
To be honest, I'm not sure this question is a great fit here because it's not a programming question and nobody but Apple's app review team will be able to give you a definite answer. I do know that subscriptions need to be restorable across multiple devices, so I don't know if that helps you out. The only non-restorable purchase type you can have is a consumable.
I am also not sure that your logic quite works - let's say you store the UUID in the keychain. How are you deriving it so that it's locked to the SIM? You don't have access to the IMEI or anything that uniquely identifies the SIM card on iOS.
You want to restrict the use to one device. That means it must be a "consumable IAP" according to Apple guidelines (note - non-renewing subscriptions won't work - they need to be copied to all devices owned by the user). So make it consumable but make it easy - sell the product as "5000 uses". Each time the user uses the function or the App, charge them one 'use'. This also has the advantage that a heavy user may willingly pay you twice.
And…you can use bluetooth (MKSession) or iCloud to transfer all remaining uses from one device to another device to solve the problem of a user purchasing a new device.

Is it possible to detect when a user has re-purchased a non-consumable IAP for free?

When a user of an iOS app purchases a non-consumable item, then installs that app on a new device, it is possible for them to again go through the standard purchasing logic for that item. The app store will ask them if they wish to spend $0.99 on the item, but if they click "Yes", it will inform that they already own that item, and ask if they wish to download it for free.
I would like to track new purchases in my analytics, and not have them conflated with re-purchased items that a user receives for free. Unfortunately, it seems that this behavior is indistinguishable from a genuinely new purchase, (to the client app). Apple seems to say as much: "Note: If the user attempts to purchase a product that’s already been purchased, rather than using your app’s restoration interface, the App Store creates a regular transaction instead of a restore transaction. The user isn’t charged again for the product. Treat these transactions the exact same way you treated the original transactions."
In discussing this issue, most posts (and Apple's documentation) say that I should offer a 'Restore Transactions' button to the users. I do offer this button, but it is always possible for users to circumvent this logic, and go through the traditional purchasing route. This is where my tracking will become inaccurate.
Do I have any options? Thanks!
I am pretty sure you don't have any options for tracking a new purchase versus downloading a previous purchase for free when a user does an in app purchase. I have looked into this for the same reason of analytics and I could not find a way to do it. IAP is set up to make sure that you honor purchases made by the same iTunes account on other devices.
If your users are required to have an account specific to your app to make a purchase you could use that to know if they already have made the purchase or not. But requiring an account for purchase can lower your conversion rate.

How to 'fake' a restore in-app purchase for previous app users when moving from paid to free

Our app is moving from paid to free, and in the process, moving a key functionality from being included to activating via In-App purchase. Obviously, we don't want current users who paid for the app functionality to be charged again in the In-App purchase for functionality they already had. So on the update by the user, we want to 1) identify current users and 2) make it so they don't see the In-App purchase in the first place, sort of 'faking' the In-App purchase so that the app will appear to them exactly as it did before.
The app does not have a backend, so we have to determine current users from new by examining the saved user data fields for certain values. I do understand that if a previous user has deleted the app from their device that nothing can be done, and I don't mind charging them for the In-App purchase, since they never used the app anyway.
But for those current users who update and assuming we can examine the saved user data and determine that they are current users, what would be a good way to bypass the In-App purchase and make the app look like they already got it, when in fact they never paid for it? Thanks!
Here's what I would do - keep in mind this will take some time:
Set up a server (I prefer EC2) with mySQL on it. Plenty of tutorials about this.
Submit an update to your app that sends the user's UUID to your server.
Wait. This is the hardest part. You'll need to wait until satisfactory majority has updated to your app. That majority percentage is up to you to figure out. It could take months for this to happen.
Make your new, free, app send the UUID to the server.
Check to see if the UUID is in the DB.
If it is, set whatever you would have set when an in-app purchase was made to true.
You have several options:
Free in-app purchase for a limited time:
You would create a free tier in-app purchase content and release an update that somehow makes the user sign up for it. This way, when your user switches devices they can restore the purchase and regain the functionality.
Wait for a period so most people use the in-app purchase content
Change the tiers and release your app as free
Dual versions
Make a demo version of your app. Note this can be rejected by Apple.
Create a file in the filesystem
Make a file in the filesystem and save into iCloud. The app will check for the file and thats how you would determine if the user has paid for the app (or should buy the in-app purchase).
iCloud will synchronise the file between user's devices and it will make sure that whatever device the user uses the app will see the user as 'paid'.
I hope this helps, currently having this problem myself.

Update in-app purchase content for iOS app?

I can't seem to find an answer to this question anywhere, so here goes...
I've developing an iOS app that will have non-consumable in-app purchases (expansion packs). Say I sell a pack that has 10 levels in it, for example, and in a month I want to update that in-app purchase to have 15 levels. The user will NOT have to re-purchase the pack; they would just need to update it.
Three questions:
Is this even possible?
How are users notified of this (or how SHOULD they be notified of this change?)
Does Apple need to review changes like this?
Thanks in advance,
Rick
Clearly yes. It is up to you, to write the code in a way, that your app remembers which updates a user has bought and how these updates are interpreted in your app. The only thing that will stop you from changing an in-app purchase content is when you take functionality or in your case levels, away again. Apple won't allow you to upload a new paid version with less functionality.
I would probably tell the user in the info text you have on the app-store, that they will receive 5 additional levels if they already have the 10 level upgrade.
Apple reviews every change you make to the app when you upload a new version to the app-store. This is true for any feature as it is for updates to in app purchase.
I did something similar to this in my app recently. I was saving a BOOL value in NSUserDefaults that specified if the user had purchased the expansion pack. In my update I simply had the change the code that was given to the user based on whether or not that BOOL value was YES or NO. As long as you designed it correctly you shouldn't have any troubles updating
Yes it's possible. Provided you keep a track of who has bought what pack (ie. keep a bool value as an NSUserDefault), then they will still have access to it (even if you add more stuff/levels to it).
It depends what you mean by notified; they will know if they read the update comments when they install the update. Also you could just choose to alert them when the load the app after the update - your call.
If you're submitting the code Apple will review it. Just think of it like any other update to an app.
Hope this helps!

Resources