we implement in-app purchase, but want to receive some information about user: the user will have an option of preordering some content without payment.so that our servers wouldn't work useless we'd like to force to register.
Can we make some request and learn the user's id, which he uses in AppStore.
or it is prohibited?
I don't have a solid answer for you, and nothing to cite. But I'm almost positive this is not permitted. I'd suggest reading the docs, and doing a bit of research.
You can likely find a way to get the user ID, but it will probably result in the rejection of you app. Apple doesn't like this kind of behavior.
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.
Client looking into using QR codes in print advertising that will reward the visitor with a discount. Simplest solution (to the best of my knowledge) is to make the QR code point to a unique URL (ex. using a GET parameter for a "coupon code") that is used to store a cookie and then check for that cookie upon checkout to apply the discount.
Now most of the QR apps I've been looking at have embedded browsers. If the user scans the code and completes the purchase right within the app, I believe the above solution would work. But an ideal solution would allow the user to scan the code on the go and then visit the site up to X days later and still receive the discount. If a user returns to the site later they will probably use the mobile phone's standard browser app (i.e. Safari on iPhone) and not the app they originally used.
The answer to this question says that "each SDK app is given its own WebKit cache and cookie stores, so while cookies will persist within the same app, they aren't accessible betweeen apps." So it seems impossible to me to use the above solution to enable a user to scan a QR code and visit the site later and guarantee that a discount would be applied. I cannot think of any other solutions, but before I conclude that it simply cannot be done I wanted to see if there are any other solutions I am simply not thinking of (short of having the user create an account and store it server-side)
P.S. Obviously there are other devices besides iPhones but if I can't even get it to work for iPhones that would be enough of a deal breaker. In fact the variety of possibilities regarding mobile devices and QR apps makes me think there's a very good chance that it really can't be done.
There's no way to setup a website that will can automatically give the discount to returning visitors across different web clients on iOS. You'll need the end user's help.
You could have the QR code link to a special landing page that tells the enduser to bookmark the page to get the discount at a later date. If QR app can save a bookmark, the end user will come back through the QR app. If the QR app can not save a bookmark, the end user will view the page in Safari and bookmark it there.
You could have the end user register for the discount, and then send a discount code by e-mail. Merely asking for an e-mail address should be sufficient. When he returns to get the discount he will use the e-mail with the discount code.
The solution to this problem is not to tie discounts to browsers, but to humans. Humans tend to have the same address, and fairly often the same credit card number. These are things that are much more valuable to check than cookies. If a given billing address or credit card # has been used for a discount before, then deny the discount on the second usage. This will solve the problem 90% of the time (and nothing will beat about 90% of the time).
Cookies are a fine first step (low-hanging fruit and all that), and are fine to check if they happen to be there, but keep in mind your actual goal. You want a single discount per paying customer, not a single discount per app/device/blah-blah-blah. All the latter are proxies for the former. Focus on things that identify actual paying customers.
If I have a Facebook app, and my users agree to allow my app to access their information, photos, friends, etc, is it ethical to grab their information when they log in, and then saving it in memory so that the next time he goes to my app, it can load faster?
If so, what about when the user logged off? Is the right thing to do to is to delete all the cached information and photos that the user provided?
Has Facebook got any way to detect that we're doing this (saving their information, etc)?
EIDT: Just to be clear, Facebook's term and agreement is not very clear on this matter (agreeing to access information is not always equal to agreeing to have the information stored). As in where I'll be storing the data, it will be just in the user's disk, not my own server. So I can't guarantee that the data is being encrypted securely (If someone steal the phone, that someone will probably be able to get the data)
And yes, my intention is to give my users a better app experience, not anything else.
EDIT2: I'm torn, one answer with very high votes says it's ok because I'm providing a better user experience, but others says I'm breaching privacy. Can anyone provide links to the documentations? Or can more people vote? I'm really glad for the responses!
You're not being malicious. Providing the user a faster experience is beneficial to both the user and to you.
With that said, if the data is not stored on your server in a secure manner and you're being reckless or negligent with the security of that data, then that may raise some ethical questions.
I'd say that it would probably be best to have it off by default, but possibly prompt users to opt-in for faster load times. I think a lot of people would have a problem with you storing their personal data on your server for an arbitrary amount of time past when they sign out of the app.
My answer is similiar to #Keysmack.
I believe you should set default to "off" for caching user's personal fb data.
Opt-in for faster load,performance, more features, etc are all good reasons.
The reason you should offer off by default is that it is actually illegal to store user info without getting their permission in countries such as Australia.
so make sure you consider the legal requirements of the countries your users come from as well as the FB T&C.
Update: Apparently my country passed some new law that makes it a legal requirement to store data for up to 90 days.
I am getting ready to submit an educational app to Apple for review. The app is somewhat like a series of flash cards, and working through the entire app would require thousands of "flips".
In the hopes of shortening the review process and preserving some poor tester's sanity should s/he want to see the end state of the app, I am considering adding some way to fool the app into thinking that the user is done. My first thought is to add a check for a boolean in standardUserDefaults that would do such, and giving the name of the setting in the "provide us with login information" field on the app submission page.
So my question is, does anyone know if app reviewers are able to directly edit NSUserDefaults values?
Alternatively, does anyone have any other good ideas for accomplishing this?
(I would prefer to avoid "secret key press" type solutions if possible...)
As part of the submission process apple will ask if your app has any "demo" or "test" accounts. They are intended for just this purpose. So you may want to consider including a "secret code" and document it in this section. I know you said you don't want to go that route, but i highly doubt a tester is going to do anything outside of the standard process (such as edit NSUserDefaults)
Have the test account you give Apple for review (password protected) ask your server for permission to unlock all the data. You can disable this test account on your server after the app is approved; and/or after a certain date, by which time you expect the app to be in the App store.
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...