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?
Related
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).
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.
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.
I am pretty new with iOS 5 and I am thinking in writing an app.
I would have a list of people inside the app who has it. Then I would invite them to an event.
I don't need any code right now I just wanted to know the concept behind this.
First, how an app can recognise who has my it installed, so it can show a list of people.
Second, after creating an event with a group of people how can I send an invitation to them.
Thanks
From a very general standpoint, what you need is a back-end server to interact with your app and store user/event info. You can either build your own or try to use a service like Parse.
I'm developing my first iOS app and I'm facing a challenge.
I'd like to present new users a personalized screen when the app starts at the first time. Let me explain more.
The flow should be more or less like this:
My app isn't installed on the user's device.
Then the user gets an SMS on his iPhone with a short message and a link to install my app. The message is part of a conversation. Another user of this app had sent this message (through my backend) in order to join this user to the conversation.
This install URL doesn't necesarrily link directly to the itunes store, it can link to a conversations specific link such as myapp.com/conv/12345
The page at myapp.com/conv/* will detect the device and if it's an iPhone would redirect the user to the appstore to install myapp.
The user then installs myapp and launches it.
Now I'd like to present the same conversation 12345 to the user, before he even needs to login, register or what have you. That's the difficult part... I don't want the user to start an a blank page, I'd like to take it right to the conversation 12345 page.
I assume steps 1-5 are easy, but I can't think of a way to implement 6. I admit that I'm not familiar enough with the intrinsic of the appstore but as far as my understanding goes, "all apps are made equal", I mean the app itself when it gets installed it has no context, it doesn't know what "caused" it to be installed, it isn't aware of the click on myapp.com/conv/12345. Is this correct?
If there was a way for an app to know something like a referrer URL for the instllation or something along these lines that would be awesome.
If there was a way for app to query the device for its phone number
then I could make this work (b/c the SMS was sent to a specific phone
number, so I can track the most recent conversation sent to this
number on my backend). But since apps are sandboxed, accessing the phone
number is off limit.
Well, I suppose I could ask the user to type a unique code from the SMS when the
app starts, say 12345 and then I'd be able to display the
conversation to him. But that's problematic in two ways, first,
security - the user can join a conversation not meant
for him, and second, that's less than optimal
user experience, I want this to work like magic, I don't want to make
users memorize and type strings into my app the first time they
install, I'm sure they won't appreciate it... (they could
copy-paste, but still...)
Another option is asking the user to type his phone number. But that
again has a few drawbacks, one is that again it's less than optimal
UX, I'm asking a user to type his phone number to an app he doesn't
yet know or trust, second I'll need to verify (authenticate) the
phone number, I mean what prevents that user from typing a phone
number that doesn't belong to him?
If I had access to the SMSs then I could dig up that code, but I find
it hard to believe that apps get access to SMSs, it's just sounds
like another reasonable sandbox restriction. Of course I'm not
speaking of jailbroken devices.
BTW, if the user just went over to the appstore to install my app (and didn't go through a conversation SMS) that's fine, in this case I'll just present a normal register/login page. The interesting case is where the user was already part of the conversation when receiving the SMS and now I want him to (effortlessly) become part of the same conversation through my app.
To sum up - is there a trick to present "personalized" pages the first time an app is installed and launched that would get that user right into the context of the conversation sent to him over SMS without having to request additional input?
Thanks!
It's impossible to do. Your application is installed without the knowledge you need whatsoever. As you pointed out, it's a reasonable sandboxing restriction.
What you could do is a challenge-response based system, but it would be about as intrusive to the user as is registering/login in.
Ran, you can keep a flag in NSUserDefaults (equivalent to Android's SharedPreferences)
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html