I am writing a paid app for the store which gives you a 1 year subscription to some content.
This means I need to store on my web service db, when the user first launches the application some kind of unique user id (Apple ID?), along with the date. I can then do validation to check if the subscription is still valid.
I can see how to get a UDID but that's not really very good if they want to install it on another device with their existing iTunes account.
I would rather not make the user have to enter in an identifier themselves.
Keep in mind that the user may very easily change the apple id he or she is using on the device. He may even allow others (familiy members...) to use the same apple id. I wouldn't share mine, but there is no technical barrier for others to do so.
I can easily imagine apple not approving an app making such use of the users apple id, for this and a number of other reasons.
Having said this, I know of no way to retrieve it anyway.
Either tie the subscription to the UDID (and allow the user to migrate it later) or create some sort of accounts the users may log in to. I don't see a way around this...
Related
My app is a sync solution (imagine dropbox).
The user needs to sign in to access the app's features, and if he does not have any account already created, he can sign up.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
but Apple has rejected this app saying:
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
We found that your app requires customers to register with personal information to access non-account-based features, which is not in compliance with the App Store Review Guidelines.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user. User registration that requires the sharing of personal information must be optional or tied to account-specific functionality. Additionally, the requested information must be relevant to the features.
Although guideline 11.6 of the App Store Review Guidelines requires an application to make subscription content available to all the iOS devices owned by a single user, it is not appropriate to force user registration to meet this requirement; such user registration must be made optional.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Please help me solve this. Many apps like dropbox/facebook require login.
I don't get the exact reason why they rejected my app.
Also, please guide about the in app purchase, why registering cannot be mandatory
Asked App Store Review people for clarification on their rejection.
They accepted it. and the app got approved :D
Its on Appstore now :)
I also Faced this kind of Problem and my app also Rejected due to this.And Again I Changed my App flow Like User Registration will be Optional. User can See all the Feature of the app with out Registration by skipping this step.If he want to do something user-specific then you can ask to register such as : (user like,comment,photo upload etc) or else he can use the contents and features which are public.
in Case of in-app Purchase You can Prompt user that if He will Register with your app he can able to use this Content in his all devices.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Apple does not allow apps that require you to share person information to work, like an e-mail address.
You options are, remove the need for an e-mail address or remove account creation form you app and move it to a website.
It also states that you app is asking to create an account to access the full app and even needs the account or acces features that do not require the user to have an account. You can make those features available with out the account creating you might be able to get thru the review.
The reason apps like Facebook and Dropbox got thru the review proces is because they don't have a register option which is in app only. They redirect to a website.
I recently spoke to an Apple Rep over the phone in regards to an app of mine that was also accused of violating clause 17.2.
I explained to him that the email would be used for password recovery, monitoring transactions within the marketplace, and managing any inappropriate behavior (such as users uploading offensive or copyrighted content). The rep responded, "Sir, the clause states 'Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected'. I cannot allow you to require your users to submit their emails if its not account-based". He did not seem to understand that the emails are account-based for the very sole purpose of security.
I did mention to him that Instagram and Facebook alike require logins at startup. He simply replied, "Yes but those apps are entirely account-based."
Honestly, I felt he was blindly following Apple's Guidelines ("Because that's what it says we must strictly follow!"). He had little understanding of how social networking apps operate, and even less understanding of the law (specifically the DMCA - on a separate issue). Explaining to them how all that works proves to be futile; they wont budge because they are asked to follow Apple's BROAD Clauses as strictly as they do.
My conclusion: I had to compromise the app's user flow such that the app's registration page can be skipped, and all other functions within its marketplace were locked to non-registered users. It makes no sense.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user.
It seems to me that the point is that you are asking the user to provide his email address as a step towards the creation of a user account. This is different from what dropbox and other apps do (i.e, you provide your credentials for your dropbox account, which is different from your email address, although it can be the same).
You may either remove altogether email verification, or you could postpone it to a later point when you have made clear to the user that this is required to access private information.
I got the same thing last week and this is Apple's reply:
As for the 17.2 issue, a nickname, avatar, or sharing are not inherent or specific features of those social networks, and thus, the user should not be required to register with those services, or provide you with access to their social network accounts. The user should not be prevented from using your app and service if they do not provide this information.
Instead, it would be appropriate use your own authentication method and give users the option to create a nickname and upload an avatar, independent from those networks.
Moreover, we realize that these social networks may be very popular. However, the popularity of the social network is not an appropriate reason to force a user who has not, or chose not to register and provide their personal information to those services, before they can use your app.
Therefore, we ask that you to include your own authentication mechanism to allow the user the option to register only with you, creating an account with only the information needed and relevant to your app's features.
Best regards,
App Store Review
So in short, you have to provide custom authentication and not just use Facebook. Although I've seen many Apps who do require you to login with Facebook.
Thanks,
James
It happened same for me, although the first version was approved, the second version was rejected for this reason, I added the Skip button at the landing view.
It's all summarized in the last paragraph. Apparently, your application doesn't inform the user (in a clear way) that registering is for syncing and from their reply, it seems that your application is useless without the Sign Up.
If that's the case, you should be more specific why you need the user to register.
On a side note, I personally don't like the applications/websites that force you to register before you see or try anything. I hope your application isn't the same.
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 been stuck in a strange situation, according to my requirement, I need to track the resellers of my app, i.e. I will be publishing link of my app in the iTunes-Store on 3 or more different sites(The re seller's sites).
According to my promise which I made to these resellers, I will provide a share of my profit.
So here I have to track from which link did the user came to the APP-Store.
Any suggestions or solutions will be Thankful.
I think the only way to do it will be server-side. Links at your resellers should point to your server, where you log the source of link (resellers web page) and redirect request to AppStore. But you'll have no way of knowing, which of this requests ended up with a purchase.
The only way to do this for real is to get them to become iTunes affiliates and provide reports back to you. They should use the iTunes referral to make the sale (they will get a small cut from Apple) -- Apple will report that back to them, and then they can prove to you that they made a sale, and then you pay based on that.
Reserve the right to audit them -- meaning that they will have to show you the report directly from the iTunes affiliate site.
I assume that iTunes actually tells them what they sold, but you would need to check that.
Another idea (which may or may not make sense based on what your app does) is to make personalized versions of your app for each reseller. If there's some way to incorporate a very simple feature that is personalized (and makes sense), then you can upload the same app multiple times and assume all sales are coming from that reseller.
So, for example, if the app were an exercise tracker, and the resellers were gyms -- you could customize the app for each gym and add their schedule and contact info to it. Then, sell the app as an Excerise Tracker for XYZ Gym and let them promote it and get a cut of sales.
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.