Mehedi Hasan · Senior Software Engineer React Native vs Native for Wholesale Field Sales Apps: Which One Wins?
React Native or native Swift/Kotlin for a wholesale field sales app? Compare offline orders, scanning, ERP sync, budget and upkeep before you choose a stack.
If you run sales for a wholesale distributor, your reps need an app that takes orders in a basement stockroom with no signal, scans barcodes, shows the right customer price, and pushes clean orders into the ERP when they reconnect. The question is whether to build it once in React Native or twice in native Swift (iOS) and Kotlin (Android).
For most distributors, React Native wins. Native wins in a narrow set of cases, and it is worth knowing them before you sign a statement of work.
What a wholesale field sales app actually has to do
Before comparing stacks, pin down the job. A typical field sales app for a distributor covers:
- Offline order entry — catalog, customer list, price lists and open orders stored on the device, with orders queued until the rep is back online
- Customer-specific pricing — contract prices, quantity breaks and promotions pulled from the ERP, not re-implemented in the app
- Barcode scanning — camera scanning for shelf audits and reorders, sometimes rugged scanners such as Zebra devices
- ERP sync — orders, credit holds and inventory availability exchanged with NetSuite, Business Central, Epicor or a homegrown system
- Visit logging — notes, photos and signatures on delivery or proof of visit
- Admin control — remote sign-out, role-based access and app updates without chasing reps to reinstall
None of these is exotic. That matters, because the case for native is strongest when an app leans on hardware or platform features at the edge of what cross-platform tools support.
Where React Native is the better choice
One codebase for both platforms. Most distributors have a mix of iPhones, Android phones and Android rugged devices. React Native ships to both from one TypeScript codebase, so features, fixes and pricing rules land on every device at the same time.
Offline-first is a solved pattern. Local databases such as SQLite (through libraries like op-sqlite or WatermelonDB) handle thousands of SKUs and customers on the device. The hard part of offline sales apps is conflict handling — what happens when a price changes while a rep has a queued order — and that logic is the same work in any stack.
Scanning is well covered. Camera scanning through react-native-vision-camera is fast enough for shelf work. Rugged Zebra devices usually expose scans through DataWedge intents, which a small native module can pass into React Native.
Faster updates. With Expo and over-the-air updates for JavaScript changes, you can fix a pricing display bug without waiting on an app store review. Changes that touch native code still go through the stores.
Cheaper to own. One codebase means one set of tests, one release process and one skill set to hire for when the app needs changes next year.
If you want the internal-tools angle on performance, we cover it in React Native vs native iOS performance for internal tools.
Where native Swift or Kotlin is the better choice
Native is worth the extra cost when one of these is true:
- Your fleet is a single platform and will stay that way. If every rep carries a company-issued iPhone and that policy is fixed, building only in Swift removes the cross-platform layer.
- You depend heavily on vendor SDKs that only ship native. Some rugged-device, payment-terminal or printer SDKs offer only Swift or Kotlin libraries. One or two can be bridged; a dozen becomes a native app with extra steps.
- You need deep background work. Continuous location tracking, Bluetooth sessions with scales or printers that must survive the app being closed, or heavy on-device processing are easier to get right natively.
- You already have native mobile developers in-house who will own the app after launch.
How the two compare side by side
| Factor | React Native | Native (Swift + Kotlin) |
|---|---|---|
| Codebases to build and test | 1 | 2 |
| Offline order entry | Strong, via SQLite-based local storage | Strong, via Core Data / Room or SQLite |
| Camera barcode scanning | Strong | Strong |
| Rugged scanner SDKs | Usually fine with a small native module | Direct access |
| Background location and BLE | Possible, more care needed | Most control |
| Shipping fixes | Over-the-air for JS changes, stores for native | App stores only |
| Build effort | Lower | Roughly one extra platform’s worth of work |
| Long-term maintenance | One team, one skill set | Two skill sets to keep |
What it costs
The biggest cost driver is not the stack; it is how many ERP objects you sync, how pricing works, and how much offline conflict handling you need. Building twice natively adds a second platform’s worth of build and test effort on top of that.
Our mobile builds start from $16k as a fixed price, agreed in the statement of work before development starts. See mobile app development for what that covers and pricing for how our engagement models work.
How to decide in one meeting
Ask four questions:
- Do reps use both iOS and Android, now or within two years? If yes, lean React Native.
- Is there a vendor SDK you cannot replace that only ships native? If yes, check whether it can be bridged before choosing native.
- Does the app need to keep working in the background (tracking, Bluetooth) while closed? If yes, weigh native.
- Who maintains the app after launch? Pick the stack that team can support.
If you are also planning who builds it, read how to hire a React Native team for an offline field sales app.
FAQ
Is React Native fast enough for a catalog with thousands of SKUs?
Yes, if the catalog lives in a local database and the lists are virtualized so only visible rows render. Slow React Native apps usually load the whole catalog into memory or re-render long lists on every keystroke; both are design problems, not limits of the framework.
Can a React Native app work with Zebra or other rugged scanners?
Usually yes. Zebra devices can broadcast scans through DataWedge intents, which a small native module passes to the JavaScript side. Check the specific device and SDK during scoping, because a few vendor SDKs only ship native libraries.
How does offline order sync avoid duplicate or wrong-priced orders?
Each queued order gets a unique ID so the server can ignore repeats, and the server re-checks price and credit when the order arrives. If something changed, the order is flagged for the rep or an inside sales coordinator instead of being silently accepted.
Do we need to publish the app on the public app stores?
Not necessarily. Internal apps can be distributed through Apple Business Manager and managed Google Play, so only your reps can install them, while still getting store-managed updates.
Talk through your field sales app
If you have a rough feature list and know which ERP you run, we can tell you which stack fits and what a fixed-price build would include. Book a 30-minute call.
Need this built? Our team does fixed-scope mobile app development — scoped, priced and delivered in weeks.