- The three distinct paths for Salesforce mobile deployment and the architectural trade-offs of each
- What the standard Salesforce Mobile App can and cannot do — and where its ceiling is
- When the Mobile SDK is warranted and what building with it actually involves
- How Briefcase and SmartStore handle offline data synchronisation and the conflict resolution problem
- How to select the right mobile path for a given use case and user profile
The Mobile Landscape: Three Distinct Paths
Salesforce mobile architecture is not a single choice — it's a decision between three fundamentally different approaches, each with different architectural implications, team skill requirements, and capability ceilings.
Path 1: Salesforce Mobile App. Salesforce's own native iOS and Android app, available free to all licensed users. It renders Lightning pages, supports standard and custom Lightning components, and includes features like push notifications, location-based features, and offline via Briefcase. Configuration is done in Setup, no development required for basic deployment.
Path 2: Mobile SDK (Hybrid or Native). Salesforce's open-source SDK for building custom iOS and Android applications that connect to Salesforce. Hybrid SDK builds use Cordova/React Native and target developers with web skills. Native SDK builds use Swift/Kotlin and target native mobile developers. The SDK includes authentication (OAuth), offline storage (SmartStore), and data sync (MobileSync) as first-class capabilities.
Path 3: Experience Cloud Mobile Site. A Progressive Web App approach — building a mobile-optimised Experience Cloud site that users access via mobile browser. No app store distribution required, configuration-driven, but constrained to browser capabilities and no true offline support.
The choice between these three paths is irreversible without significant rework. Path 1 costs nothing beyond licensing but has a fixed capability ceiling. Path 2 requires mobile development investment but provides full control. Path 3 is fastest to deliver but permanently limited to browser capabilities. Make this choice deliberately — it shapes every subsequent mobile architectural decision.
Salesforce Mobile App: Capabilities and Ceiling
The standard Salesforce Mobile App is significantly more capable than most architects initially assume. It supports: all standard Lightning components, custom LWC components built for mobile, dynamic forms, quick actions, push notifications via connected apps, Einstein features, and — since 2022 — offline via Briefcase. For field sales, service technicians with basic data access needs, and mobile managers who primarily need visibility into CRM data, it often meets requirements without any custom development.
Where It Hits Its Ceiling
The ceiling becomes apparent when requirements include: complex offline data entry workflows (beyond the Briefcase model), device hardware integration (barcode scanners, industrial sensors, Bluetooth peripherals), deeply branded native UX that differs significantly from Salesforce's design language, very high performance requirements (the app renders Lightning pages which carry overhead), or integration with native device capabilities like augmented reality.
Architects frequently underestimate the standard app and build a Mobile SDK solution for requirements the standard app could meet, incurring 3–6 months of additional development cost. The evaluation should start with the standard app and work outward only when specific requirements demonstrably cannot be met.
Before committing to a Mobile SDK investment, build a prototype of your target user workflow in the standard app using Lightning pages and LWC. Test it with representative users in realistic conditions including poor connectivity. If 80%+ of requirements are met with acceptable performance, the remaining 20% may not justify a full custom build. Many organisations have discovered this after building an SDK-based app they didn't need.
Mobile SDK: When You Need Full Control
The Mobile SDK is warranted when requirements genuinely exceed the standard app's capabilities. The three most common justifications: complex offline workflows that go beyond Briefcase's record-level sync, deep device hardware integration (IoT sensors, scanners, cameras for document capture), and branded consumer-grade UX that the Lightning design language cannot accommodate.
The SDK provides three core capabilities beyond what a web application offers. SmartStore is an encrypted SQLite database on the device — data stored here persists without network connectivity and is cryptographically protected. MobileSync is the synchronisation framework that keeps SmartStore data consistent with Salesforce, handling incremental sync, conflict detection, and merge policies. SalesforceSwift/Cordova plugins provide native device capability access.
// SmartStore: querying offline data in a Mobile SDK app (JavaScript)
// SmartStore uses a JSON-based query language called SmartSQL
var querySpec = navigator.smartstore.buildSmartQuerySpec(
"SELECT {Accounts:Name}, {Accounts:Industry}, {Accounts:Id} " +
"FROM {Accounts} " +
"WHERE {Accounts:Industry} = 'Technology' " +
"ORDER BY {Accounts:Name} ASC",
100 // page size
);
navigator.smartstore.runSmartQuery(
false, // isGlobalStore
querySpec,
function(cursor) {
// cursor.currentPageOrderedEntries contains offline records
processOfflineAccounts(cursor.currentPageOrderedEntries);
},
function(error) { console.error("SmartStore query failed", error); }
);Briefcase: How Offline Sync Works in the Standard App
Briefcase, introduced in the Salesforce Mobile App in 2022, provides offline access to Salesforce records without custom development. Administrators define a "priming rule" — a set of records (e.g. "Accounts owned by the current user, modified in the last 30 days") — and Salesforce pre-downloads those records to the device. When connectivity is lost, users can view and edit the primed records. When connectivity is restored, changes sync back.
The offline data is stored encrypted on the device and managed entirely by the Salesforce app. Users don't configure what's available offline — administrators define the priming rules centrally.
The Conflict Resolution Problem
Offline architectures always have a conflict resolution problem: what happens when the same record is edited offline on a device and online by another user simultaneously? Briefcase's conflict resolution is "last write wins" — when the device syncs, if the record was modified on the server since it was downloaded, the offline edit is rejected and the user is notified. There is no merge capability for field-level conflicts.
For many use cases — a field rep updating notes on their own accounts — this is acceptable. For use cases where multiple users frequently edit the same records simultaneously, it's a significant limitation and a real source of data loss. Understand your conflict probability before committing to Briefcase as your offline solution.
A Briefcase priming rule that downloads too many records consumes excessive device storage and battery during sync. A rule that downloads too few means users hit "record not available offline" errors in the field. Priming rule design requires understanding your users' actual workflows — which records they access, how recently, how large the record set is. Get this wrong and offline functionality becomes a source of frustration rather than productivity.
Performance Considerations for Mobile
Mobile performance in Salesforce is primarily determined by three factors: network latency (cellular networks are significantly higher latency than office WiFi), Lightning page complexity (each component on a page makes separate data requests), and image and file sizes (photos attached to records can be megabytes each).
For the standard mobile app, performance optimisations include: reducing the number of components on Lightning mobile pages (design mobile pages separately from desktop, not as the same page), enabling offline Briefcase for frequently accessed records to eliminate network calls for common data, and compressing or resizing files before upload.
For SDK apps, performance considerations include SmartStore query optimisation (SmartSQL has different performance characteristics from SOQL — composite indexes help), MobileSync soup design (the data structures you sync matter for query performance), and minimising the volume of data pre-downloaded to the device.
The Decision Framework
Match the path to the use case and user profile systematically.
Standard Mobile App: Internal users, standard CRM workflows (sales, service, field ops basics), basic offline needs (record viewing, simple data entry offline), time-to-value is a priority, no mobile development resource available. This covers the majority of enterprise mobile Salesforce use cases.
Mobile SDK: Complex offline workflows (multi-record transactions while offline), hardware integration requirements, branded consumer-facing apps, very high performance requirements, dedicated mobile development team available, and timeline allows 3–6+ months of development.
Experience Cloud mobile site: Unauthenticated or lightly authenticated external users (customers, partners), no app store distribution possible, mobile-specific UX needed beyond the standard app, acceptable that offline is not supported. This is appropriate for customer portals and partner communities with mobile use cases.
If reliable offline functionality is a hard requirement — users in areas with no connectivity who must complete transactions without network — you need either Briefcase (for standard app) or SmartStore/MobileSync (for SDK). Experience Cloud mobile sites cannot provide true offline. If offline is a hard requirement and the standard Briefcase model doesn't fit your conflict patterns, the decision is made: you need the Mobile SDK.
Key Takeaways
- Three paths to Salesforce mobile exist: the standard app, the Mobile SDK (hybrid/native), and Experience Cloud mobile sites — each with distinct capability ceilings and investment requirements
- The standard Salesforce Mobile App supports Lightning components, push notifications, and offline via Briefcase — it meets the majority of enterprise mobile use cases without custom development
- Mobile SDK investment is justified by complex offline workflows, hardware integration, branded consumer UX, or very high performance requirements — not by limitations that can be addressed through configuration
- Briefcase provides declarative offline for the standard app but uses "last write wins" conflict resolution — evaluate conflict probability before committing to it as your offline model
- SmartStore is an encrypted local SQLite database; MobileSync handles bidirectional sync with conflict policies — together they form the SDK's offline architecture
- Mobile performance in Lightning is dominated by page complexity and network latency — design mobile pages separately from desktop pages with fewer components
- Start evaluation with the standard app and prototype your target workflow before committing to a Mobile SDK build
Checkpoint: Test Your Understanding
1. A field service team needs offline access to work orders while in areas with no connectivity. They also need to capture photos from industrial cameras integrated via Bluetooth. Which mobile path is appropriate?
2. What is Briefcase's conflict resolution model when a record is edited offline and also modified on the server before sync?
3. Why should mobile Lightning pages be designed separately from desktop Lightning pages?
Discussion & Feedback