O.K so I'm writing a iPhone travel guide, you purchase a subscription to a travel guide for 3 months, it downloads a fairly hefty database and for 3 months that database gets updated weekly with new stuff.
Now what I'd like to do is make the user enter their email address as a one off action before they purchase their first guide, for China say. The purpose for doing this is
1) To allow me to contact the user by email when they add a note/tip for a particular place (the app will allow them to send notes & information to me)
2) To Uniquely identify who has purchased the subscription so that if they wipe their device and reinstall the app they can plug the email address in and pickup their subscriptions again. Or so they can use the same subscription on another device they own.
My concerns are
1) Will Apple allow the email method of restoring functionality to a second or restored device?
2) As long as I tell the user what I'm using their email address for (aka I won't sell it to anyone else and use it for X purposes) will it be o.k to ask for said email address?
And as a side note, can I tack the devices unique id onto my server comms to track devices or is apple going to through a hissy fit about that as well?
Our app got rejected because we used email to uniquely identify the user. From apple review guidelines:
17.2 Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
For subscriptions UDID can't be used to uniquely identify the user. So we were using email address. Back to drawing board.
Related
Currently I'm working on an app for a social network, where users have to purchase premium membership to unlock some extra features.
At first I used auto-renewable subscriptions, but my app got rejected. They told me to use non-renewable subscriptions and:
Non-Renewable Subscription content must be made available to all iOS devices owned by a single user, as indicated in Guideline 11.6 of the App Store Review Guidelines:
11.6 Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
If you choose to use user registration to meet this requirement, please keep in mind that it is not appropriate to require user registration. Such user registration must be made optional. It would be appropriate to make it clear to the user that only by registering will they be able to access the content from all of their iOS devices; and to provide them a way to register later, if they wish to access the content on their other iOS devices at a future time.
The most logical way to transfer subscriptions in my case would be by using registration, as user can't view the content (or purchase subscriptions) without registering and logging in. So this means that registration is required.
Will my app get rejected again? If yes, then what workaround would you suggest?
Any help would be greatly appreciated.
Yes and No.
If you force your user to register (especially with email address) =
REJECTED
If you make registration optional and let the user to use your app
with limited access = APPROVED
(The above statement was from my own experience and understanding. Please correct me if I'm wrong.)
First my app got rejected for using auto-renewable subscriptions.
But second time my app got rejected (this time non-renewable). The reason is, my app requires user registration. In apple's term, 'requires' means 'force'.
If you choose to use user registration to meet this requirement,
please keep in mind that it is not appropriate to require user
registration. Such user registration must be made optional. It would
be appropriate to make it clear to the user that only by registering
will they be able to access the content from all of their iOS devices;
and to provide them a way to register later, if they wish to access
the content on their other iOS devices at a future time.
From the above, the highlighted lines makes it clear that, the user registrations MUST be optional. If the user wish to access on other iOS devices, they can choose to register. But there is a catch again.
The catch is,
17.2 Apps that require users to share personal information, such as email address and date of birth, in order to function will be
rejected
So what I'm going to do is,
I would let the user to buy subscriptions without registration. But I will auto register the user with the unique ID to identify the user later. And showing the user, that, they have to register with an username and password in order to access the subscription among other iOS devices.
I would not force the user to register with email address. Instead, I will use 'username' as mandatory and 'email' as optional, but stating that, it's recommended to enter the 'email' so that, it would be easier in case of password recovery.
This is my experience with apple's in-app purchase so far.
Please correct me if I was wrong any where...
Auto-renewing subscriptions are only for periodical content like magazines, newspapers, etc that appear in the newsstand app. Apple will flat out reject any use of Auto-renewing for any other purpose. You have to use Non-renewing Subscriptions for "Services". Best info for this is http://developer.apple.com/news/pdf/in_app_purchase.pdf
As for the user registration chicken-and-egg scenario, you can get the app approved if it allows registration of anybody regardless of in-app purchases. That is to say, only allow the IAP after the user has registered. Your "Free" users can just have limited content.
I don't think that Apple would reject an app just for requiring registration, unless that registration's sole purpose was to allow a user to share their subscription across all their devices. In that case, Apple insists that you provide an optional method for the user to share the subscription.
I have an Iphone application in which i am trying to implement non renewable subscription.I had done it a manner that after the purchase i am adding that details to user account information.so he can get it on all the devices.I have a login at the start of my application.And after associating the reciept data with the user account i was finding out the expiry date in my server from the purchase date in the reciept data, by using that information i was showing the buy button again to my user.But the apple is rejecting it for the reasons
11.6: Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
Can anybody know the exact mechanism to implement nonrenewable subscriptions ?
From your description it sounds like your login when they start your app is mandatory. Apple forbids this. They insist that the login be optional, but it must still be available to everyone who wants to use it (when using non-renewing subscriptions).
What I did on my app was, next to where I show the user's purchased subscription level, I have a button that says Save your account.... And when they click it it describes to them how, if they create an e-mail and password than they can share their subscription across all their devices and they can restore their account if their iPhone gets lost or stolen. You want to incentivize the user to do this because a better experience for them means a better experience for you. You could even offer them a perk, like 2-weeks free if they create an account. And since you're using non-renewing subscriptions, you have the power to do this since you're calculating your own expiration date, instead of letting the app store do it for you.
I have created an application for my customer. We have published the application with my account. Now, they want to change the developer name as their company's name. Is there a way to change the developer name? Can I move my application to their business account so that Developer name changes to their business name?
Yes, you can transfer the app to other since WWDC 2013.
Also, you can call the Apple Support to change the Seller Name.
Here is a video about this: App Transfer Tutorial.
My apps initially appeared in the App Store with the wrong seller name. I don't personally own a credit card, so a family member who did paid my developer subscription. While my correct name appeared elsewhere, under Seller it showed the name from the credit card. I used one of the contact options in iTunes Connect to request a name change, which was applied within a few days.
On the current Contact page, the Contracts and Legal category includes Request Name/Address update. Try that.
You'll certainly find it easier to rename your account than to move the app to a different account. Here's what they say about that.
I sold my app to another developer and can no longer distribute it on the App Store. Can I transfer the app to the new developer's iTunes Connect account?
No, you can’t transfer the app to another developer account on iTunes Connect. To add the app to another account, remove the app from the current account and upload it to the new iTunes Connect account.
Note that uploading the app to a new iTunes Connect account will disable current customers from receiving automatic and free updates of your application. All customer reviews, rating, and ranking information will be reset. You will not be able to reuse the app name and SKU in the old account. If you have uploaded a binary or used the app with the iAd Network, your Bundle ID will not be reusable either.
This is only applicable for the part of the OP's question:
Is there a way to change the developer name?
The most simple way I found to CHANGE the developer name was by filling out a request on this page:
Contact Us Page
Then select from the option:
Enrollment, Membership, and Account -> Account Updates and Renewals
I just told them which names I would like to user, First name and surnaame.
Here is Apple Support email regarding same question;
As an individual you cannot change your first and last name, you can
only have your legal name appear in the App store. I can suggest to
you to enroll as a company, witch would mean you can use your company
name instead of your own name, but first you would need to check that
you meet our initial migration requirements:
You are a founder or cofounder of your company.
Your company does not already hold an active or expired company membership.
Your company does not operate as a sole proprietorship, DBA, fictitious name, trade name, or branch.
If you have paid apps, you have agreed to the latest Paid Applications contract in Agreements, Tax, and Banking in iTunes
Connect.
You are eligible to obtain a DUNS Number for your company: https://developer.apple.com/support/D-U-N-S.
If it is the case and you meet our requirements please feel free to
contact us again so we can migrate your account into a company.
If you need to transfer your app to another developer account, that is now possible. Since WWDC 2013, iTunes Connect now supports transferring apps from one developer to another, keeping exactly this situation in mind. Go to the iTunes Connect homepage for more information. There is also a video tutorial that Apple has provided on this matter.
Personally I wanted to changed my real first & last name to a company/brand name, having an individual account. That's what, as of 2020, Apple's support says:
"Developers enrolled as individuals will sell apps on the App Store using their personal legal name. There are two ways to change your name to a company name:
Have your company enroll in its own Apple Developer Program membership, and then transfer your apps to that membership.
Migrate your membership from an individual to an organization."
I am working on a application which has a more peculiar requirement. Basically it is something which is not targeted at end users but at a system integrator who will embed an iPad into a larger system and sell it to an end user as a whole.
However, the problem I'm facing is that the system integrators could simply purchase the app once and then keep cloning thousands of iPads from a single iTunes account, my company would not get any revenue from this.
Is there any way around this. I've looked at in app purchases but according to the guidelines I'm supposed to give in app purchase restore functionality so I guess if I don't the app won't get approved.
I could use external authentication servers I guess, but that may be viewed as circumventing the app store.
I've loked at the volume B2B stuff but I'm not quite clear on how that works or if it would help me in this case.
Any ideas?
Thanks
Last time I checked an application can only be installed on five devices, and then the other ones simply refuse to install the application.
If this system integrator managed to circumvent this, it's he who is breaking the App Store rules.
You can't use the App Store mechanisms as you described (you can't change iTunes). In-App purchases of non-consumable items must include a restore option so the user can restore it on all his devices even if it's thousands (this also for subscriptions etc). If you won't enable that you would be rejected.
You can think you can send the Device-ID for each device that purchase the item and have control over that(or any information) but apple would simply reject your app because it's forbidden to send device-ID.
If your service is online you can simply use some kind of tokens created on your servers which would be given to each client (from some kind of private key), This way you must be connected to each purchased item (only those would contact your servers and you would grant access).
Security wise you must consider leaving some of the functionality on your server side. This is not illegal same as you can't access Facebook without username& password.
And now for the easy way, Define your service as consumable item for in-App purchase(if you can). What does it mean? Lets say you are selling a special feature like "Ad-Free" you can sell credits that would be consumed with each app open or any other process you have in mind, You can even set this credit to 1 million for 0.99$ (so the user never gets to that) but still the consumer would have to buy it again and again for each device and it would be absolutely legal by Apple. Pay attention that the problem would be on the consumer side such as that if user have deleted his app you should find a way to help him or refund him on next buy. Also, If you can and would use this method pay attention to save those credits on the restored folder on the device, so if the user would upgrade or restore the device he would still have the credits he bought.
Pay attention that if you are going to use in-App there are lots of methods to steal this content on jailbroken devices and you must use your own server to check the buying process (according to Apple).
Another important thing is that the app without the in-App purchase must have some value to the user.
I have an app which costs $5. I'd like to change this so that the app is free and that users must purchase an auto-renewing subscription to use it. I know how to implement the auto-renewing subscription, but the problem is dealing with users who have already bought the app for $5; I'd like to continue letting these users use my app without a subscription.
The rub is that for privacy reasons I can't store any identifying information on my server which link an account for my app to a specific person (not even UIDID). What I can do is maintain a separate database table which links UIDIDs to subscription purchase receipts which will allow me to know if a user has a subscription.
So my question is, how can I identify users who got my app when it cost $5? I know there's a way to restore in-app purchase receipts, but is there a way to to retrieve a receipt for the initial purchase of the $5 app which I could store on my server?
The poor man's solution is just to mark all current UIDIDs (i.e. the UIDIDs of people who have paid $5) in my server as paid, but then they would have to buy a subscription if they ever wanted to use my app from a different device.
The previously selected answer is outdated. The new answer is that it is possible today with the new receipts that were standardized this year (2013).
The receipt now has two additional fields: original_application_version and original_purchase_date which can be used to detect when a user purchased and therefore be used to guide logic around what users should get what features.
You can see more about 10 minutes in here: http://devstreaming.apple.com/videos/wwdc/2013/308xex4x6ybggtlw4ztv0sg5btp/308/308-SD.mov?dl=1
or if that link dies here: https://developer.apple.com/wwdc/videos/ and search for Using Receipts to Protect Your Digital Sales.
Chaning your business model like this is not very well supported by the App Store.
Your "poor mans" solution is probably one of the best of a poor set of options.
Another one would be to switch to a new app entirely (just a different bundle ID in practice). Anyone using your old app would have paid, regardless of which device they use. Anyone using the "new" app would need a subscription. Obviously you'd lose any reviews and possibly external links that you currently have.