What You'll Learn
When the standard Salesforce Mobile App is insufficient, what the Mobile SDK provides over and above it, the SmartStore offline data architecture, Mobile SDK authentication patterns, and the decision framework for native vs standard mobile.
The Standard Mobile App vs the SDK
Salesforce provides two mobile paths. The standard Salesforce Mobile App is a pre-built iOS and Android application that renders your Salesforce org's Lightning Experience inside a native shell. It requires zero mobile development — configure Lightning App Builder and the mobile app is ready. For the majority of internal CRM use cases, it is the right answer.
The Salesforce Mobile SDK is a set of iOS (Swift/Objective-C), Android (Java/Kotlin), and React Native libraries that allow developers to build custom mobile applications that connect to Salesforce. SDK apps can have fully custom UIs, offline capabilities, access to device hardware (camera, GPS, biometrics), and app store distribution independent of Salesforce's release cycle.
SmartStore: Offline Data Architecture
The most powerful feature of the Mobile SDK is SmartStore — an encrypted, on-device SQLite database that stores Salesforce data for offline access. SmartSync sits on top of SmartStore and handles the bidirectional sync between the device and Salesforce when connectivity is restored.
The SmartStore architecture:
- Soups: Collections (analogous to database tables) in SmartStore. Each soup stores JSON objects that can be indexed and queried via SmartSQL.
- SmartSync: The sync manager that fetches records from Salesforce via the REST API and stores them in SmartStore. It tracks dirty (modified) records locally and syncs them back to Salesforce when online.
- Conflict resolution: SmartSync detects when a local modification conflicts with a server-side change. The default policy is server-wins; custom policies can implement merge logic.
// SmartStore Soup registration (iOS Swift)
func registerSoups() {
let soupSpec = SoupSpec(name: "accounts",
features: [.externalStorage])
let indexSpec = [
IndexSpec(path: "Id", type: .string),
IndexSpec(path: "Name", type: .fullText),
IndexSpec(path: "LastModifiedDate", type: .string)
]
store.registerSoup(soupSpec, withIndexSpecs: indexSpec,
error: nil)
}
// Syncing from Salesforce
let target = SoqlSyncDownTarget.newSyncTarget(
"SELECT Id, Name, Phone FROM Account LIMIT 10000")
let options = SyncOptions.newSyncOptions(
forSyncDown: MergeMode.leaveIfChanged)
SyncManager.sharedInstance()?.syncDown(
target: target, options: options, soupName: "accounts",
update: { state in
if state?.isDone() == true {
print("Sync complete: \(state!.totalSize) records")
}
}
)Authentication: Connected App and OAuth Flow
Mobile SDK apps authenticate via a Connected App in Salesforce, using the OAuth 2.0 User Agent flow or the OAuth 2.0 Web Server flow (for server-side code). The SDK handles the token management lifecycle:
- Redirect to the Salesforce login page (or Identity Provider) on first launch
- Exchange the OAuth code for an access token and refresh token
- Store the refresh token securely in the device Keychain (iOS) or Keystore (Android)
- Automatically refresh the access token when it expires without user intervention
For customer-facing apps, consider using Salesforce's External Identity licence (formerly Community licence) rather than full Salesforce licences. External Identity is significantly cheaper for high-volume consumer apps.
When Native SDK Is Justified
Build with the Mobile SDK when at least two of these conditions are present:
- Custom brand experience: The mobile app needs to look nothing like Salesforce — matching your product's visual identity is critical
- Offline-first requirement: Field workers, logistics operators, or others who work in locations with unreliable connectivity
- Device hardware access: Camera (photo capture, QR scanning), GPS (location tracking), biometrics (secure sign-in), push notifications with custom payload handling
- Customer-facing distribution: The app is published to the App Store / Play Store for external users who should not interact with Salesforce's standard interface
- Performance-critical UX: The use case requires snappy native performance that web-based UI cannot match (real-time inventory scanning, high-frequency data entry)
Key Takeaways
- The standard Salesforce Mobile App covers 90% of internal CRM mobile use cases at zero development cost.
- The Mobile SDK is justified for custom-branded apps, offline-first requirements, device hardware access, and customer-facing distribution.
- SmartStore provides encrypted on-device storage (AES-256); SmartSync handles bidirectional sync with conflict detection.
- Device passcode enforcement is required for SDK apps with sensitive data — no passcode weakens SmartStore encryption.
- External Identity licences are significantly cheaper than full Salesforce licences for customer-facing SDK apps.
- Always prototype with the standard mobile app first before committing to SDK development.
Check Your Understanding
1. A field service team works in underground facilities with no connectivity. They need to create work orders and capture photos offline, syncing when they return to connectivity. Which mobile approach is required?
2. What encryption standard does SmartStore use to protect on-device data?
3. A company wants to build a customer-facing mobile app for 500,000 consumers. They plan to license each consumer as a full Salesforce user. What should the architect recommend instead?
Discussion & Feedback