eMeals is a long-running digital meal-planning and grocery-shopping platform. Its mobile experience helps customers discover meal ideas, manage current and previous shopping lists, add or edit grocery items, review meal recipes, print lists, and connect with grocery retailers. Over more than a decade the iOS application accumulated Objective-C, Swift, UIKit and SwiftUI, while Android combined Java, Kotlin, the View system and Jetpack Compose, so the two increasingly required separate engineering effort for the same product outcome.
The business problem was not simply old code. It was the cost, risk, and inconsistency created when the same customer experience had to evolve through different platforms, languages, data models, and release paths. The existing model did not fail because native technologies were incapable. It failed economically, since each new capability created two delivery streams and two maintenance surfaces.
Every meaningful feature had to be interpreted and implemented separately for iOS and Android. Two teams could start from one requirement and arrive at different interactions, edge cases, analytics, or release timing. Product managers then spent time reconciling parity and testing repeated equivalent scenarios across two independently evolving implementations.
iOS reflected Objective-C foundations, Swift additions, UIKit navigation, and SwiftUI views, while Android mixed Java, Kotlin, XML screens, and Compose. Hundreds of files across those generations still served live journeys, so small changes were hard to scope and a full rewrite would have risked years of validated behaviour and business continuity.
eMeals could not pause feature delivery or replace the native applications in a single release, since authentication, analytics, native navigation, printing, deep links, and grocery-retailer SDKs all had to keep working. The solution needed a brownfield path where new shared experiences coexist with legacy screens, launch behind an experiment flag, preserve native behaviour, and fall back safely if unavailable.
The proof of concept used the Shopping List rather than a disconnected demo because it touches API data, item actions, recipes, retailer connections, printing, authentication, analytics, and back behaviour at once. Testing the highest-risk ownership boundaries first exposed integration and performance gaps before further journeys were committed.
React Native owns migrated product UI, internal navigation, and client state, while the native hosts keep authentication, lifecycle, analytics transport, printing, and secrets. A typed, versioned bridge defines what each side may send, and the host exposes one stable entry route, so integration points stay few and ownership never becomes circular.
A migrated feature is now implemented once and delivered to both platforms through native packages, so product decisions, validation, error handling, and analytics are defined in a single place.
Feature parity becomes the default, since migrated workflows share business logic and UI behaviour. Native differences stay intentional and contract-driven rather than emerging from two builds.
Server-backed query state, runtime validation, controlled retries, loading skeletons, and explicit error states make behaviour easier for both customers and support teams to understand and predict.
Eternalight built a shared React Native module on React Native 0.85, React 19.2, TypeScript 5.9, and Expo SDK 56 with Expo Brownfield, embedded in the existing hosts. Axios, TanStack Query, and Zustand own data and state. Android packages a Maven AAR alongside Java, Kotlin, and Compose; iOS ships an XCFramework alongside Objective-C, Swift, UIKit, and SwiftUI.
Brainstorming
Wireframe
Development
Send us a message, and we’ll promptly discuss your project with you.
The legacy applications relied heavily on offline device storage and synchronization, so customers saw inconsistent results moving between devices or returning after data changed elsewhere. A local cache can improve convenience but cannot safely remain the primary truth for shared account data, which crosses the app and service boundary.
Separate stacks required dedicated iOS, Android, and service expertise, so work stalled when a specialist was unavailable and onboarding took substantial time. The same fragmentation limited AI-assisted development, since generated changes across eight or more platform conventions could mix patterns or miss implicit contracts entirely.
Remote data flows through endpoint configuration, adapters, repositories, and typed normalization, with Axios centralizing HTTP and TanStack Query owning caching, retry, and invalidation. Android publishes build-type-aware Maven artifacts and iOS a Swift Package, with size ceilings and native binaries isolated per platform.
The shared Shopping List launches behind an experiment flag with a controlled native fallback, and telemetry compares shared and legacy journeys rather than relying on anecdote. The codebase standardizes on TypeScript, explicit types, and co-located tests, giving AI tools better context while senior engineers retain architecture and release decisions.
User Feedback
Launch
Integration
React: A component‑based UI library for building fast, interactive web interfaces with a virtual DOM.
Type-safe frontend development for improved reliability and maintainability.
A robust, object‑oriented language running on the JVM for portable, enterprise grade applications.
Modern Android development and integration
Native iOS application integration
Mobile crash monitoring and diagnostics
