views:

393

answers:

5

I'm trying to glue information from a web page to an iPhone app that said web page suggests to download. I control both the web page and the downloadable app.

Scenario is like this:

User visits my web page, on which I recognize the user (he may have logged in, and I store his info in a cookie). I then present a link to him to an app in the App Store that he should download for "enhanced experience" of this web service of mine. Now, when the user launches the downloaded app on his iPhone, I like to re-identify the user who previously visited said web page.

All would be easy if an iPhone app could read Safari's cookies. But it can't.

A somewhat lame solution could be that the web server stores the visitor's IP address and uses that to recognize him once he launches the iPhone app. But that's not reliable.

Another one would be to give the user a token (code) that he needs to remember and then re-enter in the app. Still quite awkward, I think.

Any better suggestions?

+1  A: 

Simply put, you can't do this.

One thing you could consider is a custom URL scheme to launch the app. You could send the user an email that uses this custom link. However there's a couple of problems with this:

  • the user may not have the account that they used to register for your site set up on their iPhone. This might seem unlikely, but say the user signed up for your site 5 years ago with their Hotmail account and they have since switched to Gmail.

  • it's unlikely that the email would fit into their workflow. They would probably download the app and just launch it by touching the icon instead of clicking a link in a received email.

You could also put the custom URL as a link on your web page, but again, this won't fit into the workflow because they have to go to the App Store app to do the download.

Consider this - if you've got some sort of website that has an authentication step, it's probably a fair bet to say that the user is the type of person who already has an application such as Facebook installed on their iPhone. They are already used to the paradigm of having to enter their credentials into an application despite the fact that they may have already done it in Safari.

bpapa
+1  A: 

If you could read the unique iPhone device ID from javascript on your web page, you could look for that again when the application connected...

But I cannot find any means of reading this from Javascript in Mobile Safari, I thought I'd post in case there is a way now to give you another option to consider.

Kendall Helmstetter Gelner
Not a bad idea to use something that identifies the particular iPhone in some way. I'll see if there's something in that direction.
Thomas Tempelmann
Maybe some other resources of the iPhone can be inquired by the html/JS code, and then be used to generate a code. Such as using the first 10 contacts, or a checksum of a picture stored on the iPhone...
Thomas Tempelmann
Turns out there is really nothing that allows you to get any specifics about the iPhone from within the html code running in Mobile Safari.
Thomas Tempelmann
A: 

OK, we found a somewhat working solution: The html code can create a cookie. Later, when the app runs, it can't directly read that cookie, of course (due to the sandboxing of iPhone apps). However, it can connect to the server, then open a http URL pointing to the server and including a unique token that it has gotten from the server beforehand. This leads to launching Safari, accessing the server. The server can now read the aforementioned cookie and finally establish the connection with the help of the token.

Thomas Tempelmann
So the user has to launch your app, which launches safari, and then has to go back to your app? that doesn't sound like an experience preferable to entering a username/password directly in the app.
bpapa
Indeed I find my proposed technique preferrable because the user has not to remember anything such as his registered name+password. And my solution involves much less typing as well. Isn't that obvious?
Thomas Tempelmann
A: 

Just stumbled over this question and I'm curious if you thought about using a UIWebView. Where the question is - does UIWebView share cookies with safari?

If it does the rest should be easy.

ManniAT
Good question. I'll make a note for myself to investigate that
Thomas Tempelmann