This architecture solves the 'mobile release bottleneck' by decoupling UI instrumentation from campaign logic. It enables real-time, cross-platform personalization at scale while maintaining native performance and visual stability across fragmented technology stacks.
In our Engineering Energizers Q&A series, we highlight the engineering minds driving innovation across Salesforce. Today, we spotlight Sneha Singla, a director of software engineering, whose team confronted a brutal engineering contradiction: making one real-time mobile personalization architecture work across four fundamentally different technology stacks without breaking native layouts, corrupting customer identities, exposing unnecessary profile data, or requiring a new app release whenever a marketer changed a campaign.
Explore how Sneha’s team engineered cross-platform mobile personalization across iOS, Android, React Native, and Flutter, helping an early customer implement it in two months and generate more than 150 million decisions within three weeks.
The nightmare was not one difficult mobile engineering problem. It was that a failure anywhere, whether identity resolution, framework integration, native rendering, consent, or deployment, could show the wrong experience, destabilize the app, or make personalization disappear when a customer changed channels.
The team had to solve six problems simultaneously:
The mission was to bring the web’s profile-driven personalization into native mobile apps without creating another channel silo. A customer could browse Italian food on a website, open the brand’s app seconds later, and receive a generic experience because their context had not followed them. They had changed screens, but the brand had effectively forgotten them. The goal was a build-once, deploy-anywhere model that delivered real-time mobile personalization while preserving developer control over native components and allowing marketers to manage experiences dynamically across channels.
The challenge was making one mobile personalization architecture behave consistently across technologies with different rendering and application lifecycle models. iOS and Android rely on native networking, UI, and secure storage, while React Native and Flutter introduce bridge layers, caching behavior, dependencies, and additional risks.
In response, the team established consistent schemas, event semantics, identity behavior, fallback handling, and native rendering across all four technology stacks. Bridge layers were built that allowed React Native and Flutter to use the native APIs exposed through iOS and Android while maintaining a consistent set of SDK APIs for mobile personalization. This preserved a consistent platform model while accommodating each technology’s differences. Brands could configure a campaign once and implement mobile app personalization without maintaining separate iOS and Android experiences.
Mobile app release cycles make small campaign changes expensive. A change may require developers to modify the app, publish another version, and wait for customers to install it before receiving the new personalized experience.
The team separated mobile app instrumentation from experience configuration. Developers instrument the app once by creating stable placeholders, or content zones, and registering approved native components such as hero banners or recommendation carousels. They define where each component can appear and establish constraints that protect the layout. Marketers then use the Salesforce UI to configure templates, content, targeting, and component selection. The platform versions and publishes that mobile personalization metadata through a global CDN. When a user opens the app, the SDK retrieves the configuration, applies the targeting and mapping rules, and dynamically renders the appropriate native component.
This low-code mobile personalization architecture preserves developer control while allowing marketers to change campaigns without repeated code or platform-specific logic. An early customer implemented mobile personalization in two months without asking the team a single implementation question and generated more than 150 million decisions within three weeks.
A mobile interface cannot simply absorb another banner or recommendation carousel. The runtime must understand developer-defined placements, identify the highest-value personalized content for the user, and map it to an appropriate native mobile component without destabilizing the app. Dynamic mobile content rendering must also preserve responsiveness, accessibility, navigation, and visual stability across different screen sizes. Text cannot overlap, components cannot stretch unpredictably, and personalized content cannot obstruct how customers use the application.
The team addressed these constraints through four connected concepts. Developers register content zones as invisible containers and define the native mobile components allowed within them. Administrators create reusable visual and structural templates, while marketers create personalization experiences connecting those templates to real-time data, targeting logic, and specific content zones. This gives marketers flexibility within developer-established boundaries. The native mobile personalization design was refined through multiple iterations, applying lessons from the earlier Marketing Cloud Personalization mobile roadmap.
A person might browse anonymously on the web, interact with an email, explore products through a mobile app, and then authenticate through any channel. The platform must connect those anonymous interactions to the correct known customer profile regardless of where they originated. That real-time identity handoff created the greatest risk. Simultaneous data from multiple channels could produce race conditions, identity conflicts, duplicate histories, or incorrect profile merges. Supporting four mobile technology stacks multiplied that complexity.
The team used Data 360 identity resolution to stitch the interactions together. When an anonymous user authenticates, Data 360 merges their browsing and engagement history with the known profile so the same context can inform cross-channel personalization. The Salesforce Personalization mobile module sits on the Data 360 mobile SDK, which supports identity resolution and consent management. Decisioning and identity resolution were kept on the server side. The mobile SDK receives the decision and personalized experience to render instead of storing unnecessary raw profile attributes, simplifying the runtime while helping prevent duplicate histories, incorrect merges, and unnecessary on-device storage.
Traditional mobile personalization testing may require teams to rebuild the app, change configurations, push updates, or manufacture customer histories simply to verify targeting and native layout. The team created a QR-code preview flow that lets marketers select a personalized mobile experience and evaluate it against a specific individual. The mobile personalization simulator injects that person’s live profile attributes and real-time preferences, then uses the native renderer to show what the customer would see. Marketers can validate targeting, content, component selection, and layout without recompiling the app or constructing fake data. This shortens the mobile testing feedback loop and confirms that an experience fits the available screen space before launch.
Together, these capabilities make mobile part of the same continuously evolving cross-channel personalization experience. The architectural lesson is to instrument the app once, separate campaign configuration from application code, keep real-time identity resolution and decisioning on the server, and dynamically render only the native components developers have approved. That gives marketers control over mobile experiences while customer context follows each individual across channels in real time.
The post Engineering Real-Time Mobile Personalization Across iOS, Android, React Native, and Flutter appeared first on Salesforce Engineering Blog.
Continue reading on the original blog to support the author
Read full articleThis architecture demonstrates how to balance on-device processing with cloud AI to solve real-world data entry challenges. It provides a blueprint for building low-latency, high-accuracy mobile AI features that function reliably in noisy, bandwidth-constrained environments.
Standard RAG pipelines often fail in production because they strip semantic structure from complex documents. This framework helps engineers move beyond basic text retrieval to build trustworthy AI systems capable of handling real-world enterprise data with high accuracy.
Managing complex enterprise systems requires more than identifying errors; it requires context. This approach allows engineers to prioritize remediation by linking static configurations to real-world runtime behavior, reducing decision paralysis and improving system scalability.
Engineers often struggle with the unpredictable nature of LLMs in production. This architecture provides a blueprint for maintaining AI flexibility while guaranteeing reliability for regulated or mission-critical UI elements, ensuring compliance and a consistent user experience.
