When you’re working on BLE software, there are plenty of situations where you need a device to test against, and the real one just isn’t available. Firmware might still be in progress, you may be testing an app flow in isolation, or you might want to validate a GATT design before any hardware exists.
That’s where Virtual Devices in LightBlue come in.
Virtual Devices let you quickly create a simulated BLE peripheral directly inside LightBlue. You can define services and characteristics, control advertising behavior, and interact with the GATT table just like you would with a real device. We originally built this feature for ourselves to make it easier to test and debug BLE interactions without depending on physical centrals or peripherals, and it’s become a core part of our own development workflow.
This guide walks through what Virtual Devices are, how to use them, and where they fit into your development workflow.
How Virtual Devices Simulate Real BLE Devices
A Virtual Device behaves like a real BLE device. It advertises, accepts connections, exposes a GATT table with services and characteristics, and responds to reads, writes, and subscriptions just like the hardware device you’re building. The difference is that it exists entirely within LightBlue.
However, Virtual Devices simulate the GATT structure and BLE protocol layer, not the underlying hardware. Services or characteristics that depend on physical sensors, actuators, or other hardware-specific behavior won’t be present unless you manually configure them. This makes Virtual Devices useful for testing app-side BLE logic and connection handling, but they’re not a complete substitute for hardware testing.
Under the hood, LightBlue uses your phone or computer’s Bluetooth radio to advertise the virtual device profile. Other devices, whether that’s another phone running your app, a tablet, or even another instance of LightBlue, can scan for it, connect to it, and interact with it exactly as they would with physical hardware.
This means you can test connection logic, verify data handling, and validate your app’s BLE implementation without waiting on firmware or physical prototypes. You’re working with the same GATT structure and connection behavior you’d see in production, just simulated.
How to Create and Use a Virtual Device in LightBlue
The Virtual Devices workflow in LightBlue is pretty straightforward. You begin by creating a device, configuring its GATT table, and starting advertising. Here’s the step-by-step:
- Open the Virtual Devices tab: In LightBlue, navigate to the Virtual Devices section. This is where you’ll create and manage simulated peripherals.
- Create a new device: Tap the plus icon in the upper-right corner. You’ll see two options:
- Start with a template: Choose from pre-configured devices like heart rate monitors, thermometers, or other common BLE profiles. Templates provide a complete GATT table based on standard BLE specifications, so you can start advertising and testing immediately or customize the structure to fit your needs.
- Create a blank peripheral: Build your GATT table from scratch with your own services and characteristics.
- Configure your device: Press save, and your device will appear in the Virtual Devices list. Select your device from the list to edit it. You can:
- Change the device name (this is what appears in scan results).
- Add, remove, or modify services and characteristics. LightBlue automatically includes the Service Changed Service, so there’s no need to add it.
- Set UUIDs, properties (read, write, notify, indicate), permissions, and initial values for each characteristic.
- Start advertising: Once your Virtual Device is configured, start advertising. LightBlue will begin broadcasting the device, making it discoverable to any BLE central scanning nearby.
- Connect and interact: Open your mobile app (or another instance of LightBlue) and scan for devices. Your Virtual Device will appear in the scan results. Connect to it, explore the GATT table, read characteristics, write data, or subscribe to notifications. Everything works just like it would with a real peripheral.
Managing and Reusing Virtual Devices
All Virtual Devices you create are saved in the Virtual Devices list, making them easy to reuse across testing sessions. This is helpful when you’re iterating on a design or switching between different test scenarios without needing to reconfigure a device each time.
LightBlue also includes pre-built templates for common BLE profiles like heart rate monitors and thermometers. These templates give you standard GATT structures without needing to build them manually, and you can customize them once created if your use case differs from the baseline profile.
If you’ve previously connected to a real device, you can clone its GATT profile to create a Virtual Device with an identical structure. This is especially useful when you need to test your app against a specific device configuration but don’t have the hardware available, maybe it’s in use, being reflashed, or you’re working remotely. Cloning captures the exact services, characteristics, UUIDs, and properties from the real device, so you can replicate its behavior in LightBlue and continue testing without waiting on hardware access. Once cloned, you can use the Virtual Device as-is or modify it to test variations or edge cases.
If you no longer need a Virtual Device, you can remove it by swiping it from the list.
When LightBlue Virtual Devices Are Most Useful
Virtual Devices aren’t a fit for every situation, but knowing when to reach for them makes a big difference. The examples below reflect the scenarios we’ve seen them be most useful in our day-to-day work.
Testing App Behavior Without Hardware
One of the most common uses for Virtual Devices is early-stage mobile app testing, before hardware or firmware is fully available. We’ve often used Virtual Devices to stand in for a peripheral so we can validate connection flows, characteristic reads and writes, and basic data handling while firmware is still in progress.
This approach lets you exercise your app’s BLE logic early and often, rather than waiting for hardware to unblock testing. By the time real devices are ready, your app’s BLE layer is already well-tested and easier to integrate.
Reproducing and Debugging Issues in Isolation
Virtual Devices are also useful when you need to reproduce a specific BLE issue without relying on physical hardware. We’ve found this especially helpful when debugging edge cases or failures that are hard to trigger reliably on a real device.
By simulating a device and controlling its behavior, you can focus on a single interaction—like a particular characteristic value or notification sequence—and verify how your app responds. This can make it much faster to reproduce bugs, validate fixes, and understand failure modes without repeatedly reflashing firmware or setting up complex test conditions.
Learning, Teaching, and Exploring BLE Concepts
We also use Virtual Devices as a lightweight sandbox for learning and experimentation. When you’re trying to understand how GATT tables, characteristics, and notifications behave, having a simulated device makes it easy to explore without writing firmware or purchasing hardware.
This is useful whether you’re new to BLE, onboarding a teammate, or just experimenting with different approaches. You can quickly create simple profiles, interact with them from a central, and see how changes affect behavior in real time.
Prototyping GATT Designs Before Firmware Exists
Another place Virtual Devices shine is during early design discussions. We’ve used them to prototype and validate different GATT structures before committing to a firmware implementation.
By creating multiple Virtual Devices with different service and characteristic layouts and testing them against a mobile app, you can evaluate tradeoffs early and make more informed decisions. This helps surface issues sooner, when changes are cheaper and easier to make.
Build, Test, Iterate
Virtual Devices won’t replace physical hardware, and they’re not meant to. But they can be a useful tool when you need a fast way to test, debug, or differentiate between BLE behavior and a hardware change.
We’ve found them especially helpful for validating app-side BLE logic, experimenting with GATT designs, and isolating issues before bringing hardware into the loop. Used this way, Virtual Devices can help reduce friction early in development and make later hardware testing more focused and efficient.
For a broader look at how LightBlue fits into different stages of BLE development, our article on LightBlue Use Cases to Ship BLE Faster covers everything from prototyping to production testing. And if you want to see how Virtual Devices fit into systematic mobile app debugging, our article on Using LightBlue to Debug Centrals walks through testing your app’s BLE implementation against known-good peripherals.
