Implementing App Wrapping for Corporate Mobile Apps
App Wrapping is a post-build operation: take ready IPA or APK, wrap in MAM container without source code changes, get app with corporate security policies. Valuable for legacy apps, third-party vendor products, and situations with no source access.
When App Wrapping is Right Choice
MAM SDK integration is more reliable but requires code access and refactoring. App Wrapping fits when:
- App source code unavailable (vendor software, old app with departed team).
- App written in third-party framework incompatible with MAM SDK (some Xamarin, Cordova versions).
- Need to quickly add basic policies without full development cycle.
- App used by small number of employees; full SDK refactoring not cost-effective.
How Intune App Wrapping Tool Works on iOS
Microsoft provides IntuneMAMPackager—command-line tool for macOS:
./IntuneMAMPackager/Contents/MacOS/IntuneMAMPackager \
-i /path/to/app.ipa \
-o /path/to/wrapped-app.ipa \
-p /path/to/provisioning-profile.mobileprovision \
-c "Apple Distribution: Company Name (TEAMID)" \
-e /path/to/entitlements.plist \
--use-secondary-ipa-keychain-group true
Packager re-signs app, injects MAM frameworks into bundle, updates Info.plist with MAM keys. Result IPA contains IntuneMAMConfigurations.plist and injected frameworks in Frameworks/.
Automatically embedded:
-
UIPasteboardinterception—copy-paste policy restriction. -
UIDocumentInteractionController/UIActivityViewControllerinterception—"Open in..." restriction. - PIN/biometrics on launch by policy.
- Selective wipe on access revocation.
- File encryption in
Documents/andLibrary/directories.
App Wrapping Limitations on iOS
Wrapping isn't magic. Some SDK features become unavailable:
- Multi-identity — manage multiple corporate accounts in one app. Requires explicit SDK integration.
- Intune-targeted conditional launch checks — custom compliance logic. Unavailable without code.
- Custom wipe handler — wrapping deletes app files but can't call business logic cleanup (e.g., server deauth).
If app uses WKWebView for main UI—wrapping works worse: JavaScript content not intercepted. Need SDK integration or manual WKUserContentController restriction.
App Wrapping on Android
Intune App Wrapping Tool for Android:
java -jar IntuneMAMPackager.jar \
-i app-release.apk \
-o app-wrapped.apk \
-c RSA_KEY_ALIAS \
-ks keystore.jks \
-ksPass keystorePassword \
-alias keyAlias \
-aliasPass aliasPassword
Android wrapping works via bytecode instrumentation: tool rewrites Dalvik/ART bytecode, replacing system class calls (android.content.ClipboardManager, android.app.Activity) with MAM wrappers. Less stable than iOS approach, can break with aggressive ProGuard/R8 optimizations.
Android wrapping issue: if app uses minifyEnabled true with custom ProGuard rules, wrapping tool may not recognize renamed classes. Solution—add -keep rules for system classes wrapping must intercept.
Testing Wrapped App
After wrapping, must verify:
- App launches without crash (common cause—framework conflict on re-sign).
- Policies apply: test copy-paste to other app—must be blocked.
- Selective wipe works: initiate via Intune Portal, verify data deleted.
- Versioning: each base app update requires re-wrapping. Need CI/CD pipeline.
CI/CD for wrapping (GitHub Actions):
- name: Wrap IPA with Intune
run: |
./IntuneMAMPackager/Contents/MacOS/IntuneMAMPackager \
-i build/app.ipa \
-o build/app-wrapped.ipa \
-p $PROVISIONING_PROFILE \
-c "$SIGNING_CERT"
Implementation Stages
Analyze app compatibility with wrapping → configure Intune Portal and App Protection Policy → wrapping + re-signing → test policies → CI/CD integration → rollout via Intune / MDM.
Timeline: one-time wrapping of ready app—1–2 weeks. Full pipeline with CI/CD and policy testing—3–5 weeks. Cost is calculated individually.







