Engineering Real-Time Mobile Personalization Across iOS, Android, React Native, and Flutter

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.

What is your team’s mission, and what made engineering real-time mobile personalization feel nearly impossible?

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 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.

What made cross-platform mobile personalization difficult across iOS, Android, React Native, and Flutter?

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.

With mobile campaign changes potentially requiring another app release, how did you separate app instrumentation from experience configuration?

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.

What made dynamic native mobile rendering within limited screen space so difficult?

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.

What complicated real-time identity resolution across web, mobile, and email?

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.

How did you preview and test personalized mobile experiences without rebuilding apps or creating fake customer data?

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.