A Zebra scanner control app is mostly an app that configures DataWedge.
A Zebra scanner control app is usually less code than people expect. On a Zebra handheld the scanner is not a peripheral you open, claim and read from. It is a service that is already running, it owns the trigger, and it hands the decoded barcode to whichever app is in front. Most of your code goes on what happens after the scan. That half looks like the rest of the inventory barcode scanning apps people build. The hardware half is what is different here.
This page covers the two ways DataWedge can hand you a scan, what changes when you want a button on screen instead of a trigger pull, whether keystroke output really lands in a React Native text field, and what a rugged scanner app has to hold that a phone app never does.
See what the delay costs a shiftThe short version
Two output modes, and the choice shapes the whole app.
DataWedge can deliver a scan as keystrokes, as though somebody typed the barcode very fast into whatever field has focus, or as an Android intent your app receives as structured data. Keystrokes ask nothing of your code. Intents need a broadcast receiver, which on a cross-platform stack means a native module.
Almost everything else follows from that one decision: whether you get the symbology, whether you can tell a scan from something a person typed, and what happens when a trigger is pulled on a screen that was not expecting it.
The scanner is already a service, and it has a config
DataWedge comes pre-installed on every Zebra Android device. It is a service, not a library, and it owns the scan. You associate a profile with your app package, and from then on every trigger pull is handed to your app in whatever shape that profile says. Zebra describes a profile as holding the configuration for how DataWedge behaves with one or more associated applications, which is the sentence worth remembering: the scanner settings sit beside the app, not inside it.
That has one pleasant consequence and one awkward one. The pleasant one is that an app with a plain text field is already a working scanner app. Nothing to install, no permission to request, no SDK. The awkward one is that most of what people mean by control is configuration you do not own at runtime unless you go and ask for it.
Two delivery modes matter. Keystroke output sends the decoded barcode to the focused field as a run of key presses, emulating a person pressing keys. An action key setting appends a Tab, a Line Feed or a Carriage Return, which is how a scan submits a form without anyone touching the screen. Intent output instead hands the data to your app inside an Android intent, with the characters in one extra, the raw bytes in another, the symbology in a third, and tokenized GS1 fields in a fourth if you turn that on.
There is a third setting on the keystroke page that says more than its name suggests. The inter-character delay is a pause after each character is delivered, and it defaults to zero. Zebra tells you to raise it in steps of 100 milliseconds, to a maximum of 1000, if characters start going missing. Read that backwards and it tells you the wedge can type faster than an app can accept, and that the fix lives on the scanner side rather than in your code.
Does the wedge actually work in a React Native text field
Yes for the text itself, and the failure people brace for is the wrong one. Zebra warns that web applications read these key events through the DOM and do not receive Android key press events, which is why a barcode carrying a control character does nothing useful inside a browser. A React Native screen is not a browser and a TextInput is not a DOM input, so that warning is about Cordova and Ionic builds rather than this one. The characters arrive in the focused field and the value updates.
What you should not build on is per-key handling. React Native documents that on Android the onKeyPress callback only handles input from the soft keyboard, not from a hardware keyboard, and a wedge is far closer to a hardware keyboard than to a person. There is a wrinkle worth stating plainly: from Android 10 onwards DataWedge dispatches through its own InputMethodService, which is why the normal keyboard disappears for a moment during a scan, and an InputMethodService is a soft keyboard. We checked this in the documentation, not on a device, so treat onKeyPress as unreliable here rather than as settled in either direction.
Read the value instead. onChangeText gives you the field contents after every change, and onSubmitEditing is the hook for the Carriage Return that the action key setting can append, although whether an injected return fires it is exactly the sort of thing to confirm on the handheld. Keep in mind that TextInput is a controlled component: React Native forces the native value to match the value prop, so every character is a state update and a re-render. That is the mechanism behind dropped characters at zero delay, and a good reason to reach for a ref when the barcodes are long.
The honest summary: keystroke input works in a React Native field, per-character events do not, and none of this was verified on a bench. Borrow a handheld for twenty minutes before you design around it.
React Native documentation, TextInput
Try it
What the inter-character delay costs a shift
The wedge types the barcode one character at a time. Raise the delay to stop dropped characters and every scan on the floor gets slower.
2.0s per scan, 20 minutes a shift
Over a second of typing per scan, before anyone has read the screen. The delay is a scanner setting, not something you can fix in the app, so it is worth knowing the price before you raise it.
The part that earns the word control
Configuration from inside the app is what turns a text field into a control app. DataWedge exposes a set of Android intent APIs, and from your own code you can create, clone, rename and delete profiles, switch the active profile, set and read config, enable or disable the scanner input plug-in, switch between the built-in imager and a paired Bluetooth scanner, and ask for scanner status.
The soft scan trigger is the one people want first. It takes START_SCANNING, STOP_SCANNING or TOGGLE_SCANNING, which is how you put a Scan button on screen for the times somebody is holding the device one handed. Two conditions come with it. Barcode input has to be enabled in the active profile, and Zebra notes the command can be ignored while the scanner is busy, so read scanner status and leave a gap rather than firing blind.
Turning the scanner off matters as much as turning it on. A picking screen should scan. A notes screen should not, or the first stray trigger pull fills a comment box with a pallet number. Disabling the input plug-in on screens that expect no scan is the cheapest bug fix in an enterprise barcode scanner app, and the same problem shows up on every form of a maintenance management app, where a technician taps through fields with a live scanner still in their hand.
One limitation to state plainly: none of this exists on iOS. DataWedge is an Android service, so the wedge, the profiles and the intent API are Android only. If supervisors carry iPhones, that half of the app needs a different capture route, usually the camera.
What the app holds between scans
Between scans the app is doing the real work, and this is where a warehouse scanner app stops resembling a phone app. A scan is an event with a place in a task: this pallet, into this bay, against this order line. The barcode is the smallest part of the record it produces.
Three behaviours are worth designing before any screen exists. What happens when a scan matches nothing, because it will, and a silent failure on a device held at arm length is invisible. What happens on a repeat scan of the same label, which is not the same thing as a genuine second unit. And what happens when a trigger is pulled while no field has focus, which under keystroke output means the characters go nowhere at all and the worker has no idea.
The symbology question decides more than it looks. If you only ever need the digits, keystroke output is enough. If the rules depend on what kind of code it is, a GS1 structure carrying a lot number and an expiry date, or a serial shipping container code on the outer case, then you need intent output and the label type and tokenized fields that come with it. That is the usual reason a barcode scanning app for food outgrows the wedge in its first week.
How the scan can reach your app
| How the scan arrives | Works in a plain text field | You get the symbology | You can tell it from typing | Stays pure JavaScript |
|---|---|---|---|---|
| Typed in by hand | Yes | No | No | Yes |
| DataWedge keystroke output | Yes | No | only by timing | Yes |
| DataWedge intent output | No | Yes | Yes | No |
| Bluetooth scanner in HID mode | Yes | No | only by timing | Yes |
| Camera scanning inside your app | No | Yes | Yes | No |
Building one around your own process
Zebra ships utilities for this and every warehouse platform ships a scanning client. They are built for the general case: receive, putaway, pick, count. They fit until the process has a step nobody else has. A bin rule local to one site. A supplier who prints labels in their own format. An exception a picker has to record in four seconds while still holding the box.
Newly is an AI app builder. You describe the app, including which field the scan lands in and what happens on a mismatch, and it writes a real React Native and Expo project you own. It is $25 a month and there is no free plan. The part that matters for hardware like this is the Deploy tab: one press builds, signs and uploads the Android app to Google Play internal testing, and Newly also builds a standalone release APK you can download and install straight onto a handheld, which is usually how a build reaches a device that lives in a charging cradle. iOS goes to TestFlight through your own Apple Developer account. It does not ship a DataWedge integration, and intent output needs a native Android receiver, so settle that question early if you want structured data rather than keystrokes.
One more thing to decide before any screen gets drawn: what the app does in a warehouse with no signal. Racking, steel and cold storage beat wifi, and a scanning app that assumes a live connection fails in the exact aisle where it matters most.
Questions people ask about Zebra scanner control apps
An app that configures and drives the scanner built into a Zebra Android handheld, rather than one that talks to the hardware directly. The scanning is handled by DataWedge, a service pre-installed on every Zebra Android device. Your app chooses the profile, chooses how the data arrives, and decides what the scan means.
Describe the scan your floor actually does
Write down which field the barcode lands in, what happens when it matches nothing, and what a picker is holding at the time, then build the app around that.
Start building