One of the cool unsung new features of iOS 6 is the way it doesn’t ask you for a password every single time you go to make an app purchase.
( http://www.cultofmac.com/201559/re-enable-password-check-in-ios-6-to-avoid-nasty-in-app-purchase-surprises-ios-tips/#LasCHqVOtcTZxIjc.99 )
I'm writing an App for Children for a client, is there a way to ensure the user has to add his password for every in-app purchase from inside the App?
I mean, I can also show a message to the parents to change the setting, but maybe that's not what they want. Still their children shouldn't be able to buy things in the ensuing 15minutes after the parents bought something from my app.
Thanks for your help!
PS: Maybe if I could read the time since the last in-app purchase somehow and check if it's less then the 15 minutes I could show an extra alert.
The iOS API for In App purchases does not have an option to force asking for the password. I totally understand why you would want that but it just one possible with the current SDK. I also do not see Apple changing this any time soon.
It's not even your responsibility if you look at how Apple setup the In App purchases since iOS 5. Parent can just lock the ability to use in app purchases for the device it self.
You can of course make parents aware of this ability but you just can't force it.
Related
I'm facing this problem while designing my iOS app. Suppose that a user purchases an app and downloads it to the iPhone. I would like to provide him with a default consumable item the first time he runs the app to use whenever he wants , however I would also like to track if the user has already consumed the item. This way if he decides to reinstall the app we can restore the transactions (if he used the item) or we can avoid possible intents to download different kind of content by reinstalling app and consuming default items each time. (Guess NSUserDefaults is not an option here).
One approach that came to my mind was using UDID(or any iOS 6 alternatives) to keep a record on server of the user's device the moment he uses the default item. But this will limit items just to the device from which they consumed content.
It would be great to support all the user's devices (like inAppPurchases), but I can't figure out a way to implement this.
Any suggestions or help would be great.
Thanks a lot.
In order to tie information to a user (not just a device she used at one time), you'll need to ask the user to identify herself and save it someplace other than the device. In other words, a backend that implements registration and login.
From scratch, this can be a lot of effort that an iOS developer didn't count on. Fortunately, there are several services in the world that provide a substantial head start. Here's a nice round-up. I've had direct experience only with Parse.com, and think it's excellent.
With introduction of iOS 6, I read apple added Contacts privacy settings as explained here.
However, in prior iOS versions, this setting is not present and user privacy is at risk especially after people realized that 'Path' was dumping iOS contacts on its servers.
If an application wants to collect phone book data in iOS 5 or previous versions, which is the better way of doing it?
Ask for permissions explicitly once via UIAlertView.
Ask for permissions every time the back up is made via UIAlertView.
Create an application entry in Settings and ask user for permissions once.
Shun the idea of Phone Book backup altogether.
I think personally you may want to think about bailing on the idea as it seems to be a bit of a quagmire security wise, we are building an app at the moment that uses the address book for invitation purposes and we present a UIAlertView informing the user that we are access and not storing every time the view loads, annoying but it covers us.
I've been developing an application for our client and they are requesting that we add in compulsory updates for their application. The app allows sales-team members to showcase their product and they are worried that if a product gets re-called then the sales-team must reflect this in the app immediately or else there could be legal implications for the company. How feasible is this to implement? Are there any examples of this in use?
Cheers for the help guys,
Dan
The way you could do this is to get the app to call the server and ask for the latest version number. If it's different then stop the app and tell the user to upgrade. However, this won't work if they start the app without a network connection :)
I also don't know if this will be allowed by Apple?
A better way to do it is for the app to download a list of products each time it runs (cahcing it incse it starts with no connection of course!) so that the products in the app are always up to date and the users never need to upgrade at all.
I need to implement trail period in my app. How to do it? Store day count in NSDefault? or some other?
You could store a counter in the preferences as you mention, although that counter would disappear if the user reset their phone.
However, I think it's all slightly besides the point. In general, Apple frowns upon apps that have this kind of functionality, so don't be surprised if your app gets rejected. Consider launching two different versions of your app instead, a "Lite" app and a "Full" app. The Lite app should have a reduced feature set, but it should never stop working.
Apple is against the idea of you disabling features to prompt people to pay money for something. Your app needs to be fully functional and a 'lite' version and a paid version seems to be how things work at the moment.
That being said - if you implemented it properly you could add in app purchase items to enhance your app. Your original 'lite' app could be $0 and additional features can be added for a fee.
The most bullet-proof method would be to send and maintain a copy of the iPhone's UUID in a database.
Then if the App is not "unlocked" it requires a "key" form the database every time it launches. You can then implement the trial period on the server side.
However, if you decide to use some type of encryption to store or transmit keys etc you will need a licence to distribute the App.
You make a light version of your app. There is no official way to have a trial version at this time. Hopefully Apple will eventually address the need, but I can't say I would hold my breath...
I am wondering if there is some way to make an iPhone application where when a user clicks a UIButton, it to display an alert box about the item and then gives the user an option to purchase it. I see a lot of documentation on Apple's site regarding creating a view to store all of the choices of what to buy, but I don't really want to create my application this way. In addition, do I need to have my app in the app store before I can add in-app-purchasing, or can I do it before?
Thanks for any help.
EDIT: I am attempting to make the purchase "Non-Consumable", if it makes any difference in how the button would be set up.
The way a user makes the purchase is irrelevant and can be anything you want. The real challenge is getting the in-app purchasing up and running.