Workspace ONE SDK Integration for Mobile Apps
You have a thousand Zebra Android devices on the warehouse floor and a hundred iPads with your management team. Each app demands individual settings, security policies must be centrally enforced, and every device needs to comply with corporate standards. VMware Workspace ONE (formerly AirWatch) is an enterprise mobility management (EMM) platform that combines MDM, MAM, identity, and zero-trust access. Unlike Intune, Workspace ONE provides deeper MDM capabilities for Android devices and native support for rugged hardware. Our team brings 10+ years of mobile development experience and has integrated EMM solutions for over 50 corporate clients. We ensure your app runs seamlessly and securely under this platform.
Problems We Solve
Integrating MDM into your app is rarely plug‑and‑play. Typical issues include:
- Enrollment fails because of incorrect provisioning profiles.
- Policies don't apply without properly configured APNs (iOS) or FCM (Android).
- DLP rules block legitimate workflows—copy‑paste between approved apps, URL sharing, or screenshots.
We tackle these at the SDK level, eliminating lengthy back‑and‑forth with WS1 administrators.
How Workspace ONE SDK Works
The Workspace ONE SDK is similar to Intune MAM SDK but has its own API and lifecycle. Key components:
- AWSDKCore – handles policy processing and authentication via Workspace ONE Intelligent Hub.
- AWContentLocker – secure file storage.
- AWNetworkKit – managed networking through Workspace ONE Tunnel (per‑app VPN).
- AWDataLoss – intercepts clipboard, file sharing, and screenshots.
On iOS, the SDK is installed via CocoaPods or SPM:
pod 'AWSDK', '~> 25.0' On Android, via Maven:
implementation 'com.vmware.ws1.android:airwatchsdk:25.0.0' According to VMware Workspace ONE SDK documentation, AWController initialization must be called in application:didFinishLaunchingWithOptions:.
iOS Initialization and Enrollment: Step by Step
The Workspace ONE SDK requires the Workspace ONE Intelligent Hub app on the device. Hub acts as a broker between your app’s SDK and the WS1 server. Without Hub, the SDK cannot receive policies.
- Add AWSDK via CocoaPods or SPM.
- Import the AWSDK module in AppDelegate.
- Call
AWController.clientInstance().startinapplication(_:didFinishLaunchingWithOptions:). - Handle errors in the completion closure.
- After a successful start, apply the managed configuration from the SDK Profile.
Example code:
import AWSDK class AppDelegate: UIResponder, UIApplicationDelegate { func application(_ application: UIApplication, didFinishLaunchingWithOptions options: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { AWController.clientInstance().start { error in if let error = error { // enrollment failed print("WS1 SDK error: \(error.localizedDescription)") } else { // Policies applied, app now runs in managed mode self.applyManagedConfiguration() } } return true } private func applyManagedConfiguration() { let profile = AWController.clientInstance().sdkProfile() let serverURL = profile?.customPayloadProfile?.payload?["BackendURL"] as? String AppConfig.shared.backendURL = serverURL ?? AppConfig.defaultBackendURL } } AWController.clientInstance().start is asynchronous. The app should show a splash screen while the SDK initializes and fetches policies. If the device is not enrolled in WS1, Hub launches the enrollment flow.
Custom Payload: Pushing Configuration to Your App
Custom Payload injects configuration into your app via the SDK Profile. It’s analogous to Managed App Configuration in Apple MDM, but administered through the WS1 console. Example Swift reading:
let sdkProfile = AWController.clientInstance().sdkProfile() guard let customPayload = sdkProfile?.customPayloadProfile?.payload else { return } let backendURL = customPayload["BackendURL"] as? String let featureFlags = customPayload["FeatureFlags"] as? [String: Bool] let sessionTimeout = customPayload["SessionTimeoutMinutes"] as? Int ?? 30 In the WS1 console, Custom Payload is defined as XML or JSON in Apps → SDK Profiles → Custom Settings. Changes apply at the next check‑in (typically every four hours).
Custom Payload parameters can be described in a table:
| Key | Type | Description |
|---|---|---|
| BackendURL | String | URL of the corporate backend |
| FeatureFlags | Dict | Enable/disable application features |
| SessionTimeoutMinutes | Integer | Session timeout in minutes |
Per‑app Tunnel: Managed Network Traffic
Per‑app VPN through Workspace ONE Tunnel provides an additional secure channel. Traffic from a specific app is tunneled through the corporate gateway without requiring a global VPN profile. To enable Tunnel in your app, add AWNetworkKit and configure the URL session:
import AWNetwork // Replace standard URLSession with Tunnel-aware configuration let tunnelConfig = URLSessionConfiguration.default AWNetworkKit.shared.configureTunnel(for: tunnelConfig) let session = URLSession(configuration: tunnelConfig) The Tunnel operates transparently — your app makes normal URLSession requests, and the SDK redirects them through the VPN. No changes to URLRequest or headers are needed.
Why Custom Payload Matters for Configuration
Without Custom Payload, every app would have to be recompiled whenever the backend URL or feature flags change. Custom Payload lets administrators update settings on the fly through the WS1 console; the app picks them up after the next check‑in. This cuts rollout time from days to hours. On a recent project for a logistics company with 2,000 Zebra devices, we used Custom Payload to push new backend endpoints and feature toggles across the fleet in under 24 hours — with zero app updates.
DLP Policies Out of the Box
The SDK provides ready‑to‑use data loss prevention. For example, when copy‑paste to other apps is forbidden, we clear the clipboard on every foreground event; when screenshot detection is enabled, we overlay a blank screen. Policies are set in the console and applied automatically, reducing operational overhead.
Process of Evaluation and Work
We don’t offer a fixed price because every integration is different. Here’s how we work:
- Discovery — we review your current app architecture, WS1 environment, and security requirements.
- Analysis — identify which SDK components (Core, Content Locker, Tunnel, DLP) are needed.
- Design — define the SDK Profile with Custom Payload mapping and enrollment flow.
- Estimate — after analysis, we give you a clear timeline and cost.
- Implementation — add AWSDK, implement lifecycle, map Custom Payload, configure Tunnel and DLP.
- Testing — on managed devices (both Android and iOS), including edge cases like lost connectivity.
- Rollout — staged deployment with monitoring and documentation.
Timelines
Basic SDK integration with Custom Payload — 3–4 weeks. A full project including Tunnel, DLP, multiple policies, and thorough testing — 6–10 weeks. Costs are determined after the discovery phase.
Typical Mistakes and How to Avoid Them
- Missing Hub dependency — Hub must be installed on the device; otherwise enrollment fails silently.
- Incorrect APNs/FCM setup — push notifications for policy updates won’t work, causing stale configurations.
- Overlooking check‑in intervals — policy changes via Custom Payload are not instant; plan for 4‑hour delays or trigger a manual check‑in.
- Ignoring DLP impact — if your app shares data with other apps via UIActivityViewController or similar, those flows may break under strict DLP. Test early.
Get a consultation — contact us, we’ll evaluate your project, propose an optimal solution, and deliver a seamless integration with quality assurance.







