2

I'm developing an app for iOS and Android that i want users to be able to launch when they receive a SMS message that contains a link.

The link includes the app package as well as encrypted data in the following format:

"com.app.myapp://?<encrypted data>" (the <> brackets are not included and the encrypted data is never over 120 characters)

On iOS, this works perfectly as the SMS link comes in correctly hyperlinked to include all of the encrypted data, the app launches and all is well.

Android on the other hand, the link comes in broken...only the "com.app.myapp" is hyperlinked, which still launches the app when clicked, but it does not pass the encrypted data. So it seems like Android is breaking the link.

One fix i had for android was to add "http://" to the beginning of the link, this kept the hyperlink fully intact in Android, but on iOS the link with http would no longer launch the app. Also removing the ':' after the package name fixed it for Android, but again broke the iOS functionality.

I know its not an app issue, its more a Android Messages issue / possibly a link formatting issue. Is there another solution i can try?

RH201
  • 312
  • 3
  • 16
  • You can use deep links or unviersal links: https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html – MichaelV Apr 12 '18 at 13:30
  • Thanks, but there is no website associated to my app and this doesnt look like it supports Android. The messages need to come through SMS and work for both OS' – RH201 Apr 17 '18 at 23:03
  • Is it because you have no base path in your uri? Have you tried `myapp://load_data?`? – wottle Apr 18 '18 at 17:16
  • Adding 'load_data' doesnt appear to make any difference, the link is still not clickable in the SMS message which is an absolute must – RH201 Apr 18 '18 at 19:43

1 Answers1

1

You cannot add http:// in front of com.app.myapp:// because they are both uri schemes. You should familiarize yourself with the difference between URI Schemes and App Links. Since you are using URI schemes to accomplish this, you should not be using .. Your URI scheme should look something like myapp:// not com.app.myapp://. This is probably why Android Messenger is ignoring everything after the ://.

An easier solution would be to use Branch SDK and pass along the encrypted data in the link data.

EDIT

Android messenger does not recognize raw URI schemes as clickable links. You probably still need to use http for android. You should look into using Android app links and iOS universal links. These take a bit more set up but should handle links in both cases

clayjones94
  • 2,648
  • 17
  • 26
  • Thanks, Branch SDK looks like an option, but before pursuing that... when using "myapp://" the link in Android Messenger still is not a clickable link, so not sure what that format would work for but doesnt work for Android – RH201 Apr 17 '18 at 22:53
  • Ahh yes Android messenger does not like URI schemes. I've just added an update to my response :). I know you don't have a website, so Branch luckily will host a 'Text-me-the-app' page for you on the link domain they create for you – clayjones94 Apr 18 '18 at 15:51
  • Thanks again for the update and links. Before i go too far, if i go with the App Links and Universal Links route, would I need 2 seperate links (One for Android and one for iOS as Android would need 'http' and iOS will not work with it included?) I wont know what device the user has when the messages are sent, and sending 2 links may cause an issue as the message will be too long so thats why i ask – RH201 Apr 18 '18 at 19:42
  • App links and Universal links both correspond to an `http` web link, so you will just need one link. Since you don't have a website, you could just get a web link and have it redirect to the correct app store based on user agent if the app is not installed. – clayjones94 Apr 18 '18 at 19:50
  • Just to update on this, we decided to go with Branch, for now, as a solution to this problem. It's easily integrated into our backend processes, we can dynamically create the links we need, and the cherry is that the links work correctly on both iOS and Android. Thanks for the suggestions – RH201 May 07 '18 at 18:22