World class mobile apps incorporate features and functionality that users have come to expect for their entire mobile experience. However, mobile environments face different challenges than the web. Network connectivity is unreliable, there are multiple sources of truth between user devices and the server, and the REST model wasn’t designed for pushing data. Overcoming these challenges is the key to creating more engaging user experiences, or rather a “reactive” app. This talk will explore reactive app trends and strategies for building your own. Develop an understanding of:

• How leading tech companies build reactive apps today
• Industry examples of how reactive features serve business goals
• Using API bridges to connect mobile apps to legacy enterprise data

Introduction (0:00)

I am a iOS developer by background and I founded my own mobile app company that had built a sales productivity tool that led me to joining Realm where we build a number of mobile tools for developers. I’m the director of product at Realm.

From our view and why we do what we do at Realm is that we see that mobile apps really are the future, there isn’t an internet and then mobile, really the internet is mobile at this point. It’s the predominant channel that users are going to and so our key mission is to really address that and make life easier for mobile app developers. But one of the interesting things about the mobile ecosystem is that unlike the web or desktop, it’s actually really competitive.

Competition in Mobile Apps / What is a Reactive App? (1:37)

This shows how many mobile apps have been able to reach a user install base that’s quite large. Compared to the other channels, there’s considerably less and so the take-away from that is that users are quite picky. A mobile app is a very personal device, users will pick and choose which apps they actually want on their device and on their home screen. And so from that, at Realm, we look at that and say, “Well, if it’s competitive, “that means you’ve really got be best in class “with your mobile app to stand out at this point.”

How do you drive or capture that user engagement? How do you get into one of those apps that users are comfortable with? Keeping on their phone or putting it on their home screen that they’re looking at every day. So the solution to that is what I like to call building a reactive app, and so what does that mean though? Basically, I break it down into three key traits.

• Immediate UI

The reason why the email app can be used constantly is because it has an outbox functionality. You can delete an email, create an email, you can do that and you’re never hindered by the network connection. Nothing is holding the user or the UI from updating. This creates a great user experience and it enables this constant use that email apps have.

• Ability to automatically synchronize across devices

Most users don’t just have a single device, they might have multiple phones, they might have a tablet, a phone, and they might also obviously be using desktop and web applications as well. A great user experience understands this reality and the data that the user is working with follows them wherever they are.

In Facebook, where now when you actually start typing, other devices that are also looking at that post are going to see a little notification saying someone is writing a comment and the reason they’re doing that is because they know that that’s going to drive more engagement.

Underneath this is technology to sync all that data from the different devices and enable that experience. Facebook is capable of doing that and they can deliver that on all their different channels. And that’s why they can have the user experience and engagement that they have. So that’s the second attribute that I would define a reactive app as.

• Push Notifications

Using push notifications is key to delivering this reactive experience. While users will open up their app and they might use it for a minute or two and then close the app, you don’t want that to be the end of the user engagement. Push notifications can create a repetitive pattern and so the best example of this is Uber or Lyft.

When you book your car, close your app and wait, that’s not the end of the user experience, you’re still waiting on the car to show up and they send you a push notification at the right time to tell you when to go outside. That’s key to delivering this reactive experience.

Challenges of Building a Reactive Mobile App (8:00)

Connectivity Issues

Some of the key challenges that arrive are that mobile networks are not entirely pervasive and they’re not very reliable. Even on LTE, even in San Francisco on my drive to work, there’s key dead spots, whenever I go over Van Ness here in the city. It doesn’t matter how fast that connection is, and taking that into account is quite difficult, especially when you want to synchronize data across devices or providing immediate UI.

Users have complete control over how the app is operating, or the operating system itself. An app can be shut down or restarted at any time. In addition, iOS and Android will close or shut down you apps at different times to try to preserve battery life. As an app developer, that’s another key piece that you have to take into account when developing the app.

REST

Other common practice today in terms of communicating the app with your back-end infrastructure or server is that, on the web, you would typically use different APIs, and while standards have evolved over time, the common standard today is having a REST API, as the way to provide that communication but when you try to transfer that over to mobile, you run into a number of problems.

That REST is actually quite brittle and cumbersome in a mobile world and so there’s a lot of error scenarios that can happen. What happens when you try to make a REST call and then suddenly you lose connectivity. What does the app need to do in response to that? What about if you’ve actually, if the app knows it sent the request, but then suddenly connectivity is lost before the reply can come back from the server. What happens then?

Lastly, REST is not designed for pushing data, there’s no ability to push a REST call out. What happens is the app has to do some sort of pulling or you have to use Apple’s push systems and also make a REST request in response to it. And so you end up with just a much more convoluted set-up to deliver some of these key attributes of a reactive app.

Solutions (12:09)

Our solution to this is that we think that it’s a lot easier to manage all this complexity if you have persistent shared state. If you’ve got the data on the device and also on the server, it makes it much easier to keep that in sync with each other.

We launched what’s called the Realm Platform which is a combination of two things. It’s a database that runs locally on the device that maintains the data that needs to be displayed by the user or the UI, and then there’s a server application that also has a copy of that same data and the two communicate between a real-time data sync channel. When changes happen locally on the device, they’re applied to the database and then sent to the server when network connectivity is available. And likewise, the server can make changes and push it.

So for example, you’ve got an eCommerce to allow users to make a purchase. With Realm, the way you would do this is you could create an object called a buy object and you would persist this on the mobile app locally and that will always complete because the database is running there on the device. Immediately after you make the purchase, assuming there is a network connection, that’ll be sent over to the server and that same buy object will be represented on the server. Now the server can react to that and do whatever it likes with it and so for this example, it could call out to the stripe API and actually try to go complete the order for the user.

The server system can then update that object and say it’s currently processing and that’ll be synchronized back, and the mobile app can then react to that change and update the UI, letting the user know that it’s processing. The key point is that intermixed at any point in time in this situation, the network can die. And so this sync that’s happening can stop. But that doesn’t actually break anything. The UI is still up to date with the data that’s on the mobile client and the server likewise knows where the state is as well.

The stripe call can actually return and you can update the buy object to say the order was completed. And then once the network has been re-established, that will then make its way back to the mobile device and the user and the UI can be updated and the user can know that the purchase has been completed. This makes it just a lot easier to not have to worry about all those error scenarios that happen when developing your mobile apps.

To note, the Realm Platform is that it’s not a Cloud service, this is actually a server application that can be integrated into any existing infrastructure and so you can think of it as almost like a mobile gateway or a bridge. It can be the conduit that transfers data between your client and whatever other back-end systems or APIs that you want to make more mobile-ready. So a little bit more about Realm.

Our company’s been around for five years. We got our start just building the mobile database so there’s thousands of apps today.

What we’ve recently launched is the Realm Object Server which is what enables the synchronization, and there’s a free trial that you can test out. All of our open source code is on GitHub.

How Do You Scale the Server System? (18:24)

We provide a number of capabilities to make that easier and so we have a horizontal scaling system where there’s a load balancer, and you can keep adding more object servers and so that makes it really easy so all the users that have Realm databases. You can shard those across all the servers to scale out as your user growth happens. We have a number of back-up systems to be able to continuously back up each of the servers to a replica and that, if it goes down, then you can replace the leader with the replica.

Would this mean you don’t need as many third-party SDKs in your app because you can send the request to them from the back end? (18:24)

Yes, we really think the mobile platform can be the data layer for your app, and as a result, if you’re using multiple different SDKs to transfer data, you can simplify that.

What are the best examples that you’ve seen of no-connectivity experiences?? (20:17)

One app that I use all the time is Expensify for travel expenses, and they use Realm on their app. Receipt scanning is something that you really need to have offline because you might want to do it on the airplane or when you’re traveling, so I use that as a great example of a user experience that really understands that offline is key and they use Realm to persist the data so when you scan a receipt, it goes to the Realm locally on the device and then it’s sent later on when you’ve got network connectivity.