App for Fitness Device in React Native: How to Develop Guide from Technical Lead

The demand for convenient and personalized solutions transforms the fitness app market, sparking interest in how to build an app for fitness devices, as now more people prefer exercising at home with their choice of equipment to maintain their physical health.

Fitness Apps - Global Strategic Business Report by Global Industry Analysts, Inc. states that the worldwide size of the fitness app market reached $12.1 billion in 2024, and it’s going to reach $25.8 billion in 2030.

According to Statista, 901.4 million users worldwide have used fitness apps in 2024. And this number is expected to grow to 1,048 million by 2028. This exponential growth is a compelling motivation to develop a React Native companion fitness app, don’t you think?

Device

The device has a few important fields, which could help us work with it:

Characteristics

Characteristics are the main communication gateway between the Client (iOS and Android app) and Server (BLE device). Each characteristic has:

1. UUID – That's the unique identifier, which you can use to distinguish characteristics among others. Some standard services use a 4-byte value within the format 0000{XXXX}-0000-1000-8000-00805f9b34fb (these 4 symbols ({XXXX}) differ in every characteristic), while others have fully custom UUIDs.
2. Value – A base64 string representing the characteristic’s data, which updates on read/write operations.
3. Metadata – Define what actions can be performed:

• Write Without Response – Sends data without confirmation.
• Write With Response – Sends data and waits for confirmation.
• Read – Retrieves data from the characteristic.
• Notify – Enables real-time updates from the device.

Characteristic Value

It doesn't matter whether we write or read data, we work with Characteric's value, which is a base64-string representation of Uint8Array.

To make transformations, we use base64-js:

We suggest using react-native-ble-plx as the best solution for making the connection between a React Native app and a BLE device.

Please follow the installation guide for react-native-ble-plx:

• For iOS: Add BLE capabilities to your Xcode project;
• For Android: react-native-ble-plx don’t point out the differences in your AndroidManifest since Android 12. Thus, you need to add a few permissions and explicitly require them.

You can find more details in the official documentation: Bluetooth Permissions in Android.

Our Requirements

When working with Bluetooth, we should deal with:

• listeners (device connection/disconnection/subscription to data change);
• scanning (finding new devices, having the ability to connect to them);
• state management, etc.

Due to the hardware limitations, we should run scanning only once for a React Native fitness app. If we stop-start scanning in the application, we can break the Bluetooth connection.

Additionally, listeners should always be up-to-date. We want to prevent race conditions and state issues when updating it. The new value only applies in the next render, and it could break the app in the current one.

With these two ideas in mind, we understand that React doesn't really work well with it. States would lead to endless re-runs of the scanning process, our listeners wouldn't be up-to-date, and there may be a lot of other possible issues.

Of course, we could "hack" React: either use the refs all the way or just make all the dependencies empty. However, such manipulations make the code very hard to read and difficult to maintain since any possible change could break the way we work with it.

The best approach? A dedicated Bluetooth manager class handles hardware interactions, with a helper hook to update React state efficiently.

Let’s see how to implement it:

We'll use the same approach across all modules we create in our fitness app React Native. Let’s move on!

Enabling Permissions

Permission request differs for both iOS and Android:

• For iOS, the permissions are automatically asked.
• For Android, you need to ask for a few permissions. Until Android 12, it was only ACCESS_FINE_LOCATION. Right now, they also need BLUETOOTH_SCAN and BLUETOOTH_CONNECT.

📌 You can learn more about how to connect BLE device Android, in our guide.

For instance:

Scanning

To perform scanning, we first need to create a react-native-ble-plx manager:

We need to create it only once, at the start of the complete React Native fitness app development with BLE mobile app development services, because if we do it multiple times, Bluetooth wouldn't work well.

We should structure our scanning inside a separate class. The scanning will start only once, and all the outer dependencies will be replaced using refs. It’s the best approach, but if you'd like to keep it all inside the React hook (which we don't recommend doing), please take care of the following aspects:

1. Before calling the next startDeviceScan (e.g., when dependencies changed), we need to call .stopDeviceScan. If we don't do it, we fall into a memory leak.
2. If we call multiple start-stop-start-stop device scanning, your app might end up not being able to scan at all.

Too many dependencies can repeatedly trigger .startDeviceScan, disrupting Bluetooth stability. You need to be careful with it in your React Native workout app to make sure your Bluetooth connection is stable.

What can you do?

1. Reduce the number of outer dependencies.
2. If you have a state and you need to update it, use setState(prevValue => newValue) syntax. In this case, you don't need extra dependencies with useEffect.
3. If you have a state and you really need a previous value, use useRef. It doesn't lead to rerenders, and you don't need to add it to your useEffect dependencies.

Now, let's see how we can handle it as a separate class. We need to keep a few things in mind:

1. We need to let our React Native fitness app know something has gone wrong.
2. We need to update our state from our class.

addItemToList is a custom function that ensures there are no duplicates.

These two functions — changeOnSyncDevices, changeOnBleError — are custom changeOn functions, which are updated within useEffect. We need it because the dependencies might change, and it won't affect the constructor. We need custom useEffects to make sure we can update the handlers and listeners as we progress inside the React Native fitness app.

You might’ve noticed that we’re adding allowDuplicates here. It’s needed for a specific edge case. Without it, iOS won’t rescan the same device if you disconnect and reconnect it. Since iOS sees it as the same device, it won’t notify us when it reconnects.

With this code, we could run into a situation where we keep reconnecting to the same device multiple times. To avoid that, we can add a field to the class that tracks whether a device is currently connected. We also need to handle device disconnections properly to ensure we're not storing any devices that are no longer available.

Looks great!

Navigating Between Screens

Inside your React Native gym app, you can see a few screens that require Bluetooth connection and work with devices, and a few ones that don't, which could be an important factor in your IoT project cost estimation. Thus, you might be tempted to start all the scanning operations on specific screens because it eases the process of retrieving/showing the data.

We don’t recommend doing it because multiple scan-stops might break scanning. Therefore, you should wrap all your code inside a context.

However, you should somehow understand whether you should actively scan right now. You can use another isActive field inside a class. To make sure it's up to date, you can use the listener updates within our hook.

Using this code above, every time you call useBleContext on a screen, active would be set to true, triggering automatic scanning. Once you leave this screen or switch to another tab, active will be set back to false, stopping the scanning process.

📌 For more information on managing Bluetooth connections in your app, check out our Web Bluetooth tutorial.

How do we parse the received characteristic value? Imagine we received a notification from ROWER (2ad1). It's a base64 string which we can parse to an array of numbers. However, what we receive depends on the first two bytes:

[CONTROL_BYTE_0, CONTROL_BYTE_1, VALUE_BYTE_0, VALUE_BYTE_1, ....]

That's how it could look: [12, 0, 13, 6, 5, 3]. But how to understand what [13, 6, 5, 3] stands for?

It depends on the values we see in the first two control bytes. To work with it properly, we need to convert CONTROL_BYTE_0 and CONTROL_BYTE_1 to the binary system — [1100, 0]. Then, we need to take a look at each bit and check its value. The way you can do it is described in the
documentation.

For instance, our protocol says that if on bit 0 we have value 1, we have 2 bytes of speed:

• In case we have value 1 on bit 1, we have 2 bytes of distance.
• If we have value 1 on bit 2, we have 2 bytes of calories.
• Finally, in case we have value 1 on bit 3, we have 2 bytes of energy.

Let's sum up what we have for now:

Now, let’s take a look at our values — [13, 6, 5, 3]. The first two bytes are the "calorie" bytes — the calories are 13 + 6. Then, we have 2 bytes of energy, and we start not from the beginning, but from the end of the previous take. It'd be 5 + 3. Simply speaking, we shift our values.

RESPONSE: speed - not set, distance - not set, calories - 19, power - 8

However, if the CONTROL_BYTE_0 value is 10 instead of 12, we don’t have calories. If we turn 10 to the binary we receive 0101, which means that instead of calories we have distance:

RESPONSE: speed - not set, distance - 19, calories - not set, power - 8

To sum up:

What functionality do we expect from our protocol?

1. Write to different characteristics under different circumstances.
2. Read from one characteristic under some circumstances.
3. Subscribe to different characteristics, and correctly parse the response, shifting the values.

Delightech

Deligtech is a very niche protocol. You can access its documentation here. Despite offering a range of important features, their number is quite limited, though different from those of FTMS.

1. It has a single characteristic for both writes and monitors (fff1). All the requests should be correctly prefixed to understand that we work with Delightech.
2. Even though we have one characteristic for all Delightech operations, we have different goals for writing. We distinguish the goal by our payload:

— When working with the info command, we pass 64 as the first byte of the payload. This command includes such info: start, connect, pause workout; user info (like weight), etc.
— When it comes to workout command, we need to "ask" this characteristic to send us a notification with an updated user payload. We pass 32 as the first byte of the payload. We run this command and receive a notification every second. We can change this number to any other. For example, we can send this command every 10 seconds and receive a notification every 10 seconds.

3. Notification is sent only when we send the write command. Instead of subscribing to a real notification, we ping our BLE device every second.

To sum up, there are only 3 possible situations when we send requests to a BLE device:

• Establish a connection with a mobile app.
• Send user info.
• Get information about the workout (within this request, we also control whether the workout is active or not, and change the resistance/target speed).

Let’s talk a bit about parsing the values. Instead of shifting our values, depending on the first bytes, we ALWAYS expect them in the same positions. For instance, if we expect calories, they'll always be sent as the 6th byte, whether we have distance or speed, or any other field.

However, we have some exceptions here. Some fields might be empty for particular devices (for instance, when we run, we don't receive any rpm; or we won’t receive heart rate if we don’t use a heart rate sensor). We understand what fields are sent by taking a look at the CONTROL_BYTE. Imagine the following notification:

[CONTROL_BYTE, SPEED_HIGH, SPEED_LOW, CALORIES_HIGH, CALORIES_LOW, DISTANCE_HIGH, DISTANCE_LOW]

As you can see, we always receive the speed, calories, distance, etc. in the same position. If, for instance, bit 5 of CONTROL_BYTE is 1, we omit CALORIES_HIGH, CALORIES_LOW. We don't take a look at them at all.

The last thing: we can take a look at the notification we receive, and based on it, understand what type of device we work with (bike/treadmill/rower/etc). Some fields also depend on what type of device we work with.

To sum up:

1. We need to be able to .write() to the same characteristic under different circumstances (with different values).
2. We don't .read() from any fields.
3. We need to subscribe to a single characteristic and every second trigger .write() to receive a notification. We don't shift any values, but read them, depending on CONTROL_BYTE.

Yeekang/Fitshow/Thinkfit

Documentation on these protocols can be found here. However, it’s in Chinese so there might be some issues understanding it. The English version can be found here. Let’s review some key points of the protocol.

We have two different characteristics to work with. All the values we send/receive from characteristic should be prefixed with 2 first bytes — [0x02, 0x42-0x45]. The second byte marks the exact command we want to send/parse.

Also, we have a special characteristic to write to (fff2). Even though for all the writes we have a single characteristic, we have multiple possible occasions to send write:

1. Connect to the React Native fitness app.
2. Write a command to receive data about the device (available fields, max resistance, etc).
3. Send the user's data (weight, height, etc.).
4. Start the workout.
5. Pause workout.
6. Resume workout.
7. Stop working out.
8. Change resistance/target speed.
9. Every second, send 2 requests to receive a notification about the workout.

Here we state that the protocol might have an array of possible characteristic UUIDs, using which we can determine the specific protocol we work with.
Also, the protocol might have an array of possible characteristic UUIDs or an array of prefixes for the protocol. Using either of them, we can determine the protocol.

Also, we can specify protocol.helper.ts, which takes a Protocol and provides us with a way to understand that the device is of Protocol:

Later on, we can use the ProtocolHelpers inside our AppDevice to know if the device is of Protocol:

Having done this, we'll always have an available #currentProtocolHelper inside our AppDevice, which would make all the data parsing / .write() sends. If we don't know the #currentProtocolHelper, we can’t understand what protocol we work with. In this case, we can show some errors with a timeout.

Step 2: Sending Some Particular Write Commands in Specific Moments

Let's agree on what we mean by “particular commands”. It's just a write command:

• Sent to a specific characteristic.
• Sent with specific values (might be dynamic).
• Sent at a specific moment.
• Some commands can be sent only for some protocols.

A list of possible commands we might send consists of:

Each of these CommandType is used in at least one or more protocols. Inside our AppDevice, we specify our intention to send some information to the protocol.

This is where the tricky part happens. To send a command, we need to understand what protocol to send it to. At the same time, some protocols (Delightech and Fitshow) don't respond until we send the CONNECT command. How do we handle this chicken and egg situation?

Well, we could send the commands to all the possible protocols if their identifiers are available. So if we send the FTMS-like data to Delightech, they’d just ignore it. However, if we send Delightech data to Delightech, we receive a Delightech response and, thus, can use ProtocolHelper afterward. Simple as that!

Let's first update our protocol to let us know what command it can handle:

Here, for a Protocol, we determine commands by creating a record that contains all the CommandTypes we want to send to the protocol. We may not want to send one of the commands, that’s why it's Partial. We also may send a few requests within one command (for instance, for Yeekang/Fitshow/Thinkfit, we send 2 write requests every second to receive a workout notification).

Command consists of the UUID of the characteristic to send to (for instance, fff1), and an array of values. Each value can have a few different fields:

Here's an example of how it can look:

Then, we need to map these commands for every protocol to a definite array of numbers, which we could later use with Bluetooth:

And, finally, we can use it inside the AppDevice. Remember that if we don’t know the protocol and send a command, we should send it to every protocol.

The field might look something like this:

Here we state that we want to save a new speed, if we received a notification:

• from characteristic 'fff1';
• when on the 0 index the value is 0x20, and on the 1 index the bits are 1 on 2 index, and 0 on 3 index.

Also, we want to have this field:

• in a decimal format;
• take it from the index 4th byte;
• take 2 bytes, and multiply them with [10, 1].

Let's take a look at the example of how it could look:

It works with Delightech and Fitshow since it allows for correctly understanding the values. However, developers have identified a few flaws with the FTMS. As you might remember, we have value shifts for the FTMS. For instance, if we have speed, we’ll have the distance at byte 4. However, if we don't have speed, we’ll have the distance at byte 2. And it goes crazier the more combinations we have.

In React Native development, there are 2 possible solutions:

1. We can set up a special class/function to handle the offsets here.

For instance, we pass the characteristic array, the UUID, and all the fields we have, and it goes one by one in an array (starting with the first value), increasing the startingByte for all the next ones. Thus, we'll add a separate field sholudShift or something like this. It's a working solution that doesn’t have any serious downsides.

However, we don’t like to lose the flexibility and divide our parsing into 2 different pipelines, with only 1 flag changing the behavior. If we have another protocol with something in between, it might not work that well.

2. We can have a special mapper function that makes all the offsets at build-time and leaves us with thousands of different matchRules, depending on what we have.

For instance:

• If we have no other values, look at the speed at byte 2.
• If we have only distance, look at the speed at byte 4.
• If we have distance and calories, look at the speed at byte 6.
• If we have distance, calories, and RPM, look at the speed at byte 8.

We'll have several rules like these for each field. During the parsing, we should find the appropriate matchRule. If we find it, we should look at the startingByte and make the computations.

With this implementation, our code for Fitshow, Delightech, and FTMS looks the same. The only difference is that the FTMS code is much bigger.

You can choose either of these solutions, but we used the second one, and didn't see any issues with it so far.

Let's take a look at how the mapper can look:

Here we have a simple switch on whether the field should be offset or not. If yes, we go through the positions, adding 1 rule to the existing matchRules and increasing the startingByte. Basically, the situation when we have ONLY this field (for instance, the speed at position 2) changes to the situation where we have every possible combination of fields. For instance, speed, distance, calories, speed, and RPM. In this case, speed is at position 10.

Let's take a look at how our Protocol might look:

Using the deviceFields, you can understand what fields you can work with and save them once you understand the protocol. Let's finalize and see how it could work:

🔄 Reverse Engineering: Getting BLE Logs Based on the Existing Apps

Right now you have all the information you might need regarding the architecture, setup, and protocols when creating a React Native gym app for fitness devices. The last thing to cope with is making the correct mapping for the devices. You can use the protocol, although it might not always be easy for you to understand what command follows what response.

If you have a device in place, you can connect using any existing fitness-related app to your device, and record all the Bluetooth logs.

Learn more about the integration of BLE devices into your React Native fitness app in our article:

Drawing from our experience in building a React Native workout app for SportPlus, we’ll provide insights into each step of developing such an application.

Step 1: Validate the Protocol

We decided to start with protocol validation since the success of the app lies in its ability to communicate effectively with the supported equipment. Initially expecting a single protocol, we soon discovered that the reality was far more complex, with 3 distinct protocols in play. However, we swiftly came to an effective approach.

Our solution? A generic protocol handler. This system enables the fitness application to identify and adapt to the specific protocols used by different fitness devices. This involved parsing unique identifiers and special data within characteristic values to identify the protocol, ensuring that the app interacts only with compatible devices.

Upon receiving a notification from one of the protocols, our application expects the equipment to belong to that protocol and operates exclusively with it. However, in cases where no response is received within a certain timeframe, we deduce that the device is not a compatible training machine and initiate a disconnection.

The generic protocol handler helps the fitness app find the right device by checking either characteristic UUID or characteristicArray. Let's summarize and see how it works in our case:

Step 2: Wireframe the UX

In order to prepare the relevant design of the fitness app React Native, we began UX wireframing. It involves creating a blueprint of the application's layout and navigation flow, laying the groundwork for intuitive user interaction.

Since the success of a fitness device application relies on UX, wireframing stage was focused on simplicity and clarity. We aimed to create a clean and uncluttered layout that allowed users to easily access the needed information. By establishing clear navigation paths and logical screen transitions, we ensured that users can navigate the app with minimal effort.

Step 3: Develop the UI/UX Design

During this stage, we bring our concepts to life through visual aesthetics and interactive elements. This stage involves refining the wireframe layout and adding visual elements to create a polished and engaging user interface.

User empowerment is the key concept of our fitness app UI and UX philosophy. We aim to give users the tools they need to take control of their fitness journey, whether it's setting personal goals, customizing workout routines, or tracking performance metrics over time. Every aspect of the UI design is carefully crafted to improve usability and facilitate user interaction.

If you want to know how to create an engaging UI using React Native, read our article dedicated to this topic:

Also, we provide comprehensive services for building a personal training app from scratch, considering all your preferences.

Step 4: Initiate Frontend Development

Our developers transformed design into functional components that seamlessly integrated with the protocols and backend systems.

A key focus during frontend development was flexibility and scalability. We designed the React Native gym app architecture to accommodate future enhancements and changes, ensuring that it can adapt to evolving user needs and technological advancements.

Step 5: Execute Quality Assurance and Testing

No application is complete without thorough testing to ensure its reliability and performance across various devices and usage scenarios. Our QA process encompassed the following testing types:

1. Functional testing. We conducted testing to identify and address any bugs or issues that could impact the user experience. It’s the main type of testing we used to verify functionality, from logging into the account to connecting the equipment via Bluetooth.
2. Non-functional testing, which includes:

• Performance testing. This testing ensured that our app could handle the demands of real-world usage without slowdowns or glitches.
• Compatibility testing. We tested our application against a range of fitness devices to ensure compatibility and consistency.
• Usability testing. We assessed the user-friendliness and intuitiveness of the app for its target users.
• Localization testing. We verified that the system functions work well when adapted to different languages or regions, ensuring a consistent user experience across diverse audiences.

We also thoroughly tested the interaction between the equipment and the mobile application. In projects involving interactions between several devices, ensuring a stable connection and seamless operation is paramount. Additionally, we asked a client to send us additional fitness devices to check the simultaneous connection.