Invite person from contacts who doesn't have app? - ios

I want to let users of my iPhone app invite people from their contacts to a group they're creating. I can use deeplinks for people that already have the app installed to have an invitation automatically show up, but I was wondering if I can somehow pass custom information to someone downloading the app for the first time so after they initially open the app they'll have an invite waiting.
As far as I can tell this is impossible but I was wondering if there's any other way to somehow associate a contact with that person making an account on their own device. My application uses gmail authentication for account creation so if everybody had each other's gmails saved in their contact this might be possible, but that's not the case unfortunately. If I could get a user's phone number then it would be easy but I know that's not allowed without specifically asking the user.
Does anybody know if it's possible to do something like deeplinking for people installing the app for the first time?

You can do this with Google Firebase Dynamic Links. Google has a guide for this here:
https://firebase.google.com/docs/dynamic-links/

If I understand the question correctly, here is what I'd do:
Scenario: Send Invite
If the email invited by a user is a registered email, done.
If the email invited by user is not a registered email, store it in a separate table (pending invites)
Scenario: Sign up/ Sign in
User registers using email, store user information.
When the user logs in, check if email exists in pending invites table, if exists, present invitation.
Delete user from pending invites table
Not sure if you have it already but you might need a db table to keep the invitations sent by your users.

What you're describing is called Deferred Deep Linking (Deep Linking refers to using a link to open your app directly to a specific piece of content, and Deferred means that it works even if the app isn't installed first).
As you noted, there's no native way to accomplish this on either iOS or Android. URL schemes don't work, because they always fail with an error if the app isn't installed. Apple's newer Universal Links in iOS 9+ get closer in that they at least don't trigger an error if the app isn't installed, but you'd still have to handle redirecting the user from your website to the App Store. You can't pass context through to the app after install with Universal Links, so you wouldn't be able to present the invitation. Additionally. Universal Links actually aren't supported in a lot of places.
To make this work, you need a remote server to close the loop. You can build this yourself, but you really shouldn't for a lot of reasons (not the least of which being you have more important things to do). Free services like Branch.io (full disclosure: Branch is so awesome I work there) and Firebase Dynamic Links are designed to solve exactly this requirement, and can handle all of the backend infrastructure for deferred deep linking so you don't have to. From your perspective, as the developer, you'll seamlessly get exactly the same data to work with whether or not the app was installed when the link was clicked.

Related

App rejected because asking user registration (Guideline 5.1.1)

My app is a catalog of ebook-like content. Some of which are free to read, and some other are paid. I need to ask for user email / password to be able to retain the information of which content was successfuly completed, or until which chapter it was completed so the user can have his information synced accross all platforms.
However I got this rejection message :
Apps cannot require user registration prior to allowing access to app
content and features that are not associated specifically to the user.
Next Steps
User registration that requires the sharing of personal information
must be optional or tied to account-specific functionality.
To resolve this issue, please make it clear to the user that
registering will enable them to access the content from any of their
iOS devices and provide them a way to register at any time, if they
wish to later extend access to additional iOS devices.
Please note that although guideline 3.1.2 of the App Store Review
Guidelines requires an app 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.
Please resolve 5.1.1 issue and resubmit your revised binary to iTunes
Connect.
I am very surprised as I know apps such as Feedly which do not allow you to subscribe to RSS feed unless you create an account.
How should I get this problem solved ?
I have faced the similar rejection. As per the guide lines app is not supposed to force registration. So I ended up adding a skip button on the registration page. You need to add some content that users can view without registration. For example a user can preview a FREE book (maybe first page only) but can't read the full book without registration.
You can keep asking user for registration later when user is browsing the content.
There are some apps with forced registration and are available in AppStore like WhatsApp. But you need very strong arguments to convince Apple review team to consider and it's only possible if your app is really can't work without registration. In your case I don't think that's true.
For registration and login, your app must Serve contents/data user wise. e.g. Specific user settings, profile or follow topics etc. If your app does such things then Apple wont have any problems for your login or registration.
This is because of some apps have Registrations just to collect the email addresses of users.
If i will add "Guide" screen, then this issue will be resolved or not!

How to implement user suspend feature in iOS

In an iOS application, When I detect a users improper action (for example posting violent content), I wan't to suspend the user from using my application. The basic idea to implement this feature is to create and save an unique id for each application installs and suspend the usage from server api's.
My question is, how can I implement this feature even if the user re-installs the application, and still pass the Apple's iTunes submission?
I came up with two ways to technically implement this feature, but wondering how Apple would respond.
Store the IDFA (I understand that users can reset the id on their behalf)
Store an app generated udid to the Keychain (which should not be deleted even if the user deletes the app)
I know there are no perfect answers, but would appreciate to discuss this issue with anyone that have tried submitting a similar application, or anyone that is well aware of the Apple's guidelines. Thank you.
Apple will reject apps that inappropriately use the IDFA.
If your app does not use server login (at which point, whatever flags you require could be delivered to the client), keychain storage would be the only real solution.
However, if you don't use server login, you block the device, not the user. Is this your intent?
BTW, without server login, a determined user can still get around keychain storage: Reset keychain on the device
You can block a given account. Most people these days key an account with an email address. Some require a credit card (Facebook fully validates accounts using credit card numbers), others require a bank account (PayPal has to send money somewhere!) and it is growing in popularity to request a phone number (Twitter is getting there). In the end, to really be effective, you have to block something that is difficult to produce.
With email, your users can always create a new account. Check out mailinator.com. Alternatively, all you need is one domain to have as many email addresses as you want -- I use five different email accounts daily, and I use about two dozen more on a monthly basis.
Installation ids are ok but users can always just uninstall/reinstall. And if you do manage to get a device-identifying number (easy to do really, even in the post-UDID era) so that you can block a given device, your users can just get a new device, or hack your app to use some random value, or spoof your API with cURL. I own three iPhones, two iPads, two Samsung tabs, three other Android phones, two Mac Book Pros, a mini, two PCs, and I run three virtual Linux boxes, and one virtual XP box. And what happens when somebody sells a blocked device to a non-abusive user?
So just block the user's account, keep excellent log files, and keep fighting the good fight.

Free iOS in app purchase for some users/devices

I would like to build a mechanism to free my in-app purchases for some of my VIP users devices. My idea is I pre-save the UDID of the user devices in my backend server. When the app starts, it will call my server and get the list of udid and check if the device is in VIP list. if yes, directly show full features without any button to ask for in-app purchase.
However, UDID cannot be used anymore. What should I do in this case? I dont want to ask user to enter some codes. because it would disturb my user interface.
new updates of the question:
The purpose is that , I got a list of people that they will review my apps , but i dont want to have any pop up to ask for promo code or any specific UI for these people. So my idea is I ask them to give me their UDID (or whatever number that they can identify themselves for their phone), and I save them in my backend. When they download the app, the app call the backend and compare their identifier number/UDID, see if they are my VIP, and give them full features automatically without asking promo code and any UI specific for these user.
I would like to identify the user only. Do you guys have any solutions?
thanks
You could do something like provide a URL to the users which opens the app and gives the app some parameter(s). When the app receives these details it could show an alert to ask for a name or some other info (like an e-mail address) from the user. Then you can send the details to your server for verification and set some value in the app to enable the features. In this way the UI of the app is not changed.
I think it's not conform with the iOS/App Store TOS (to be clear).
The easy way is to use the UDID but we can't now... You can get another unique "number" for identifying the device like the Mac Address (you can get in in Objective-C, not really simple but you can).
You can add a button which asks for a promo code (maybe the same button to buy the in-app upgrade). Only those who have a promo code can get the upgrade for free.
Also, should it be "VIP users" rather than "VIP user devices"?

How to invite all facebook friends from ios or android app after ios sdk 3.2

I'm trying to find a best way to send invitation to facebook friends from iOS App.
In the recent api release, I found facebook is restricted the invite policy.
After searching around, I summarize my finding here:
Feed (Graph API user/feed) is used to post message on user's own wall, then friends could seen from their own portal if the feed has mention the friends.
Pro: message could be customized and including pictures etc.
Con: mention 10 people max, also need user interaction in app.
If user just post a message in their own wall, only friends comes to his page could see it, but not possible for notifying friends.
Request (Graph API user/apprequests) is used to send an request directly to friends, there are two kinds of request: User to User and App to User
User to User request scenarios (I'm interested in the first scenario)
The recipient is a friend of the sender and has not installed the app. This is considered an Invite.
Pro: Seems the proper way of invite, friends will receive notification and popup.
Con: Includes maximum 50 friends, and also need user interaction.
The recipient is a friend of the sender and has installed the app.
The recipient has installed the app. In this case the sender and recipient do not need to be friends.
App to User Request: friends will receive a message from the app, but the message is only sent to user who already has the app installed, so this is not useful to me.
So it seems my best shot is to use User to User request. So my app could provide user a list of 50 and ask him/her to confirm sending in the facebook webdialog. But what if user want to request to all their friends, sometimes 500+. Seems facebook is tighten this up to promote their Mobile App Install Ads, or App Center. Ads is another topic. I already have the App Center setup, but how should I let user's friends know about this?
I've been searching for three days, but couldn't get a ideal solution. Folks, suggestions or solution? Thanks in advance!
I've been looking into ways to do this myself and my strong suspicion is that Facebook are trying to discourage / deprecate this feature.
They haven't yet updated the 'Requests' system into their new API (you have to include the old headers to do it), despite pretty much all other features being ported over to the new system.
As you mention, they now have mobile app install ads which they're quite keen to push
And finally, Open Graph: personally, whilst as a developer I'd love to give people the option for people in my app to invite their friends over Facebook, as a user I can see why this would be annoying.
There's a large potential for these requests to be spammy if sent to many users at a time, and also they're quite unnatural, they go against the idea of OG which is that, your friends actions are fluidly put onto their wall where you can see it and choose to investigate / install the app yourself if it sounds interesting.
i.e. the idea now is that app promotion on Facebook is done more naturally and encouraged by usage rather than explicitly forcing requests

Iphone - clarification on app rejection guidelines

I have a website which offers (FREE) account based services. Iam working on a iphone app for the site. Can somebody help me with these questions?
1) Registration: In my case, the app is meaningless without an account/registration (all free). There is a lot of chatter in the internet that apps that do not offer a "registration-free" experience will be rejected. (example : http://readitlaterlist.com/blog/2010/08/version-2-2-rejected-new-rejection-reason-from-apple-may-have-major-implications/) Thoughts?
2) Email Verification: On my website, a user has to "Verify his email" before he can login.
Basically, can I do this one time only thing in my app: (a) ask email -> register (b) ask user to copy verification token in email & paste in the app (c) Hit verify & let them inside the app upon success. Is this alright?
3) Is it against Apple's rules if the iphone app only supports existing users(who already signed up via website & have a user name password)? This way I need not worry about 1 & 2 for now & still have a full fledged app.
Please note that I have read the guidelines but still cannot come to a conclusion.
I am aware that "will Apple reject my app" - is a question nobody can answer
All I am looking for is your opinion based on your prior experiance & your interpretation of guidelines. Thanks much.
UPDATE: To all users who land here: Apple approved my app few weeks ago. All I did is explain(in review notes) that my app is truly account based & would be meaningless without an email. On my home screen, I have 2 buttons, "I have an account" & "Create an account". There is no registration free experience other than a series of graphics focused on "what is " & indirectly emphasizes that it is an account based appln. Apple seem to be convinced & approved the app the first go. Hope it helps.
I made an app that sounds very similar to yours. I host some websites that are basically forums (they require registration). So my app is an app that allows the user (once they have logged in) to read, post, edit profile etc. Without logging in they get nothing, they see a login screen/Signup button. Which takes them to a form to sign up, it then sends out an email and they approve it via the link it then allows them to login. So as you pointed out No one can really tell you if your app will be rejected or by apple, but my app was very similar to yours and made it through just fine. Also think about a service like Spotify, gmail, or facebook. They require the user to login/register before the app works at all. I believe these rejections dont come from the fact that they are requiring users to login, but they are making it difficult for them to login in or they did not have a website that this was tied to, they just want the user to login to use the app. Its a very fine line, and again apple will be the judge of this in the end.
*Apple very well could have changed this since I submitted my app, but this is just my experience.
In general this sounds fine. The most important piece of advice I can give you is to make sure that you create an account for the reviewers to use - use the 'review notes' box to give them a login and password so they can type it straight into the app. You'll probably get rejected if you don't do this (reviewers dont' have time to check out your site, sign up, wait for the email, click .. etc).
EDIT: Also you should ensure there's a link to the registration page on the web from the front-page of your app (or at least somewhere very obvious).
If your submitted iOS app requires email verification from within the app for the app to function, this sounds it could very likely be a strong reason for a rejection by Apple (apps are not allowed to require personal identifying information.)
If your app requires a pre-existing login/password, and you give Apple a pre-existing fully functional working login for review purposes, what any user has to do to get this login outside and before running your app may be outside Apple's purview (for instance, joining some club or professional organization, opening a bank account, etc.).
But the only way to know for sure is to submit an app for review by Apple.
Our empirical knowledge is that we had submitted a fully featured app with more then one reasen to get rejected. One of them was, of course, that we enclose a way to get balnce in the app without using the IAP (https://developer.apple.com/in-app-purchase/) from apple. That thing was a killer. I think, because of this feature, the reviewers told us even more reasons to get rejected. One was the signup button in the login screen. After we disabled the topup and the signup feature, the review was fine and we're happy and online. Since that rejection, over a year ago, we had never tried to enable signup and upload it again. Now, we'll do that and I will report here what is happaning...
Update #Ravi Jul 31 at 16:18
It's like what I said! We're now online with a singup button at the start screen of the app. Apple does not disallow it. FYI

Resources