how to know app was priviously install on ios device? - iphone

There is any way for identify that user is installing my app again? Actually in my app i have a feature user can translate some word for free but after that he have to pay. I am using in app purchase for same. But what if user delete app and install again ? he will be able to translate again for free.How to know app was previously install on that device?

Application goes to the App Store for in app purchases. If user has already bought that item, it returns true to your request. User won't pay it again each time.

Some implementations of in app purchases use the keychain to record purchase flags or freebie flags as you mention.
This blog entry will show you how to store and retrieve something from the keychain.
This approach really doesn't to my mind sit well with the principal of sandboxing an application so I expect it's frowned upon by Apple and by purists but if you search SO then you will find other posts relating to in app purchases and using the keychain.
See this answer as it seems to be pretty definitive on the subject.

Related

Making the ios app in app store so that one apple id can install the app once [duplicate]

This question already has answers here:
Allowing only one download per Apple ID
(3 answers)
Closed 9 years ago.
Although it does not look like a technical question however it is, cause I want to make my app in the way that one apple id can download the app once and if he/she wants to re-download or re-install it, it will be prohibited from the app store or from the app itself in the device(Programatically).
The reason behind the same is to make one registration per apple id in the app so that I can choose the identical one from many.
Is it possible?
Thanks in advance.
Even if possible it would be against Apple's rules -- they insist that users can install each app on all of a users devices.
Only one download for each Apple Id
That's against Apple's software philosophy is that once you downloaded it, you can use, delete, redownload it.
An Idea
Add a non-consumable in-app purchase to your app. for registration. you can set this purchase to be free. That will grantee that an apple id will only register once. seems to be a good idea.
In the iTunes connect you can add in-app purchases to your app. (people will purchase from inside your app.) there are 3 types of purchases (products). A non-consumable product is only allowed to be purchased once per apple id. You also can set this purchase to be free.
You need to include the store kit in your project to handle store management.
Every time a user try to register will enter his/her apple id to purchase a registration. (you can call it registration key as a store name). apple store will send your app a receipt which you will validate to let the user register or you just tell him you already have an account with the following username and password. or you can let him reset his password.
This is not possible to do with the valid API's you are allowed to use for the store. You'd need to be jailbroken.
You can keep a record of the device on your own server and restrict functionality that way.

Persistent device identifier even after app gets uninstalled

In my iPhone/iPad app's use case, there is a voting system and one device can send its vote once to the server. Therefore my server needs to identify user's device. I don't want the user to register an account because that makes the app complicate. However, I couldn't find a solution that works.
UDID is deprecated
I presume getting MAC address will get your app rejected by the app review process
I tried creating my own UUID using [[NSUUID UUID] UUIDString] and then storing it using NSUserDefaults, but the settings disappear if the user uninstalls the app
identifierForVendor is also reset when the user uninstalls the app
I considered advertisingIdentifier but because I'm not using it for advertisement, I presume it will also be rejected by the app review process
I'm not asking for a bulletproof solution in every situation. Just a solution that works even if the user uninstalls the app. Because I can generate my own UUID, I guess my question boils down to: How I can save data for the app that survives app uninstallation?
However if any of you have other approach, please feel free to inform me. Thanks.
Save the UUID into the keychain.

Paid App : need to uniquely ID the user

I am designing a paying app that will require users to create their own profile.
This app will of course be downloadable on each of the devices the user has.
This is the precise scenario I want to bypass :
the user downloads the App on an iPhone
he creates an account and start using the app that makes server
calls
he downloads the app on his iPad and with his login & password
retreives the data on the server, so far so good
Now, he lends his iPad to a friend (who didn't pay for the app).
The friend wants to use the App, and wants to create his own
account. Yet, I want to forbide this since he didn't pay for the
App.
So my problem is : I want to restrict the use of the app only to the user that paid for the App, not for his friend.
Of course, I cannot use the AppleID since there is no way to reach it from code.
I thought one moment that I could use iCloud like mentioned here but since the ( iOS unique user identifier )user can choose not to use iCloud, my problem is not solved ...
Is there an easy solution that I missed to solve that issue?
You friend will be using different apple id. You could use Restoring Transactions api of apple to get understand whether the user has purchased the app or not. This is possible for non-consumable in app purchase. Please do check the below link :
https://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/MakingaPurchase/MakingaPurchase.html#//apple_ref/doc/uid/TP40008267-CH3-SW1

Can I transfer an app to another account once its up under my account?

We have a company account for the iOS developer program.
One of our clients wants to put the app we developed for them up under their own company name, but they've only just sent off for enrollment and as such they want to put the app up under our name until they get their enrollment though.
Is it possible to "swap" the app to their account once theirs is set up?
Thanks
This issue has come up in the past. I know it used to be that you had to get Apple to do this manually, and it took a long time to boot. I imagine they'd like to improve their process for it, and I'd suggest contacting them to ask where they are at with it.
I wouldn't do it. Apple is really slow answering support question so you can easily loose like few months to transfer the app. But it is doable as stated here: Transferring ownership of an iPhone app on the app store
Just got this email from iTunesConnect!
Apps can now be transferred from one developer to another within
iTunes Connect, for example after an acquisition or when a
distribution deal expires. Transferring the ownership of an app does
not affect the app’s availability on the App Store. All ratings and
reviews will be transferred and your customers will continue to have
access to all available app updates.
To transfer an app, go to the app’s App Summary page in the Manage
Your Applications module on iTunes Connect and click Transfer App.
Make sure that:
Your account is active
You have accepted the most current version of your contracts
Your app has at least one approved version
Your app is in the Ready for Sale, Invalid Binary, Rejected, Developer Rejected, or Developer Removed from Sale state
Any associated In-App Purchases are in the Ready to Submit, Ready for Sale, Rejected, Developer Removed from Sale, or Approved
state
You know the Apple ID of the recipient’s Team Agent and their Team ID.
For more information on app transfer, see the video tutorial on iTunes
Connect. To find answers to common questions about app transfer, see
the FAQ on iTunes Connect.

iPhone/iPad app rejected because of subscription model?

We intend to launch a free iPhone/iPad app on the AppStore.
The content will actually be accessible thanks to a subscription model (login/pwd authentication in iPhone app).
The subscription (about 100$ a month) is handled via a dedicated web server.
If used without subscription, this app will provide minimum value.
Does anyone know if this kind of subscription model can be rejected by Apple ?
I know some apps follow this model, but I'd like to have your thought on this before starting in this direction.
Thanks for your answer.
This is fine AFAIK - As long your app is free and you put in the description that it requires a subscription to whichever service. When you submit the app, you'll need to hand over details to a test account to Apple so that they can test it, but other than that it's no hassle at all.
I know of an app which works just like that on the app store right now - Spotify for iPhone. It's a music playing app which streams music from the web - but you need a Spotify premium account. When you first open the app, you have to sign in, and if you don't have a premium account it just tells you that you're not allowed in!
Javawag
There are plenty of apps which only work if I have an account somewhere, and some for which I have to pay for that account so, without knowing the specifics, there is nothing which immediately rules out your subscription model. There are even Apple apps, iDisk for example, which are useless if you don't have a $100 mobile me subscription.
If there are issues you can look at selling your subscription as an in app purchase (apple will take their 30% which should make them happy) or look at making the app more functional without the subscription.
Either way, when submitting for approval make sure to set up a sample account with a full subscription that the apple testers can use (there is space in the submission for including logins for this kind of thing).
Our app, previously approved, update was just rejected because we sell subscriptions through our website. (We have been doing this for 15 years, without giving Apple 30% of our money.) They are requiring that all subscriptions for iphone/ipad content go through in-app purchasing. I guess we will be looking at building a browser based app instead.
Cheers,
Gerry