Why break UX for iOS users by sending Android friendly SMS?

Shashank Agrawal
WizPanda
Published in
3 min readJun 2, 2019
https://pxhere.com/en/photo/723651

In late 2018, to provide a safe & secure experience to Android users, Google Play started requiring updates to existing Android apps with new policies and updated SMS & Call permissions.

With this change, Android apps which were using SMS read permission, now needed to use SMS Retriever API instead if they want to auto read some SMS like One Time Password (OTP) sent for different purpose like user verification.

This new mechanism prevented different Android apps by auto reading every SMS of the user by only allowing them to read SMS generated by authorized apps only. To auto read SMS on Android app, this change requires the SMS to be prefixed with <#> and end with 11-character hash string.

By mid-2019, almost every Android app has adopted this new SMS format. For example, to log in with a Google account on an Android app, Google sends the following SMS:

<#> Your Google verification code is 565163. This is valid for 30 minutes. Message ID: f6f01vO3FNp

Now, when Google app on Android can easily read this SMS and auto-populate this in the field so that user don’t have to type this in (for better user experience).

But what about iOS app or iOS user?

Well, iOS does not allow its app developer to read the SMS at all neither they understand this SMS format which is defined by Google for Android.

So even, you log in with a Google account on an iOS app, Google (and other apps) also sends a similar message to users which does not matter to iOS users at all.

Screenshot of my iOS message app

This is being done by many iOS apps which is kind of bad user experience. As an iOS user, why should I see the # & 11-digit string at the last which is of no use to me?

In my views & experience, I don’t think this is needed and not sure why these big giants have not thought of this (maybe I’m not thinking this from a different perspective).

We are also a mobile app developer and we take the UI & UX seriously. When we designed our first app which requires auto SMS reading, we handled this scenario at first hand. All we did is added a user-agent check in our server-side code which prevents prefixing & suffixing those parts in SMS string:

Our server-side code (written in Groovy) which sends the OTP to a user.

This covers all the scenarios:

  1. If OTP request is generated from Android app and the recipient SIM is in the same Android device, then auto read will work.
  2. If OTP request is generated from Android app but the recipient SIM is on an iOS device, then auto read feature is anyways of no use.
  3. If OTP request is generated from iOS app no matter recipient SIM is on Android or iOS, we don’t care because we are talking about Android’s auto SMS read.

If I’m missing something about any use case or do you have an idea why these big companies have not considered this simple check, feel free to leave a comment :)

Want to see your amazing idea in action? Or want to join us? Connect us at https://www.wizpanda.com/

--

--

Shashank Agrawal
WizPanda

Serial Entrepreneur | Founder / CTO @ Cooee® — AI-driven Personalised Notifications platform for Better Customer Engagement. bit.ly/shashanka