Skip to main content

​
Enabling SDK logging

The Desmo iOS SDK includes lightweight logging to help you understand what it’s doing. Logging is controlled by the loggingEnabled flag on DesmoConfig, which defaults to true. When enabled, the SDK prints messages such as:
  • When Desmo.setup succeeds or fails.
  • When sessions start and stop.
  • When HTTP requests are sent and responses are received.
Example: 
Desmo.setup(
    key: "pk_sandbox_XXXXXXXXXXXXXXXX",
    environment: .sandbox
    // loggingEnabled defaults to true
)
You will see messages like: 
[DesmoSDK] Setup successful pointing to: https://api.getdesmo.io
[DesmoSDK] Starting session for delivery: DELIVERY_123
[DesmoSDK] Session started successfully
To turn logging off (for example, in production builds), you can expose a wrapper in your app that constructs DesmoConfig with loggingEnabled: false.

​
Where logs appear

Logs are printed using print, so they show up in:
  • Xcode’s Debug area when you run the app from Xcode.
  • Device logs when attached to Xcode or collected via your logging pipeline.
During integration, keep logging enabled in sandbox builds so you can verify what the SDK is doing.

​
Debugging common issues

​
1. Desmo shared is nil

Symptom:
  • Your code prints "Desmo SDK is not configured" from guard let client = Desmo.shared else { ... }.
Checklist:
  • Ensure Desmo.setup is called:
    • Exactly once.
    • Early in the app lifecycle (e.g. in @main app init or AppDelegate).
  • Confirm the key starts with pk_ and is not empty.
  • Look for a log like: 
    [DesmoSDK] Setup failed: invalidApiKey
If setup fails, fix the key and rebuild.

​
2. Session start fails

Symptom:
  • startSession throws an error.
  • You may see an HTTP status code in logs, for example: 
    [DesmoSDK] Response: 401
[DesmoSDK] Error Body: ...
Checklist:
  • Confirm the publishable key you are using is:
    • Valid and not revoked.
    • Created for the environment you selected (sandbox vs live).
  • Confirm the device has network connectivity.
  • Check your backend/logs for more detailed error messages tied to that key.

​
3. Session stop fails

Symptom:
  • stopSession throws an error.
What the SDK does:
  • Flushes telemetry via telemetry.flush() and telemetry.stop() before notifying Desmo’s backend that the session should stop.
  • If the network call fails, it keeps the internal state as recording so you can retry stopSession().
Checklist:
  • Try stopping again once connectivity is restored.
  • Inspect logs for HTTP status codes or network errors.

​
4. No data appears in Desmo

Symptom:
  • startSession and stopSession succeed, but you don’t see sessions/insights in Desmo.
Checklist:
  • Confirm you are using the same environment and tenant as the dashboard you’re looking at.
  • Check for any rate limiting or 4xx/5xx errors in the logs.
  • Share session IDs from your logs with the Desmo team to trace them end-to-end.

​
Integration checklist

Use this as a quick pre-flight check before shipping:
  1. Setup
    • Desmo.setup is called exactly once at app startup.
    • You use a publishable key starting with pk_.
    • The environment (.sandbox / .live) matches the keys you created.
  2. Session lifecycle
    • startSession is called when a delivery begins.
    • stopSession is called when the delivery completes.
    • Both calls succeed without throwing in your test flows.
  3. Logging
    • Logging is enabled in sandbox builds.
    • You can see Desmo SDK logs in Xcode when starting and stopping sessions.
  4. Backend visibility
    • You can see created sessions in the Desmo dashboard or API using the same environment and tenant.
If any box is unchecked, fix that item before rolling out broadly to drivers.