UX: Cross-Platform Onboarding Without Signup Screens

… or how get more users through your onboarding funnel on Android, Web & other platforms by providing a mostly invisible signup.


One week ago, I released iOS Onboarding without Signup Screens on Medium. It described my idea of using the iOS user’s iCloud ID for a secure and invisible authentication across all iOS devices of a user with the purpose of getting rid of the need to enter an email and password during app onboarding.

The response was overwhelming.

The response to my article on Twitter and Medium was, and still is, overwhelming. The sheer volume and the very positive feedback surprised me a lot! I was surprised because for me using the iCloud ID token was a logical solution for my next app but it seemd not many other apps (any app at all?) did implement that before.

Nearly all readers who reached out to me found the idea more than compelling but many also asked:

How can I get rid of email signup forms on multi-platform?

The Requirements

If you agree that “Invisible Signup” via iCloud ID may be a good thing on iOS then how can you get a similar good user experience on other platforms like Android or the Web? What requirements would a solution need to fulfill?

Here is a list:

  1. No need for a user to expose his email during signup
  2. No need to enter a very often insecure password
  3. No signup screen wherever possible, aka “The Invisible Signup”
  4. If a signup screen is needed then make it easy to fill on a phone
  5. Provide Identification of a user across multiple platforms
  6. Not less but hopefully more security & privacy for the user

The Scenarios

The solution would need to work in the following scenarios (Android stands as example for all other platforms besides iOS):

  1. New signup first on iOS and later login on Android with same account
  2. New signup first on Android and later login on iOS with same account
  3. Already signed up with email on Android and now wants to use iOS version

The Solution

is an easy-to-type, temporary, secure, & discreet token. I named that token The Nine Pearls to be more visual, explanation follows soon.

Ok, but how does it work?

The Nine Pearls are displayed inside the existing, already authenticated app and are used to connect another device on another platform to that user account securely, without the need for the user’s email and in a very simple and easy-to-type way.


But let me explain the concept via above mentioned scenarios step-by-step. And please stay with me, we are going into details now.

Scenario: iOS First, Android Second

  1. The user signs up on iOS using the Invisible Signup via iCloud ID
  2. The user downloads the Android version of the app
  3. The user opens the Android app for the first time
  4. The Android app asks the user if he already uses the app on another device. Important: the Android app does not ask the user for an account but just asks a very gentle question which is easy to answer!
  5. If the user answers with “No” then the Android app implements its own version of the Invisible Signup. The easiest way of doing that is asking a server for a globally unique token or by hashing the current timestamp with a random string. The Android app stores that unique token in its internals. Please keep in mind: all that is done invisibly to the user, he is just magically “in”.
  6. If the user answered with “Yes” at step 4 then a very basic screen appears. The screen is called connection screen or bonding screen and should at all cost not be called signup screen!
    On that screen the Android app asks the user to enter the Nine Pearls which are maybe called “magic numbers” (or whatever engaging, non-threatening user-facing name you want to use for that) which is displayed in the app on his other device (the origin device).
    When the user enters the Nine Pearls then a request is sent to the server comparing them to the ones that the origin device did display to find the matching user account. If they match then the app gets the user account from the server and is automatically logged-in as the user on the origin device. Without entering an email or password.

The user has now connected iOS to Android and on both devices either used the Invisible Signup alone or a combination of Invisible Signup & Nine Pearls.

Scenario: Android First, iOS Second

  1. The user signs up on Android using the Invisible Signup (explained at ”iOS First, ...“, step 5)
  2. The user downloads the iOS version of the app
  3. The user opens the iOS app for the first time
  4. The iOS app asks the user if he already uses the app on another device in a gentle way.
  5. If the user answers with “No” then the iOS app uses the iCloud ID token method described at my article to identify the user across all iOS devices.
  6. Follow step 6 from scenario ”iOS First, …“ to initiate the Nine Pearls

The user has now connected Android to iOS and on both devices either used the Invisible Signup alone or a combination of Invisible Signup and Nine Pearls.

Last Scenario: Signed Up with Email on Android First, and iOS Second

  1. The user signed up on Android via email or any other authentication method which is not invisible
  2. The user downloads the iOS version of the app
  3. The Android app generates a unique token if not already existing
  4. Follow ”Android First, …“, step 4, 5 and 6

The user has now connected Android to iOS by using a combination of existing email and Nine Pearls. With every new device and new platform it gets easier for the user and step-by-step you can get rid of the origin’s email, too if wanted.


The Nine Pearls

Wow, that was a lot, thanks for being still with me!

I know that the different scenarios can be confusing but a whiteboard or pen and paper surely helped to understand the flow. The remaining article is less brain-twisting. It describes the Nine Pearls.


The Format

The Nine Pearls are a 9 digits, combined to globally unique token which is valid for a short period of time, like a minute for example. The Nine Pearls have their name from how they are displayed to the user: as 3 groups of 3 digits connected with two dashes in the user interface.

Hi, I am “452-572-141”, a Nine Pearls token.

Presenting digits in that way is not new but based on research and experience how humans read and memorize numbers in the most convenient way.

The appeal of that format lays in how easy it is to grasp these 3 numbers and much more importantly how little effort it takes to to type them on a phone.

Typing 9 digits on a phone is very easy to do.

Typing 9 digits which are not interrupted by letters is very easy and frictionless on a modern smartphone keyboard and the grouping of the 9 digit number into 3 groups separated by an existing dash makes visual copying by memorized typing a child’s play.

I also strongly advocate that the app shows an engaging visual progress indicator while entering the Nine Pearls so that the user feels good while copying these simple numbers from one device to the other.


How to Generate

The Nine Pearls are requested by the origin device from a server which generates, compares and stores the Nine Pearls numbers in the following way:

  1. The server generates a string of 9 characters. Each character is a random digit in the range of 0-9. The final string is a Nine Pearls number, leading zeros are allowed (“008123012”).
  2. The server tries to load that newly generated Nine Pearls number from his auto-expiring storage. If the number is not existing then it stores the Nine Pearls number together with the user ID which initiated the request. If it is already existing then it generates a new one.
  3. After a short period of time, like one minute, the storage automatically expires or deletes the Nine Pearls number. I suggest using Redis or Memcache for that because they are made for storing, retrieving and expiring short strings with a defined expiration time / time-to-live at very low resource costs.

Is it Secure?

I am not a cryptography expert but I would say that guessing 1 number out of 1 billion possible numbers is secure, especially since the whole 1 billion possibilities are reset after one minute and the search needs to start again.

And even if you have millions of users who want to connect your newly released Android app all at the same time at the same hour (which is very, very, very unlikely) then you still have many possibilities left. In worst case you can increase the length of the number to 12 but then it already gets a bit annoying for the user to type the number.

Against brute-force attacks to your server to find a valid number a lot of good solutions do exist like API request throtteling, IP banning, …, so that should not be an issue at all.

I would even go so far to say that the Nine Pearls are much more secure than email and password authentication because in the real world users tend to choose weak passwords, especially on smartphones because they are so hard to remember and to type. E-mails are easy to get for hackers and then it is just to find the weak password.

And Finally, is it Private?

Yes, absolutely because it can fully or at least partly replace a user’s email as unique identifier across multiple platforms.


If you liked what you read then please share, like or comment.

Thank you!