Engineering MOD Smart: A Deep Dive into React Native Tuya Integration

Building a lighting control application goes beyond simple on/off switches. It requires orchestrating low-latency state management, complex hardware pairing flows, and a scalable UI architecture that can handle multi-home hierarchies.

MOD Smart represents our latest iteration in solving these challenges. Built on React Native 0.76.5, it is a cross-platform solution designed to manage Tuya-compatible lighting hardware. This article explores the architectural decisions, from the Zustand state slices to the specific navigation stacks that power our secure, real-time control system.

Overview: The Mission

The core directive of MOD Smart is to provide professional-grade control for RGB, CW, and RGBCW lighting controllers. Unlike generic smart home apps, MOD Smart is tailored for installers and power users. It prioritizes:

Multi-Home Context: Seamless switching between client sites or properties.
Real-Time Feedback: Utilizing MQTT via the Tuya SDK to ensure UI states reflect physical device status instantly.
Cross-Platform Parity: A unified codebase delivering identical performance on iOS and Android.

Authentication & Session Security

We moved away from persistent logins in favor of a secure, session-based approach. The flow utilizes Email/OTP (One-Time Password) for verification. Upon successful validation, session tokens are encrypted and stored via react-native-keychain. This ensures that sensitive user data remains protected even if the device is compromised.

The Home Hierarchy

The application logic revolves around the activeHomeId. This ID is persisted in local storage, allowing the app to "remember" the user's last visited location. The hierarchy is structured as:

Home: The root entity (e.g., "Client Residence").
Room: Logical groupings (e.g., "Living Room").
Device: The physical controller.

Device Control UI

The control surface is the heart of the app. We map Tuya DP (Data Point) codes directly to UI elements. Whether the connected device is a simple White (CW) strip or a complex RGBCW unit, the UI adapts dynamically.

Interaction: We utilize @gorhom/bottom-sheet for non-intrusive management. Renaming, deleting, or toggling device settings happens in a modal overlay, keeping the user in context.
Firmware: Dedicated DeviceInformation and DeviceSettings screens handle OTA (Over-The-Air) updates, checking against Tuya’s cloud services for version parity.

Universal Pairing Flows

Hardware onboarding is notoriously difficult. MOD Smart implements three distinct pairing strategies to ensure success:

Wi-Fi EZ Mode: Rapid smart configuration.
AP Mode: Access Point mode for difficult network environments.
Bluetooth LE Scanner: Automatic discovery of nearby localized devices.

Note: We leverage MQTT feedback loops during pairing to confirm device registration before the UI transitions, preventing "ghost" devices.

Logic & Automation

Scenes & Schedules: Users can define color presets and automated timing rules stored on the device MCU.
Strip Configuration: Users can adjust strip lengths programmatically, affecting the pixel density logic sent to the controller.
Grouping: Devices can be clustered for synchronized control.

RBAC (Role-Based Access Control)

To support multi-user environments (e.g., installers vs. homeowners), we implemented a permission system.

<Can> Component: A wrapper component that conditionally renders UI elements based on the user's role.
useHomePermissions: A custom hook that validates actions against the centralized helper logic before dispatching API calls.

Theming

The UI is built with NativeWind, allowing utility-first styling. Combined with a theme slice in our state store, this enables a robust Dark Mode that toggles instantly across the entire application without reload.

Architecture: Navigation Strategy

We utilize a nested stack pattern to maintain history and prevent "navigation loops."

RootNavigator: The entry point handling Auth vs. App states.
MainTabs: The primary dashboard (Home, Scenes, Settings).
ControllerStack: A dedicated stack for deep device interaction.

Why this matters: By decoupling the Controller flow, we avoid duplicate screens in the memory stack. A user navigating deep into a device setting can pop back to the root instantly.

State Management: Zustand

We selected Zustand for its minimal boilerplate and ability to handle transient updates without re-rendering the entire tree.

auth slice: Manages tokens and user profile data.
device slice: Handles the real-time map of DP codes and device status.
theme slice: Persists user preference (System/Light/Dark).
bottomSheet slice: centralized control for global modals.

Publishing to Play Store and App Store

The path to production was remarkably smooth, with our robust codebase passing Google Play’s review on the first attempt. However, our initial iOS submission encountered a single, valid rejection: Apple’s strict guideline requiring an in-app "Delete Account" flow for any platform supporting user registration.

This minor hurdle became a testament to our architecture's agility. Because our authentication logic was centralized within a dedicated Zustand slice, we were able to implement the UI, wire up the API endpoint, and validate the token cleanup logic in under five minutes. We resubmitted the build immediately, securing approval shortly after without further issues.

We use Fastlane to fully automate our mobile deployment pipeline across iOS and Android. For Android, Fastlane triggers a Gradle Release bundle and uploads it directly to the Google Play Internal Test Track as a draft release. For iOS, our lane automatically bumps the version and build numbers, builds the app through the Xcode workspace, and publishes the artifact to TestFlight. This setup ensures consistent versioning, reproducible builds, and seamless distribution to internal testers with a single command.

IOS Link - Play Store Link