Sumsub Integrate Msdk

Sumsub — Mobile SDK integration (iOS & Android)

Embed Sumsub KYC into an existing native app via the `IdensicMobileSDK` framework (main class `SNSMobileSDK`), from dependency install to presenting / launching the verification flow — on iOS (Swift) or Android (Kotlin).

This is the trunk: read the always-on sections below (intake, asking-vs-doing), detect the platform, then use the decision table to open only the branch files that match the platform, the project, and the user's answers.

Intake — ask these three questions first, in one message

Before touching any project file, ask all three together:

1. Launch point. "From which screen should the Sumsub flow open? Please share the class name or describe the screen." — iOS: a ViewController or SwiftUI view; Android: an Activity, Fragment, or Composable.

1. Access token source. "Does your app already have a way to fetch a Sumsub access token from your backend? (If yes, share the function name, endpoint URL, or service class. If not, I'll add a placeholder you can fill in when your backend is ready.)"

1. Optional modules. "The base SDK covers standard verification flows and is always installed. On top of it, do you need any of these add-ons?

• NFC (passport / eMRTD chip reading) — iOS: MRTDReader; Android: the nfc module – read the chip on biometric passports
• VideoIdent — live video call with a moderator
• EID — German eID card reading
• Fisherman / Device Intelligence — fraud signals (iOS: optional module; Android: bundled in the base SDK since 1.43.0 — nothing to add) Skip them if you're not sure — they can be added later."

Modules are purely additive. In a multi-select, list only the modules — an empty selection already means "base only"; don't add "base only" as a co-selectable peer.

Do not ask about: the App Token or the secret key — those are server concerns that never touch the app.

Asking vs doing — keep approvals meaningful

• Read-only is free — scan / grep / read Info.plist, AndroidManifest.xml & build files without asking.
• Batch mutations into one approval, not one per line ("I'll add these 3 Info.plist keys [list] + this call site [diff] — apply?").
• Ask explicitly only for: editing existing app code, project-mutating commands (pod install, a Gradle sync), anything irreversible, and decisions you couldn't settle in intake.

Detect the platform (do this before opening any branch file)

Decide whether this is an iOS or Android project — the install steps, the permission model, and the generated language all differ. Read-only.

# iOS markers
find . -maxdepth 3 \( -name '*.xcodeproj' -o -name '*.xcworkspace' -o -name 'Podfile' -o -name 'Package.swift' \) 2>/dev/null
# Android markers
find . -maxdepth 3 \( -name 'build.gradle' -o -name 'build.gradle.kts' -o -name 'settings.gradle*' -o -name 'AndroidManifest.xml' \) 2>/dev/null

• iOS only (.xcodeproj / Package.swift / Podfile, no Gradle) → iOS track.
• Android only (build.gradle[.kts] / AndroidManifest.xml, no Xcode) → Android track.
• Both present (a monorepo, or a React-Native / Flutter shell with native folders) → report both and ask which platform to integrate. One platform per run. (React Native / Flutter wrappers themselves are out of scope — this skill targets the native SDKs; the Step-1 scan bails on a detected wrapper.)
• Neither → ask the user to point at the app's source root.

Confirm the detected platform if there was any ambiguity, then follow the matching track.

How to navigate this skill

After intake, open ONLY the rows that match the detected platform, the project (from Step 1), and the user's intake answers. Each branch file is self-contained and ends with a Next pointer. A letter (2A/2B, 6A/6B) marks a branch — pick one; plain numbers run in sequence.

iOS track

Android track

Fallback (last resort only). This skill and its branch files are the primary source — don't reach for external docs by default. Only if you hit a genuine blocker they don't resolve, consult the Sumsub docs: iOS · Android.

When the tree is walked, return here for Guardrails and Handoff.

Guardrails — what this skill must never do

• Detect the platform first — never emit Swift into an Android project or Kotlin into an iOS one; if both are present, ask which to integrate.
• Never edit existing app code beyond the single targeted call site the user approved in intake.
• (iOS) Let the SDK present itself — in SwiftUI too. Always launch via SumsubVerification.start() ( sdk.present() / sdk.present(from:)). Never strong-hold the SDK or its mainVC across the flow, and never bridge sdk.mainVC into a SwiftUI .fullScreenCover / .sheet. mainVC strong-retains the SDK and the SDK fires onDidDismiss from that controller's dealloc; holding it yourself delays teardown and causes "opens every other time" + a crash on re-open. The SDK owns presentation and dismissal — one owner, clean re-open.