Problem
When A user downloads my application, they'll have the ability to use a certain feature. Say, 5 times. After them times are up, they'll require the iAP to continue using it. However, I have a few problems.
I want to make it simple, and just store it in the userDefaults, or keychain. However, if they re-download the app will they then have access to the feature another 5 times?
And I don't want to have to include external information from a data-base with user logins etc.
Solution
Being able to check if this particular phone has used the application before, if not. They have 5 goes stored in their defaults. However, if they haven't where to go from there?
1- At anytime the user may restore his device and reconstruct the keychain and use 5 times more.
2- You can set a server for user management.
I guess first option is acceptable and easier than second. Not much people resets his device's data just 5 more rights in some game.
Check NSUserDefualts if you have saved their usage counter. If you haven't, save it as 1, otherwise increment it.
If you've saved it before, and the increment is at 5, tell them that free trial is up.
Technology-wise - if they delete the app, I believe you'll lose your NSUserDefaults as you can see here. What about using iCloud? Is that too much? You could store that trial is up. But yes, internet connection would be necessary for that operation.
If your app is really good and users will want to use it then they won't think about deleting and re-downloading. If they won't see value in the iAP, they'll try to "hack" it. That's a philosophical answer...
Related
I have a basic query here. My app has a bit longer signup process. While testing I came across a bug where, whenever amidst the process if the user goes out of the app or kills the app, the remaining process is just left and it migrates to the a specific page, that i want the user to usually go to already.
Example if I have 5 ViewControllers and then a default 6th and if the users kills the app on 3rd VC, and then restart the app, it'll go to the 6th vc and ignore the rest of signup.
How do I avoid this. is using NSUserDefaults an optimal option. If yes How do i exactly implement it.
Cheers!
Yes, using NSUserDefaults to store the previous state of an app is common. (However, apps that have a server backend may store some data there too.)
Use the keychain to sensitive data (e.g. account details). (You must never ever store sensitive information in NSUserDefaults because it can be read.)
What you store in NSUserDefaults (and the keychain) depends on your application. If fields are filled in and/or options selected during the process, you need to store that.
Be pragmatic: It's very nice to users store app state. It can however get rather complicated. Don't waste time (with chances for bugs) trying to cover situations that don't occur often.
I was attempting to use apple's HealthKit authorization modal in my App's settings, to allow a user to toggle their info on/off for sharing. It automatically pops up the authorization screen. However it seems to only do it once and then never again. At least until 24 hours later maybe, where it will prompt again if needed.
Is this meant to be used similarly to PushMessage requests, where a user is prompted once and then not ever prompted again from the same request?
I'm skeptical to add this modal prompt in the App's initial load as it is quite intrusive as a full screen modal; even if called only once ever.
Basically the user suppose to see it once (as when asking to grant push notification permissions, or access to contacts).
I have found out that for each datatype you want to share with Health app (or read), you got one shot with the modal prompt. This prompt might be a bit tedious to the user as it shows the entire types your app ask for permissions (both read and write), and I assume this is why Apple said a best practice of HealthKit is to ask the entire permissions your app need at the same time (though some might argue with that in a matter of UX).
If you wish to ignore Apple suggestions of this best practice, you can ask for read/write permissions for each datatype separately - Doing so will result prompting that modal sheet each time you ask the permissions to a different type.
In the bottom line, this permissions sheet is meant (by Apple) to be shown to the user once. You can find a way to pass that limitation (yet for a limit amount of times - depends on the amount of datatypes available), but I won't recommend bypassing Apple's guidelines (it is never a good idea).
A trick to use is to modify the Share/write types in your authorization, this will require the user to look at it again, thus pop it up every time.
I want to develop an iOS app which consists of array of items and each item will have some text data along with the Image. I don't want to use the external server and want to make use of iCloud to store all the user data. User will be provided with any option to enable/disable the iCloud sync. Each item's data (text and image) will be wrapped inside the directory and gonna synced to iCloud, for this I'll be using UIDocument approach.
I went through the internet and found that unless we are storing NON-USER GENERATED DATA in iCloud, we won't be facing any problem in Apple Review Process. Please let me know whether my understanding is right here and is there any possibility of rejection from Apple. Just want to be double sure before proceeding towards the implementation.
Also, are there any other important points I need to consider?
Please let me know whether my understanding is right here and is there any possibility of rejection from Apple.
The first thing to understand is that there is always the possibility of Apple rejecting your app, for any reason. Their terms basically say that they can reject anything they want for any reason, even if you're not doing anything that violates anything on their list of rules. There is no guarantee that Apple won't reject your app, ever, full stop.
As you describe your app there is nothing obviously breaking any of Apple's rules, so it sounds like you're OK. That assumes that the images are not something that could be re-downloaded at some point, e.g. that they're photos or some other kind of image created on the device and not downloaded from somewhere. No guarantees, but odds of Apple rejecting you specifically for this reason are low.
I have a game where users can do a certain activity once per hour. How can I make sure it's been an hour since the last time they attempted something without them just changing their devices current time in settings?
Also, if I wanted to prevent the user from just deleting the app and re-installing it so they could constantly keep trying without having to wait to full hour is there any way I can store data on the device even after an app delete or would that have to be a server thing?
If I don't have a server can anyone think of a clever way to do this via Free in-app purchases or something?
The only way to persist data in a way that survives app reinstalls is to save it to the keychain. This works, because keychain data may be shared across multiple applications; the rest of your application's data is removed on uninstall.
If you need a reliable way to tell the current time, the device must be connected to the internet. In this case you would be able to check the current time using one of the time services through the NTP.
That sounds like exactly the sort of task you would need a server for.
When the user wants to perform this limited action, have them ask the server for permission. You can log the user's ID and request time, decide if they can execute the action, then return a small success/failure message. Works if they change their clock, works if they log in from a different device, works if they wipe the device data.
What I would like to know is whether there is anything wrong (in terms of the law, and App Store guidelines) with storing information about your application, and broadcasting it to an online location for gathering.
Specifically, an application which would normally not connect to the internet, connecting when it starts up and storing usage information like time of day, the device ID, and how long the person uses it for.
I'm guessing this sort of behavior is fine so long as you get the users consent first?
It’s fine if you ask the user first and give him an option to turn this feature off. We were once spanked out of the App Store simply for uploading a new game high-score record without a cancel button. It’s quite a long time and the rules might have changed, but better safe then sorry and your users will like the confirmation screen, too.