A while ago we talked about five surprising browser APIs that can enrich web experiences in ways that were simply unimaginable before: Payment Request, Device Orientation, Gamepad, Shape Detection and Web Bluetooth. Even before that, Sam Bellen had covered another five interesting APIs in a previous article.

In 2019, smartphones became the most used type of device to access the web worldwide. So this time around, we’re going to be focusing on five web APIs that are particularly or exclusively relevant to mobile devices. These APIs help close the gap between web and native apps, and allow web developers to build experiences that are better integrated with users’ devices.

Battery Status

We’ll start our list with a not very flashy but nonetheless interesting API. If there’s one thing that smartphone owners worry about day in and day out, it’s battery life. Thanks to the Battery Status API, we can get information about the battery of the device our website is running on, and tweak its behavior accordingly. Maybe that resource-intensive process can wait for later if the user is running out of battery, or those complex animations can be turned off.

This API is pretty simple to use. We need to call the getBattery method on the navigator object, which returns a promise that resolves to an object with all the battery information:

Besides charging status and level, the battery object also contains information about charging and discharging times in the chargingtime and dischargingtime attributes. However, those are not very reliable, as browsers tend to return values like 0 or Infinity, in part for security and privacy reasons. We’ll go back to this in a second.

The previous code allows us to retrieve battery status only once, whenever we execute it, but chances are we want to respond to changes in that information. Thankfully, we have events we can listen to in order to do just that:

Browser support for the Battery Status API is unfortunately not great, with only Chrome and Chromium-based browsers implementing it. This API has in fact a very uncertain future: it was part of Firefox years ago but was later removed due to privacy concerns, and WebKit (the browser engine that powers Safari) has expressed no intention to implement it. The latest draft of the specification introduced a section on security and privacy with some recommendations for browser vendors, but it’s not clear at all that we’ll ever see this feature supported everywhere.

Web Share

Another web API that is especially interesting in the smartphone context is the Web Share API. Mobile operating systems like Android or iOS offer a standard mechanism for developers to share data from one app to another. The share button pattern is ubiquitous in native mobile apps, and users know exactly what to expect when they tap on it. However, share buttons in websites have usually been a mess in terms of looks, behaviour and underlying implementation, often displaying a number of options to share to popular services that trigger intrusive pop-ups. This is even worse in mobile devices, as you’d ideally want the user to be able to share to the installed native apps.

The Web Share API lets web developers hook into the operating system’s share mechanism in a very easy way. We just call the share method on the navigator object and pass along a title, text and URL:

All the properties are optional, so you could share just text, or a URL without a title. In the latest iteration of this API you can even share files via a files property, like a bunch of images; think about an image editing or a photo gallery website.

For installable websites, we can not only share information to other apps but also receive it from them. To enable this, we need to add a new share_target property to the web app manifest object:

The action property must point to the URL of our website that will handle incoming shares, and the params property maps the properties we saw before in navigator.share to URL parameters (we’re using the same names in this example).

So whenever another app shares data to our web app, it will be opened with the following URL: ourwebappdomain.com/share?title=some-title&text=some-text. To retrieve the shared data from the URL parameters, we can write something like the following:

Support for this API is far from widespread, but at least the basic sharing functionality works in both Chrome for Android and iOS Safari. That means that it’s actually available for a sizable chunk of the mobile browser market. Considering how big of an improvement it is over traditional share buttons, and how easy it is to implement, using it in your website for browsers that support it might be a good idea.

Ambient Light Sensor

A lot of mobile apps already had them, but last year marked the consolidation of dark themes in smartphones with a system-level dark mode introduced in both iOS 13 and Android 10. Besides accommodating the phone owner’s preferences, one interesting use case of light and dark themes is to adapt the user interface to the environment for improved visibility, which is particularly relevant for some kinds of apps: you might be familiar with Google Maps switching to a dark theme at night or when you are driving through a tunnel.

You can actually target dark mode in websites with a CSS media query, but all it does is to read the system-level theme currently selected, hence only covering the user preference case, not the environment one. For the latter we can use the Ambient Light Sensor API. This API is based on the Generic Sensor API, which provides us with access to data from all the different sensors of a device in a consistent way. The way to use it is to first create an instance of the particular sensor interface:

Then we add a listener for its reading event and call the start method:

In the code above, we get the illuminance property from the ambient light sensor, which holds the light level around the device in lux. If this value is under a certain threshold, we can determine that the device is in a dark environment. At this point we could, for example, toggle a CSS class in the body of the document to change the colours of the interface.

Similarly to the Battery Status API, the Ambient Light Sensor API is only supported in Chrome and browsers based on it at the moment. However, the future for this API looks much brighter as it’s based on the Generic Sensor API, which is a relatively recent specification that uses a common and more solid permissions model that should address security and privacy concerns.

Proximity Sensor

Have you ever noticed how your phone screen turns off when you bring it to your ear to pick up a call? This happens thanks to a proximity sensor mounted on the top front of the device, which is able to tell the distance to the nearest surface. Native apps can make use of its value to decide turning the screen off or modifying what appears in it. This capability is exposed to websites via the Proximity Sensor API, which is also based on the Generic Sensor API.

We can use it in exactly the same way we used the Ambient Light Sensor API. First, we create an instance of the sensor interface:

Then we add a listener for its reading event and call the start method:

We get two values from the sensor in this case: distance, which indicates the distance to the closest surface in centimetres; and near, which is a Boolean that tells us whether the device is close to that surface. The latter is usually the most useful, as it’s the one that would allow us to cover the use cases mentioned before.

The bad news is that this API is not implemented in any stable browsers yet. The closest thing we have are proximity events in Firefox, which provide similar functionality implementing an older specification, but they’re only available under a config flag that users need to enable. However, there is some hope, as the Proximity Sensor API is based on the Generic Sensor API, and the privacy implications of reading proximity data in particular are allegedly small compared to other APIs.

Magnetometer

We’re finishing our list with another API based on the Generic Sensor API. This one gives us access to the magnetometer of the device, which for all intents and purposes in our case is just a fancy way of saying compass. In combination with the Geolocation API, this opens up the door for practical use cases like having complete maps navigation in our browsers, or wild ones if we add to the mix other APIs like WebXR.

You know the drill by now. First, we need to create an instance of the sensor interface:

Then we add a listener for its reading event and call the start method:

The magnetometer sensor returns coordinate values. In the code above, we convert them to degrees. We could then use that value to rotate an image of a compass needle in our website usingCSS transforms, for example.

Once again, as with the Ambient Light Sensor API, the Magnetometer API is only supported in Chrome and Chromium-based browsers right now. But as we said before, it’s not totally unreasonable to expect it to land in other browsers eventually, along with access to other sensors likegyroscopes.

Conclusion

As you can see, the list of web APIs available to developers is large, and it only keeps growing over time. And although support is not even across browsers, that doesn’t mean we need to wait to use them. In an ever-shifting platform like the web, approaches such as progressive enhancement are absolutely key to delivering experiences that still cover the basics for everybody, but include extra improvements for users of browsers and devices that support them. So let’s keep building an amazing web together!