Visit Website →
← Back to blog

Salesforce Mobile Integration for UK Agencies: 5 ECA Steps

October 14, 2026
Salesforce Mobile Integration for UK Agencies: 5 ECA Steps

Start with the Salesforce Mobile SDK and build your authentication on an External Client App using PKCE: that combination is now the recommended foundation for any new Salesforce mobile project. For offline-first apps, build on Mobile Sync rather than raw REST calls. Clone a sample app from the Salesforce GitHub organisation or create an External Client App in your org today, then follow the developer guide and Trailhead modules for the rest.

TL;DR:

  • Existing connected apps keep working, but Salesforce restricts new creation; update the consumer key and redirect URI, then test old token refresh in a full sandbox.
  • For offline edits, use Mobile Sync with encrypted SmartStore; partition large datasets into named stores and index frequently queried fields to keep lookups fast.
  • Choose native templates for performance and device features, React Native to share JavaScript across platforms, or Cordova when extending an existing web app.
  • Do not enforce authentication changes in production until the supporting app version reaches most users; stage releases and monitor login and sync errors.
Pocketapp
Build a Salesforce mobile app
Pocket App designs, develops and deploys tailored mobile apps, drawing on experience across more than 300 projects.
Explore Pocket App

Table of Contents

What the Mobile SDK gives you

The Salesforce Mobile SDK supports several templates, and the right one depends on your team's skills and your performance needs. It offers native iOS and native Android templates for teams that need full platform control, a hybrid Cordova template for teams with existing web code, and React Native templates for teams wanting a single JavaScript codebase across platforms.

Inside each flavour you get the same core modules:

  • Authentication helpers that manage OAuth flows and token storage.
  • REST API wrappers for querying and updating Salesforce records.
  • SmartStore, an encrypted local database for offline data.
  • Mobile Sync, which handles bi-directional synchronisation between the device and your org.
  • Push notification hooks for real-time updates.

Native templates tend to win on performance and access to platform-specific features such as camera or biometric APIs. React Native suits teams that already maintain a JavaScript stack and want to share logic across iOS and Android. Hybrid apps remain a reasonable fit when you are migrating an existing web app and need offline capability without a full rewrite.

Authentication and Spring '26 changes: ECA, PKCE and token migration

Salesforce's Spring '26 release changed how new mobile integrations should authenticate. From that release, new connected apps can no longer be created for most use cases: Salesforce instead recommends External Client Apps (ECAs) for new projects. Existing connected apps keep working, but any new mobile integration should start on an ECA.

PKCE (Proof Key for Code Exchange) is now mandatory for public mobile clients. In practice, this means your app exchanges an authorisation code for a token using a dynamically generated code verifier rather than a stored client secret, which matters because a mobile app can never keep a secret safe on the device.

A practical migration checklist:

  1. Create or migrate your app's configuration to an External Client App.
  2. Enable PKCE in the OAuth settings for the ECA.
  3. Update your mobile app's consumer key and redirect URI to match the new ECA configuration.
  4. Test the refresh token flow end to end, including what happens to tokens issued under the old connected app.
  5. Roll out to a pilot group before a full release, watching for authentication errors.

Pro Tip: Test your refresh token migration in a full sandbox before touching production; a broken refresh flow logs every user out at once.

Offline-first patterns: SmartStore, Mobile Sync and performance

Offline reliability is usually the hardest part of a Salesforce mobile project, and SmartStore and Mobile Sync exist to solve it together rather than separately. SmartStore stores records locally in "soups", encrypted using SqlCipher, so cached Salesforce data stays protected even if a device is lost or stolen.

Mobile Sync sits on top of SmartStore and manages the sync-down and sync-up operations: pulling records from Salesforce into the local store, and pushing local changes back up when connectivity returns. Reach for Mobile Sync whenever your app needs frequent offline edits; for simpler, read-mostly screens, direct REST calls can still be the lighter option.

A few patterns keep performance solid at scale:

  • Partition large datasets across multiple named SmartStore instances rather than one large store.
  • Index soups correctly on the fields you query most, which keeps lookups fast as data grows.
  • Batch sync operations instead of triggering many small syncs.
  • Use MobileSyncSDKManager as your entry point, particularly where the app supports multiple users switching accounts on one device.

Partitioning large datasets into multiple named SmartStore instances improves query performance compared with a single large store, which matters once field teams start carrying tens of thousands of offline records.

Installation, starter apps and learning resources

The fastest route to a working prototype is to start from an official template rather than from scratch. You have two realistic install paths: cloning a sample app directly from the Salesforce Mobile SDK developer centre on GitHub, or scaffolding a new project using the npm and CLI templates.

For a first build, pick the sample that matches your priority:

  • An authentication-focused sample if your main concern is getting ECA and PKCE working correctly.
  • An offline-focused sample if your app's core job is capturing data in the field without signal.
  • A UI-embedding sample if you are adding Salesforce data into an existing app rather than building new screens.

Trailhead carries structured trails for Mobile SDK fundamentals, and the GitHub sample repos are kept current with each SDK release, which makes them a safer reference than older blog tutorials.

Integration patterns: UI embedding, APIs or third-party channels

Not every Salesforce mobile project needs a full app. UI embedding lets you drop Salesforce screens directly into an existing app using lightning-ui-embedding, while data-level integration through REST or the Mobile SDK gives you full control over the interface and lets you build a native experience from the ground up.

Within UI embedding, you choose between two paths:

  • With a Salesforce package: faster setup, a typed and supported API, less flexibility.
  • Without a package: you implement the sf-embedding protocol manually, which takes longer but avoids an extra dependency and gives full control over behaviour.

Messaging and Interaction Service integrations sit alongside these patterns rather than replacing them, and whichever path you choose, your ECA still carries the responsibility for authenticating the session correctly.

Pro Tip: Choose the packaged embedding path first; drop to the unpackaged protocol only once you hit a specific limitation the package can't solve.

Troubleshooting and common pitfalls

Most mobile Salesforce problems trace back to a handful of causes, and checking them in order saves time.

  1. Check device time first when authentication fails: a mismatched device clock is one of the most common causes of login errors, alongside MFA configuration issues that may need an authenticator reset.
  2. Verify redirect URIs and callback configuration match exactly between your app and the ECA, since a mismatch here is a frequent cause of login loops; our redirect URI mismatch guide covers the checklist in more depth.
  3. Test token expiry handling explicitly, including what the app does when a refresh token has been invalidated by an ECA migration.
  4. Run full offline test passes, including airplane-mode scenarios and sync conflict handling, before every release.
  5. Test multi-user switching on a single device if your app supports it, since cached sessions can bleed between users if SmartStore partitioning is wrong.

Our guide to MFA and recovery flows is worth a read if authentication keeps surfacing in your bug tracker.

User experience considerations specific to Salesforce mobile integration

A technically correct Salesforce mobile integration can still feel clumsy if the user experience ignores how field and sales teams actually work. Sync status needs to be visible and honest: users should always know whether a record saved locally, is queued for sync, or has actually reached Salesforce, because silent failures erode trust in the app faster than almost anything else.

Login friction matters more on mobile than on desktop. Every extra tap in an OAuth flow, particularly one involving MFA, costs more on a small screen than at a desk, so the authentication screens deserve as much design attention as the main app.

Offline states need their own design treatment rather than a generic spinner. A field rep filling in a form with no signal needs clear confirmation that their entry is safe locally, and clear feedback once it has synced. Conflict resolution screens, when two edits clash during sync-up, should explain the conflict in plain language rather than surfacing raw field values.

Performance perception matters as much as actual speed. SmartStore queries that are correctly indexed feel instant; unindexed queries against a large soup can introduce visible lag that users read as the app being broken rather than the data layer being slow. Push notifications should be used sparingly and only for events the user genuinely needs to act on, since over-notifying is one of the fastest ways to get a business app muted or uninstalled.

Deploy and update processes for Salesforce mobile apps

Deployment for a Salesforce-connected mobile app runs on two parallel tracks: the mobile app binary and the Salesforce-side configuration. Mobile builds go through the usual App Store and Google Play review processes, which means authentication or API changes need enough lead time to clear review before an org-side change goes live and breaks the old build.

On the Salesforce side, ECA and connected app settings, permission sets and API versions can change independently of the mobile release cycle. A practical rule: never flip an authentication setting such as PKCE enforcement in production until the mobile app version that supports it has had time to reach the majority of your user base.

Staged rollouts help manage this gap. Releasing to a small percentage of users first, watching for authentication or sync errors, then expanding catches configuration mismatches before they reach everyone. For enterprise deployments, mobile device management policies often control which app versions are permitted, which gives you another lever to force older builds off devices once an ECA migration is complete.

Update cadence should match how often your org's integration layer changes. An app that only reads static reference data can update rarely; one tied closely to evolving Salesforce automation and sync logic needs a tighter release rhythm, often supported by continuous deployment practices that get fixes to users quickly without a lengthy manual release process each time.

Deploy and update processes for Salesforce mobile apps — overview diagram

Case studies and examples across industries

Salesforce mobile integration patterns show up differently depending on the sector, even though the underlying SDK and sync mechanics stay the same. In retail, mobile apps built against Salesforce commonly serve store associates who need offline-capable stock lookups and customer records, with SmartStore caching product and loyalty data so lookups work even on a poor in-store signal.

In healthcare, mobile integrations tend to centre on care coordination and patient engagement rather than raw data entry, with particular attention paid to encrypted local storage and strict authentication given the sensitivity of patient data. In charity and nonprofit contexts, field teams collecting donor or beneficiary information in areas with little connectivity rely heavily on Mobile Sync's offline queuing to make sure nothing is lost between visits and head office systems.

Recruitment and B2B operational tools often lean more on UI embedding, surfacing Salesforce records inside an existing internal app rather than building a new one from scratch, which keeps teams working in a single tool. Across all these sectors, the common thread is the same: the sector changes what data matters, but the architecture question, whether to embed, sync offline or call the API directly, stays consistent.

Case studies and examples across industries — overview diagram

Pocket App's approach to Salesforce mobile projects

We run every Salesforce mobile project through the same Discover, Design, Develop and Deploy cycle we use across our wider enterprise mobile app work, with discovery used specifically to decide which Mobile SDK flavour and sync approach fits the client's scale and existing systems. For a field sales team needing heavy offline capability, we lean on Mobile Sync and SmartStore from day one; for a lighter internal tool, a simpler API-led build often serves the business better.

Across numerous projects spanning retail, charity, healthcare and B2B sectors, our strategic discovery process and in-house UX/UI design work shape the technical recommendations we put forward, rather than defaulting to one architecture for every client.

— Paul

How we can help with your Salesforce mobile integration

We handle the parts of a Salesforce mobile project that tend to slow teams down: migrating authentication to External Client Apps with PKCE, designing offline-first apps around SmartStore and Mobile Sync, and the UX decisions that decide whether field staff actually use what gets built.

Pocketapp

If you are weighing up Mobile SDK options or need a second opinion on an ECA migration, book a Mobile App Clinic for a focused technical look at your project, or start with our discovery process if you are scoping a new build from the ground up.

FAQ

What is the Salesforce app used for?

The standard Salesforce mobile app gives users access to their Salesforce data, dashboards and workflows from a phone or tablet without any custom development. It suits teams who need standard Salesforce objects and reports on the go, whereas a custom Mobile SDK app is built when you need offline-first behaviour, a bespoke interface or embedded Salesforce data inside another app.

What are the different integration options available for Salesforce?

Salesforce mobile integration generally falls into two patterns: data-level integration through REST APIs or the Mobile SDK, and UI-level integration through embedding Salesforce screens directly into another app. The right choice depends on whether you need full control over the interface or a faster, supported way to surface existing Salesforce screens.

In which two ways can users access Salesforce from their mobile devices?

Users typically access Salesforce on mobile either through the standard Salesforce mobile app, which works out of the box with no custom development, or through a custom app built with the Salesforce Mobile SDK that connects to Salesforce via REST APIs and Mobile Sync. Both routes use the same underlying authentication and data layer.

Why can't I log into Salesforce on my phone?

Login failures on mobile are most often caused by a mismatched device clock or an incorrectly configured multi-factor authentication setup; syncing the device's time and checking the authenticator registration resolves most cases. Redirect URI mismatches after an External Client App migration are another common cause worth checking if the problem started after a recent update.

What's changing with Salesforce mobile authentication in 2026?

From Spring '26, Salesforce has restricted the creation of new connected apps and now recommends External Client Apps with PKCE enabled for any new mobile integration. Existing connected apps keep working, but new projects should migrate to an ECA and test their refresh token flow before relying on it in production.

Sources