How We Made The World’s First Taxi App That Works Without The Internet
Smartphone penetration in India has seen a two-fold increase in the last three years. With smartphone users hitting the 650 million mark in 2016, this number is expected to increase exponentially in the next few years. Affordable and reliable access to the Internet, however, is still a problem that has not (yet!) been solved in India. This blog post describes how we tackled these problems for our app-first motorcycle taxi hailing service and came about to making the world’s first taxi-on-demand app that works without the internet.
1. The idea (and some stats)
Out of the 650 million smartphone users in India, only 312 million users have access to the internet, of which only around 103 million regularly subscribe to mobile internet. These users are mostly concentrated in cities, with several suburban and rural areas having little or no internet connectivity.
The inspiration for creating meaningful (and awesome!) solutions with the help of technology comes from observing and understanding real-world problems. Despite availability, reliable internet connectivity is still a problem even in urban areas. In the context of real-time apps, intermittent internet connectivity always leads to poor user experience. We at Baxi wanted to create an amazing experience for our customers — where an unreliable internet connection is not a deciding factor, and does not even come into the equation. So we decided to fall back to a more dependable, old school mode of communication — the SMS. Due to its widespread use, SMS has become very reliable, and it naturally became central to our idea of making a seamless UX on our app.
2. Considerations
Some of the main considerations while building an app which would entirely switch over to using SMS in case of poor data connectivity were -
2.1 Propagating our app
A potential customer who owns a smartphone but has no (or poor) access to the internet would, normally, not be able to log on to an app store to download our app. To get around this problem, we leveraged our physical resources well. Since our services can also be availed by walking up to our drivers at designated motorcycle taxi stands, our drivers were trained on using popular sharing apps like ShareIt and Xender to share app binaries with customers. They were also trained on helping customers install the app and on educating them on its usage in a no-internet scenario with a quick demo.
2.2 Using application flows smartly
To be able to use our services, customers need to be registered on our platform. Making an offline flow for our app is a straightforward problem for users who are already registered with us and have been using our app. However, for users who had never used our services before, there were some corners that needed to be cut.
SMS is usually chargeable to the customer on a per-message basis. This meant that we did not have the luxury of using up a new SMS for every screen of our app. This would potentially be problematic, since each message would inadvertently have some overhead information. For example, for new users, we would need to include data that we’d need for registering the user. For returning users, this would include the ride rating for the previous ride (if not already done online), along with a few other parameters.
2.3 Security through obscurity
The singular reason to create such an app was to solve a real problem faced by our customers — to make it easy for them to use our services, thus giving us a slight edge over other businesses in this segment. Though we acknowledged the fact that others would catch on to this idea eventually, we wanted to make it a teeny bit harder for them if they meant to do so by reverse engineering our app.
To protect our APIs (which are not public yet!) and to prevent competitors from reverse engineering our app, we decided to encrypt all outgoing messages from the app.
2.4 Reliably communicating updates from the server to mobile clients
Another important aspect of our app was handling inbound communication from the server and integrating it with the flows to give a good experience to the user. To communicate important events from the server to the mobile clients, the content inside the messages was kept to a minimum. This was sent via SMS on a high priority GSM channel usually reserved for sending OTPs.
2.5 User experience on the mobile app
All important server to client communication was sent over SMS. In order for the customer to have a seamless UX on the app, we needed the app to listen for incoming SMS sent from Baxi, parse it, and display it on the app to emulate the screens which a user would otherwise see while using the app with a reliable internet connection.
3. Implementation
Here comes the 'fun' (fun, at least in my humble opinion) tech part.
3.1 How the client builds the SMS
As I have mentioned earlier, the mobile client encrypts SMS that are sent to the server when a booking is requested in a no-internet context. For this, we’ve used a series of steps, the first of which is to build a delimited string. A simple delimited string is of the form
val1|val2|val3|val4|val5…|valN
This string contains important metadata about the client app, like the User Agent and the client app’s version. It also includes the customer’s location for pick up. For returning users, it includes some information collected at the end of the previous ride (rating for the trip, and whether the customer chose to add the driver to his favourites list — more on that later). For new users, it includes the information that we need to register a user, along with the referral code that was used for the signup.
This string is then encoded, encrypted and sent to a designated phone number via SMS. A popular asymmetric encryption algorithm is used to encrypt and compress the data. Many would argue that it is not a good idea to leave private keys on the app without a considerable amount of obfuscation. Though the amount of obfuscation is a subjective discussion (you can never be too sure!) — it worked fine for our use case. Private keys are used to i) Sign messages that are being encrypted, so that the server knows that no MitM has altered the message, and ii) Decrypt incoming messages encrypted by the server. Since, in our case, the messages were sent as plaintext, it wasn’t cause for too much alarm because there are other checks on the server which would catch spoofed messages and reject them.
3.2 Forwarding and authentication
On receiving the SMS on the designated phone number, an authenticated call to our REST API is made via a designated server.
Then, the message generated on the mobile app is passed on along with some more information like the customer’s phone number that was used to send the message, the carrier and the network circle. This is used in our fraud detection system and is also logged for analytics.
3.3 Handling incoming messages on the server
At the first point of contact, the core API system runs the incoming request through an authentication check, to verify the source of the API call. Any such API calls pertaining to SMS-based bookings which do not originate from the designated server are reported to our fraud detection system and rejected straight away.
3.4 Integration with the core booking system
Once a call is confirmed to have originated from the designated system, it is decrypted and parsed by the server. Based on this, the customer is identified. Using the identity and the location of the customer, the ride booking process is initiated on behalf of the customer.
4. Conclusion
Technology is awesome. Innovative ideas can pop up anytime. Having said that, if you can think it, you can do it! Difficult problems often have really simple solutions. After all, technology is just a reflection of human knowledge imparted into computers that are designed to follow instructions.
If you’re wondering about the results of our innovation — it went well. Really well. Our daily ride count went north by a noticeable amount in the weeks following our app release, with a significant share of the rides coming from our non-data requests. It also drew a lot of media attention. A few months on, healthy competition has caught up and a few other companies in this segment have, indeed, implemented similar SMS based taxi hailing systems. As is the norm, necessity continues to drive innovation.
Observe, be inspired, and innovate!
