Given that Twitter doesn't provide users' email addresses to apps [1], how can a Twitter app contact its users?
One thing we've done is to have a corresponding Twitter account for our app, and whenever a new user signed up to our app through Twitter, we would follow them. But even so, we can't DM them from this account unless they follow us back. We can tweet "at" them (via mentions), but public tweets are out of the question for private notifications, and even if that weren't the case, users aren't notified of mentions unless they follow us, too.
Is there any other possible way then a Twitter app can contact its users?
[One possibility that would be great would be if apps could DM their users. This would still be independent of whether that app could access their users' DMs. That would let apps notify users (which is an important requirement for many apps), while still letting Twitter protect its users' email addresses.]
[1] https://dev.twitter.com/docs/faq#6718
The answer to this question is pretty simple: you can't.
Not entirely true, of course. There's #mentions, DMs and any notification feature your development platform offers, such as push notifications on smartphones. Then there's e-mails (just offer a newsletter to the user). But Twitter doesn't offer this to you, and probably won't.
You could make new users follow your apps account - then you would be able to DM them.
Making people automatically follow you probably breaches the Twitter T&Cs. So you would need to have this as an optional step.
User signs in to your app
You present a screen asking them to follow you - or a link if they don't want to
You can now DM them.
Related
I've recently had an app rejected due to the 17.2 clause
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
My app requires users to create a user account before they are able to use the app. All data in the app is tied to a specific user. Rather then create a custom login, it seemed simple enough to get users to signup with Facebook for "one-click" account creation instead of having to fill out a new account form. So I used the Facebook Graph SDK for iOS to accomplish this. However, I did not use any other features from the Facebook SDK and as a result of doing so, my app was rejected. I have a couple of uncertainties I was hoping could be answered.
Can I just implement a custom create account without the risk of getting my app rejected? The custom create account will require fields such as a userName, email, and account passWord.
I read somewhere that in order for Apple to approve custom account creation, the app must have some sort of Privacy Policy. Is this true?
What would classify as a "significant" use of Facebook services to justify the use of Facebook authentication? Would using features such as Share to Facebook and Invite Friends be significant enough to use in the app to get approved?
I'm curious to know how others have solved this problem and any advice or tips would be appreciated.
Facebook is very annoying with this clause. It isn't about how you are using the Facebook SDK, it is about asking users to create an account via any means. You have to justify your features so that they are user-oriented. You can bend the world in your favor on how you do this, though.
For example, even though a feature seems to be completely okay if user doesn't register, you can argue, "for better user experiences, we calculate user's performance on these features, and associate it with the account."
Or, you can go about saying "although this seem to be not user-related, we use the gender information to serve correct content."
Privacy policy is a must. You definitely need that accessible through the app and through the App Store page.
While working to get our app accepted after it got rejected by the same clause, my team spent a whole day trying to relate every major feature to something such that an account was necessary. But the good news is, it got accepted!
On another note, Facebook friend invites are fine, but making users upload a profile picture and create their own contents also need to be explained. They will ask questions such as "who will be able to see these contents?"
It is a tedious process, but more of a, "provide information and I'll let you pass" kind of thing. Good luck!
During my app review I received the following:
"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
Specifically, your app uses Facebook login for authentication purposes only, but does not include account-based features offered by that site, which is not allowed on the App Store.
In order for Facebook to be the only authentication mechanism available, your app must include significant account-specific functionality from Facebook. Pulling profile information, or sharing are not sufficient account-based features for Facebook to be the only authentication mechanism available.
It would be appropriate to implement your own authentication mechanism, or implement significant account-specific functionality from Facebook."
My Question:
What are some examples of "significant account-specific functionality from Facebook"?
Would allowing users to choose pictures from their Facebook for their profile, or displaying mutual friends using my app pass this requirement?
*Note: I'm building a dating app kind of like Tinder
Thanks!
There is certainly a bit of gray area here. But the question you need to ask yourself is, "how can I make my app useful to users who can't login via Facebook?"
If the answer really is "I can't" then your app does indeed require Facebook authentication. It's not useful to anyone who does not have a Facebook account. A contrived example of this could be, for example, "Facebook Group Finder", an app that scans your interests on Facebook and suggests Facebook groups for you to join. If you don't have a Facebook account, then this app can be of no use to you.
Clearly, Apple however believes that your app does not fall into that category of apps. It has useful functionality that should not require a Facebook account to use. According to Apple's review notes, it sounds like your app just requires Facebook credentials so that a user can log in, and does not use any Facebook APIs or information from Facebook beyond that point (or perhaps, it uses them, but using them is not crucial to its operation).
If this is the case, it sounds like you could replace the Facebook account requirement with a requirement for the user to create an account on your website (or whatever) instead, and not really have any loss of functionality compared to a Facebook login. Apple is asking you to add that as a login alternative.
Allowing users to choose pictures from their Facebook profile definitely wouldn't satisfy Apple, since Facebook is not by far the world's only source of pictures. Displaying mutual friends, this probably also wouldn't do it, but it's more of a gray area. It seems like you could just leave the "mutual friends" part out of your app for non-Facebook users.
If you are going to use Facebook log in, apple wants you to use significant account-specific functionality. This means that you should use things from Facebook like user interest or friend list. Using the user name profile pictures are not considered account specific functionality. Apple is saying if you are not using these information then you are not supposed to use Facebook authentication. You have 2 solutions here:
Use the significant account-specific functionality from Facebook ex. interests of friend list.
Apple will accept the use Facebook log in without significant account-specific functionality if you also add your own login and password.
Tender app is using only Facebook log in and it is not rejected because tinder uses your friends list and interest from Facebook. If you can point to apple how you are using information like this they will accept your app.
I am sure of this information because I got it from apple review team member today!
Other authentication means, provide features that user can be able to sign up using his email id. What I understood from above is you have used only fb authentication.
During my app review I received the following:
"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
Specifically, your app uses Facebook login for authentication purposes only, but does not include account-based features offered by that site, which is not allowed on the App Store.
In order for Facebook to be the only authentication mechanism available, your app must include significant account-specific functionality from Facebook. Pulling profile information, or sharing are not sufficient account-based features for Facebook to be the only authentication mechanism available.
It would be appropriate to implement your own authentication mechanism, or implement significant account-specific functionality from Facebook."
My Question:
What are some examples of "significant account-specific functionality from Facebook"?
Would allowing users to choose pictures from their Facebook for their profile, or displaying mutual friends using my app pass this requirement?
*Note: I'm building a dating app kind of like Tinder
Thanks!
There is certainly a bit of gray area here. But the question you need to ask yourself is, "how can I make my app useful to users who can't login via Facebook?"
If the answer really is "I can't" then your app does indeed require Facebook authentication. It's not useful to anyone who does not have a Facebook account. A contrived example of this could be, for example, "Facebook Group Finder", an app that scans your interests on Facebook and suggests Facebook groups for you to join. If you don't have a Facebook account, then this app can be of no use to you.
Clearly, Apple however believes that your app does not fall into that category of apps. It has useful functionality that should not require a Facebook account to use. According to Apple's review notes, it sounds like your app just requires Facebook credentials so that a user can log in, and does not use any Facebook APIs or information from Facebook beyond that point (or perhaps, it uses them, but using them is not crucial to its operation).
If this is the case, it sounds like you could replace the Facebook account requirement with a requirement for the user to create an account on your website (or whatever) instead, and not really have any loss of functionality compared to a Facebook login. Apple is asking you to add that as a login alternative.
Allowing users to choose pictures from their Facebook profile definitely wouldn't satisfy Apple, since Facebook is not by far the world's only source of pictures. Displaying mutual friends, this probably also wouldn't do it, but it's more of a gray area. It seems like you could just leave the "mutual friends" part out of your app for non-Facebook users.
If you are going to use Facebook log in, apple wants you to use significant account-specific functionality. This means that you should use things from Facebook like user interest or friend list. Using the user name profile pictures are not considered account specific functionality. Apple is saying if you are not using these information then you are not supposed to use Facebook authentication. You have 2 solutions here:
Use the significant account-specific functionality from Facebook ex. interests of friend list.
Apple will accept the use Facebook log in without significant account-specific functionality if you also add your own login and password.
Tender app is using only Facebook log in and it is not rejected because tinder uses your friends list and interest from Facebook. If you can point to apple how you are using information like this they will accept your app.
I am sure of this information because I got it from apple review team member today!
Other authentication means, provide features that user can be able to sign up using his email id. What I understood from above is you have used only fb authentication.
I am using Twitter as an OAuth provider for ASP.NET MVC 4 web site. I would like to be able to follow up with a registered user at a later date, either by email or via a tweet. Outside of having the user follow me on Twitter, do I have any other options to communicate with the user?
Here is what I unsuccessfully considered:
It appears that there is no way to get access to the email address since Twitter OAuth API does not return it.
It appears I cannot send a direct message unless a user
follows me on Twitter.
"Read/Write/DirectMessage" permissions seem
too intrusive -- all I want to do is send a user a message that a
new product is released -- I don't need any of the write
capabilities that this level of permissions provides.
To recap, if a user used Twitter to sign in to my website, what are my options to contact that user at a later date?
Thanks.
Twitter's solution for this sort of person-to-person communication is the Direct Message, however, Twitter has (rightfully) decided that both parties need to consent to this channel being available. This decision is intended to reduce the amount of spam in the Twitter ecosystem.
Posting public tweets that mention the username will get your users' attention, but it is also broadcasting their relationship with your company to the entire Twitter ecosystem. You will, essentially, be advertising their relationship with your company without their permission. This approach will bring you headaches sooner or later.
Email is probably a better choice for the sort of announcement to existing customers.
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.