In my app, I need to check address book and if ;
a person from address book is installed my app, user will be able to send a friend request,
a person from address book is not installed my app, user will be able to send an sms to relevant person to install the app.
This is actually same as Snapchat. So, what is the proper way to implement it ?
For instance, should I get phone number of the installer and record it to Users table in database ? Then when another user install the app, check all address book against Users table in DB and mark them application installed or not !
Maybe, there is an easy way to do it. So, please help me and provide some sample code for it.
Looks like you can use
CloudKit for the first question part:
discoverAllContactUserInfosWithCompletionHandler
https://developer.apple.com/library/ios/documentation/CloudKit/Reference/CKContainer_class/#//apple_ref/occ/instm/CKContainer/discoverAllContactUserInfosWithCompletionHandler:
You can get users that are also use your app.
For the second part, you can just use Address Book api I think to get all persons in the AB without your app.
https://developer.apple.com/library/ios/documentation/ContactData/Conceptual/AddressBookProgrammingGuideforiPhone/Introduction.html
Address Book is deprecated (or will be), so take a look at this WWDC 2015 video Contacts framework: https://developer.apple.com/videos/play/wwdc2015-223/
Related
Is there a way to find Favorite contacts from the iOS Address Book API? I'm referring to the contacts a user places in his Favorites tab in the Contacts app.
Favorites are stored inside Phone.app, not inside the Address Book database itself. You can't access other app's sandbox on a non-jailbroken iPhone, so unfortunately the answer is no.
Also, it would be pretty bad for privacy if any app could see your favorite contacts. It's already bad that it can access entire address book without asking you.
Filip is correct, you cannot access the list of favorite contacts on iOS via a public, app-store legal API.
To come close you could try to guess a user's favorite or most important contacts from their address book. Let's assume that people know most about the people they are closest to and that this is also reflected by their phone's address book:
For example, the address book contact for a close friend contains more
information (address, birthday, maybe a nickname) than a contact for a
business associate or a colleague at work.
We could then use this information to compute an importance score for each address book contact. By taking the n most important contacts we could approximate a user's favorite contacts.
I've written about this idea some more on my blog: http://dbader.org/blog/guessing-favorite-contacts-ios You can also find a sample implementation and a demo application there.
I have searched through the API and could not find any appropriate methods. Maybe Apple believes that this is a Phone-app data field or maybe it is about security. I'd love to use it, too.
Since apple doesn't allow apps to directly call service methods using NSURL, I have a contact saved into the users addressbook which can call a service number.
However, if I open the contact (using ABUnknownPersonViewController) I cannot call the service number.
My question: Is there some way I can switch to the address book app and show a contact there? I don't want to tell the user "Open your adress book and search for contact X".
To reply to your question:
No, there is no way to open separately the contact address book.
However:
You can simply take that number programmatically and use it as you want (also call).
Is there a way through addressbookUi framework to get only the contacts who own an iDevice? The check for example is done in the messages app for iMessage. But is this available for developers? Or is there another way to check for this? Thank you in advance..
You could check, for each address book record, if there is a phone number of type "iPhone" (represented by the constant kABPersonPhoneIPhoneLabel). There's really no way of knowing for sure which of the contacts "owns an iDevice" anyway, but if there is an iPhone number for them in the address book record, then there's a good chance of them using an iPhone. Of course, it's another story altogether how that information got in your address book, and whether it is reliable.
No there isn't... The SMS app would be checking with apples servers to see if the phone number is registered with iMessage or not.
This is not a publicly accessible API.
I guess you could hash then send the users number to your own remote database and then compare contact numbers in another users address book against your database to see if they are users of your app... It's not really what you asked to do but it's the closest solution I could think up
After registration, our app prompts users to invite her friends (aka phone contacts) to use the app too. This allows us to send an email/sms to the useer's contacts with some sort of invitation key. Works fine for a web version app, just embed the key in the url you provide in the invitation.
I'm having trouble figuring out how to make this work smoothly with IOS only. It would be brilliant if I could send the invitee a link to appstore.apple.com/myapp?registrationKey=abcXYZ and have the key magically available to my app once it's installed, but I guess this is a lot to hope for?
The obvious way around this is to make the user manually enter their registration key on first launch, but this seems less reliable and (to my mind) adds friction to the UX.
Has anybody come up with something clever to get around this?
Here is what is flowing through my brain on how to solve this solution, please note, I have not vetted, psudeo-coded, coded, or applied this theory.
Since you will know who is being sent an invitation, save that data to your database with a relationship to the user sending and a unique id to the user being invited (email address if its in the contact's card). When new users sign up scan the database for invitations, if one is found present it to the user asking We're you referred by <existing user>? Once the new user selects their response continue through the registration process, updating the relationship table accordingly and applying any extra settings you need to for the referral.
This combines automatic referral tracking with referral codes for a basic, straight-forward, almost (but not quite) fool proof method to make sure referrals are linked to the right users.
As far as I can tell, the App Store provides an information firewall between an invitation and the installed app.
The closest workaround I've seen is the following:
email link sends you to your website
the website logs reference information in the URL and the IP address
the website instantly redirects you to the App Store (if iOS detected)
user installs the app
user loads the app
app contacts your website, IP addresses matched ... BINGO
Obviously not a secure method though.
There are many failure cases:
business networks commonly share IPs
home and mobile networks release and reuse IPs
The more is frequently used to resolve cases where its good enough to know that the user 'almost-certainly' was referred to download app by the email.
For example, it can be a good mechanism to prompt the user with a "who do you know" question in an app and limit the options based on the (IP+reference) data. If they pick the original poster, then maybe that's good enough, and then you can attach any other data that the inviter provided.
(Full disclosure, currently work at Branch)
The best solution to this is to fingerprint a user. This requires you to do the following steps:
For each user, using your own domain, generate a link for said user. So, right when they complete registration, generate their unique URL, that contains the invitation key.
For anyone clicking this link, they will redirect to Safari first. When they do, capture their IP address and iOS operating system version from the headers and user-agent.
Save this data on your server, and set window.location to your iTunes url.
If the user downloads and consequently opens, inside AppDelegate.m, send a message to your server with the IP address + major/minor/min version you collect upon app launch. If it matches with what you have on the server, you can now pass that invitation key back to the new user.
It's not perfect, and has the ability to misattribute. You could also use branch.io, where all of this is taken care of (link-generation, fingerprinting a user, attribution). Branch also drops a first party cookie and ties it with the device level ID, so attributions are much more accurate.
Is there a way to find Favorite contacts from the iOS Address Book API? I'm referring to the contacts a user places in his Favorites tab in the Contacts app.
Favorites are stored inside Phone.app, not inside the Address Book database itself. You can't access other app's sandbox on a non-jailbroken iPhone, so unfortunately the answer is no.
Also, it would be pretty bad for privacy if any app could see your favorite contacts. It's already bad that it can access entire address book without asking you.
Filip is correct, you cannot access the list of favorite contacts on iOS via a public, app-store legal API.
To come close you could try to guess a user's favorite or most important contacts from their address book. Let's assume that people know most about the people they are closest to and that this is also reflected by their phone's address book:
For example, the address book contact for a close friend contains more
information (address, birthday, maybe a nickname) than a contact for a
business associate or a colleague at work.
We could then use this information to compute an importance score for each address book contact. By taking the n most important contacts we could approximate a user's favorite contacts.
I've written about this idea some more on my blog: http://dbader.org/blog/guessing-favorite-contacts-ios You can also find a sample implementation and a demo application there.
I have searched through the API and could not find any appropriate methods. Maybe Apple believes that this is a Phone-app data field or maybe it is about security. I'd love to use it, too.