I am working on Google Action for Google Assistant. Our custom Action relies on user's phone number to get additional information from external server.
According to the official guide you can use Account linking with Google Sign-In to get some user information from Google ID token:
name
given_name
family_name
profile_picture
email
locale
I know that you can fill out optional contact fields in Google account like address and phone number.
Does anyone know if Google ID token contains this optional information or no?
The answer depends.
Some basic personal metadata is available through Google Sign-In. With regards to the other fields:
Address
This information is not easily accessible. You can use an in-dialog permission to access the current location, but not the home address necessarily.
If your Action uses physical transactions, then you can get their address in order to ship items. But you shouldn't use this as a way to get the address if you're not shipping items, and such an attempt would be detected during review.
Phone Number
No, this is not something you can readily access. For general things like notifications, Google Sign-In gives you an email address. You also shouldn't ask it in your Action. The review team won't be happy with that, and the voice transcription doesn't work very well for long numerical sequences.
Gender
No, this is not something that is part of the Google Sign-In, and there's no helpers. With regards to asking it yourself, I don't think the review team would have a problem, although you may want to consider whether it's necessary for a good voice design.
No. Address, phone, and gender are not available fields/claims in Google's ID Token (JWT).
See: https://developers.google.com/identity/protocols/oauth2/openid-connect#an-id-tokens-payload
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.
I am fairly new to iOS app developemt but I am doing some research on behalf of a client who wants to create a native or hybrid iOS app that allows users to take a photo using their iPhone camera and proceed to automatically send that picture (upon confirmation by user), with a unique identifier attached to the email, to a predetermined email address. Is this reasonably straightforward? Are there any privacy issues that need to be addressed when sending this type of data?
Also, how would that user be identified so that the relevant response can be sent back to them? Basically, what happens is the photo of the product is received and that product is manually sourced from a chain of partner merchants. Then, the prices and merchant details are sent back to the user. How might this work on iOS?
Many thanks, sorry if this sounds too vague but just ask for more details.
You can Use PHP for backend For Uploading the image in server and Generating a unique code for each pictures uploaded by user.
So the process is like iPhone -->upload.php -->get the response link from php and mail that link to specified
is there an option that I could retrieve from my app the latest 10 email subjects from my ipad email inbox.
I would like to display the user his last 10 subjects in my new app.
Any Ideas if this is possible and how?
best
chris
No, it's not. Apple doesn't allow access to most user data that's handled by the built-in native software, and even then generally not without the user explicitly giving the app access (such as in an address book picker).
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.