I'm building an alcohol prevention app and one of the features is to block the user's contacts for a given period of time so that they don't irresponsibly make drunken calls/texts to people.
The current (and very old) version implements it by letting the user select in-app which contacts to block. Then, it directly changes the selected contacts' phone numbers to an invalid one. That way, even if the user goes to the Phone or Messages app, the call or text won't be sent to the contact because the number is invalid.
I very strongly dislike this approach because it screws up with your address book which can be synced across multiple devices. What I have in mind is to:
Create a separate ABGroup or ABSource of contacts for my app
Copy all the contacts from other groups and sources into my app's group or source
Falsify all the contacts' phone numbers in my app's group or source
Disable all the other groups or source in the main Contacts app.
My question is: Is this possible? I looked into the ABSource and ABGroup references but can't find properties to disable them, but I'm hoping it's available somewhere in the SDK and that I'm just being blind.
If it's not possible, I'd be happy to hear any ideas for alternative implementations (iCloud backups, write original data into a file and screw up everything then put it back later, etc).
Related
At some point I noticed I’m seeing vcard coding or something to that effect and a bunch of my iPhone contacts. Please look at the example is there any way to fix this without having to go into each individual contact and delete the tags etc. it looks to be some type of V card code reference.
As you can see in the attached image for Apple headquarters, there is corrupted data. This is happening in a lot of my contacts I am seeing things such as X-SOCIALPROFILE at the end of phone numbers, etc..
I have another client that is experiencing the same issue (both with phone number and country name fields). I am posting something to the Apple forum hoping that someone there has an answer.
I think I figured out the issue.
Adding my work email, I had accidentally checked sync contacts. It is Microsoft based so it corrupted a bunch of my contacts trying to pull vCard data etc.
Also, Facebook messenger was corrupting my contacts
I disabled both of these syncing features, on my Mac went into contacts and searched for “x”
I found a lot of things like X-social etc appended to phone numbers etc
Based on this search in contacts I has to manually cleanup about 30 contacts. After about 1 hour my phone was synced to the updated iCloud contacts and everything is good.
Bottom line. Choose one source of truth to sync your contacts like iCloud.
Don’t allow 3rd party apps to access your contacts.
If you need anymore information let me know
I have a client who is requesting a feature that I'm not sure is possible as he describes it. He would like to send an invitation to one or more of his contacts via a text message, all from with in his stand alone app. That part would be fairly easy (I think). When the contact receives the text message containing the invitation and taps on it, one of two things happen:
1) if the recipient doesn't have the stand alone app on his device, he is directed to the App Store to download it. When the app is first run the user is added to the group that he was invited to. The app itself has UI that indicates that the user is a member of group .
2) If the user already had the app, he would simply be added to the group (if he accepts the invitation).I've looked into the Message and MessageUI frameworks. I'm not seeing a way to accomplish this task exactly. The text message would have to somehow contain data referencing the group info to be joined. And then actually configure the stand alone app with that group info - even if that means waiting for the app to be downloaded from the App Store first. Seems far fetched.
Does anyone have any pointers as to how this task may be accomplished?
We're trying to implement deferred deep linking in one of our iOS applications to encourage users to invite their friends to use the app, and reward users based on how many installs occur from their referral link. Basically similar to TapStream's product.
Consider this example:
So, UserA shares their link, “ourappURL.com/refer?id=userA”, on any
network they want. UserB clicks that link, which will take them to
Safari and then bounce them to the App Store page where UserB
downloads the app.
When UserB opens the app, the app checks which referral ID they came
in on (if any). In this example, the referral ID would be “userA” as
that’s the ID that was in the referral link. The app then sends this to
our servers and we award UserA with a referral credit.
I'm trying to break this issue down into its core parts. I believe the first part is getting the web page for the user's referral link to save the referral ID to the device somewhere that the app can access it. But I'm not sure this is possible because of the sandboxed nature of iOS.
I know this is fundamentally possible because many ad providers offer the ability to track installations from an ad campaign (see Mobile App Tracking for example).
We have also attempted to do this ourselves and I will try to break down the different steps here.
Going back to your example, you are correct about "remembering" the device identification, and all relevant data "id=userA". You are also correct about "sandboxed nature of iOS" which I presume it means a web page is not allowed to store information outside of the browser app (Safari) and apps (your app) are not able to access information stored by other apps (Safari).
Our solution to this is to store this device to data key-value pair in an environment that is both accessible by the browser as well as by your app, i.e. your backend server.
The next challenge, which remains to be the biggest challenge, is how to uniquely identify this device from the information collectable from the browser? Javascripts in browsers, unlike native apps, don't have access to IDFAs which could be used to uniquely identify a iOS device. To overcome this, one can imagine to use a combination of common information that is available both to the browser app as well to your native app, i.e. OS type, public IP, screen size, etc. etc. Please note, a composite key from these data fields does not guarantee uniqueness (imagine two iPhone 6 visiting this web page via the same router). Therefore, your backend server (assuming you are using it to store this key-value pair), will want to have a strategy on how to handle collisions on keys i.e. the second key deletes the first key, or you allow collision to exist by having a queue of values for a single key. This really depends on how you actual plan to use this technology.
The last step is to form this composite key on your app using the exact same fields you used earlier in the browser to perform a "lookup" on your backend server to retrieve the value previously stored.
Here is a summary of the steps:
User 1 invites User 2 by sending the following link to 2: example.com?inviter=1
User 2 visit Web Page P
P constructs and sends the following key-value pair to your server S iOS|55.55.55.55|750×1334 -> inviter_id=1
User 2 goes to the app store and downloads your App A
User 2 first launches A, A contacts S with the same key (assuming the IP hasn't changed).
S finds the value inviter_id=1 by using this key passed in and, let's say, reward User 1 five points for inviting 2.
Hope this help!
Edit 04/24:
Since Derrick mentioned it in the comments, I figure I would take this chance to finish our story here.
Going back to the beginning of my answer where I mentioned we've attempted to do this ourselves. We had a working prototype based on our current system architecture (which is not in anyway optimized, or meant to be optimized, for storing and analyzing deep link data like this), we ultimately decided not to allocate any additional engineering resource into this project.
Due to the heuristic nature of this matching process, we found this project needing debugging, tuning and optimizing constantly for a diminishing ROI. More importantly, we have found other companies which are more specialized and do a much better job than ourselves.
It has been probably 6 months since we stopped using our internal system and we haven't regretted making such decision.
During this processes, we've worked with a number of vendors, Appsflyer, Adjust, TapStream and we have ultimately ended up with Branch Metrics https://branch.io.
Whether you should DIY or work with another company again depends on your specific objective. We finally decided to stay with Branch, not only because the other vendors charged anywhere from $500 to thousands of dollars per month while Branch is completely free, but also the level of the support they have provided is simply unparalleled.
We've successfully used the clipboard (NSPasteboard) to achieve this: the web page that processes the redirect to the app store does a paste to the mobile device's clipboard before letting the user download the app. Once the app is installed, it uses NSPasteboard on first launch to check for an appropriately coded string. This string can contain the text of interest or, more securely, a token used to fetch interesting data from the backend. In Objective C:
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSString *pasteboardString = pasteboard.string;
The clipboard can be cleared once the app is done with it, to avoid repeating the same action.
There is a good solution here: http://blogs.innovationm.com/deferred-deep-linking-in-ios-with-universal-link/
Basic workflow:
User selects domain link on web.
Link sets referral ID to cookie.
User redirected to app store.
On app launch, load referral page in SFSafariViewController.
Referral page checks for cookie and if it exists calls a deeplink into the app with the referral ID.
My answer from HERE
Apple no longer supports Deep Links. It is now called Universal Links and works a bit differently.
Source
Now that Apple no longer supports URI schemes for deep linking, developers must implement Universal Links in order to deep link properly on iOS. If you are already using URI schemes, check out our blog on transitioning to Universal Links.
From: HERE
And HERE is another article on Universal Links and what they are.
Scenario:
I "control" two different apps, App A and App B, both which the user has installed
App A is running
App A needs to obtain a string that was set by App B when App B last ran.
After obtaining the string, App A will still be running
User should not receive any feedback this communication is happening. E.g. no "switching animations" between A or B, no pop-ups, etc.
Constraints:
Apps are released under different vendors
Apps are already in the app store; updated versions will have this communication ability.
It is acceptable for the data stored in App B to be accessible to other apps on the device.
It is not acceptable for the data stored in App B to be visible to general third parties (e.g. if an external server is used, there needs to be some sort of secured scheme)
The data read should be able to occur immediately upon App A being opened after install. For instance, I cannot require the user of App A to enter log in credentials for an external communication service.
Must work on non-jailbroken devices.
This is seeming rather difficult to pull off in iOS7. Help is appreciated.
Tricky work around. Not recommended, but it will get the job done if you can't afford servers.
On the first app create a contact in the user's contacts book. Give it a generic name like "000 - NameOfAppB Data - Don't Delete" (I start with "000" so it goes to the bottom of the users contact book so they never see it, I also add "don't delete" so if the user does somehow find it they don't delete it hahaha) (who looks at contact books anyways). In the contact info under notes add your NSData in string format.
Then when app A is opened search for that contact, read the data, then delete the contact.
Apple does allow you to create and delete users contacts without their permission. (At least in 2011 they did, this may have changed).
This might serve your purpose
https://developer.apple.com/library/ios/documentation/Security/Reference/keychainservices/Reference/reference.html
I am not sure of its limitations though, i have seen implementations where credentials have been shared between apps.
I have an app that is uniquely branded for each customer (think restaurants, etc.) I need to have the user be able to click on a link to my server that contains a unique code, stores that temporarily on the iOS device (cookie, etc.) and then directs them to the app store to download the app. Then when it is downloaded, the app grabs that cookie or temp. data on launch and brands the app for that customer. I know this is possible on Android, but is it on iOS?
Downloading the app first and then selecting the brand (or restaurant) is not feasible in this case, as the url wil be shared with other customers of the same business and we want to create a fluid experience, where they won't be able to "see behind the scenes" and choose a different branding.
Thanks
Edit
Thank you for all the replies. We've reevaluated and are considering having the url be opened on the device and grabbing the IP address or another unique id, and saving that along with the correct brand to a database. The app will then connect to the database on launch, and if the IP's match, will brand accordingly. We're looking for a more reliable identifier than IP, however. Now that UDID is deprecated, are there any other identifiers we can use?
I think the design you propose of a webserver link creating the code that needs to be read by the iOS app later is the issue. You should have a solution that is entirely app based. Perhaps you can have the same services on the website be available as one app which then sets up the code in pasteboard. The user then launches the actual app that looks at the pasteboard and skins itself accordingly.
That being said, data can be shared between apps from the same app seed ID by using UIPasteboard in addition to a few other ways.
I use the pasteboard to share info between apps quickly and easily using this class.
You can use identifierForVendor (UDID replacement) to identify individual devices. Are you planning on harvesting those identifiers prior to the end user "registering" the device at the final location? If not you'll never be able to determine which device belongs where.
What about having the end-user logging into your server as that restaurant? It can be a somewhat generic login per restaurant like "Wendys/Wendys5?" and "McDonalds/McDonalds7!" to determine their App Store URL. As long as the password is easy and non-programmatic to guess it would be unlikely they figure out how to register as a different restaurant. You could also do a simple restaurant selection screen coupled with a password specific to each chain but this would expose the user to which other restaurants are using the app. This way you won't have to continually add IPs if they expand locations and can revoke credentials if the login is compromised.
One question, though: Do all of your clients understand that they'll have to have an AppleID tied to each device? You can only shared a single AppleID across 20 devices.