Simplifying our mobile SDK for developers - Why it’s time for 2.0

Managing and supporting SDKs is challenging. That’s particularly true of an SDK that accesses multiple phone sensors, in different ways, requiring different permissions.

Our goal has always been to offer the best location SDK on the market. And this includes ease of integration and testing.

In 2024 we started a project to make our SDK easier and more reliable to integrate. Looking at 12 months of support requests from app developers, we identified key issues, and set out to find improvements that would prevent more than 75% of these integration problems ever occurring.

Six months on and SDK 2 is ready for general availability. We’re really proud of the improvements we’ve made. We think something like 85% of all the integration support issues from the last year are now engineered out of the solution.

In addition we’ve added extensive remote logging and debugging capabilities, so that what’s happening in the SDK is now visible in our console.

Given the benefits of SDK 2, we’re encouraging all developers who use our SDK to update as soon as possible.Let’s dive into the changes.

Background / Foreground operation

Our SDK gets used in two different modes. In some apps, positioning should only take place while the app is in the foreground. In other apps, positioning should continue with the app in the background. The modes require different permissions to be declared when the app is built.

Previously, switching between the modes was handled with a server-side configuration flag on our side. If this didn’t match the app’s declared configuration, it could result in incorrect operation, and even crashes.

We’ve tackled these challenges with the following changes:

Instead of setting foreground or background mode over the air, this is now set as part of the configuration that the app passes to the SDK on start-up.

When the SDK is started, if any manifest / Info.plist entries or required configuration for the selected mode are missing, then the SDK will refuse to start. It will pass a failure code to the callback, send this to our remote logging server, and will throw a runtime exception / crash.

Debugging

Our SDK is minified and obfuscated, which means app developers can’t ‘see inside’. Similarly we aren’t able to ‘see inside’ the app builds that use our SDK. This means neither app developer nor SDK provider has a full view of what’s happening, making debugging incredibly difficult.

We’ve tackled this challenge by adding extensive remote status updates and logging - what’s going on in the SDK is now visible in our web console.

A full status report is sent from the SDK to our backend, which means it’s possible to detect integration problems using the developer section of our console. The status report includes the SDK version, the included modules, the manifest / Info.plist entries, user runtime permissions, and whether the SDK has ever generated any indoor or outdoor locations.

If the Crowd Connected device ID is known for an app install, it’s possible to remotely put the device into ‘Debug mode’. Every time the SDK is started and stopped is visible in real-time in the developer console. And each time the SDK status changes, this is also visible in real-time in the console.

Device ID determination

We’ve also added a feature to make it simpler to determine the Crowd Connected device ID for any phone using our SDK, which is needed to put the device into debug mode.

You can enter the IP address that the phone is connecting from in our console, and get a list of all the SDK instances connecting from that IP. Use the device model and OS to narrow down to the phone of interest.

Of course this won’t always work. In production there may be a huge number of phones connecting from the same IP, or the IP address may not be known.

So we recommend that all apps make the Crowd Connected device ID available in a screen somewhere, so that any SDK instance, whether in testing or production, can be identified and debugged.

Start / Stop Navigation

The final change removes the need to use the start and stop navigation methods. Incorrect use of these methods has caused a number of integration issues, so we’ve redesigned the SDK so they are no longer necessary.

Apps no longer need to call these methods when the map display is opened / closed.

Network economy

Finally, while working on this redesign, we made multiple efficiency improvements.

The SDK now makes significantly fewer API calls, which reduces data and battery usage.

Summary

SDK 2 has been a 6 month project. It doesn’t change the core functionality of our SDK - all of the improvements are focused on the app developer experience. We’ve made the integration process simpler, we’ve made testing easier, we’ve made it easier to spot problems, and added remote debugging features to help trace issues when they do occur.

All in all it’s a major step forward in making our SDK the best solution for any apps that need to support indoor or outdoor positioning and location features.