In short
- Everything is used for one purpose: App functionality (the support chat). Nothing is used for tracking, ads, analytics or profiling, and nothing is sold or shared.
- All of it is linked to the user inside your app, because your team sees who wrote each message.
- Everything travels over HTTPS and is stored on DevReply's servers for you. We process it as your processor under the DPA.
- Your users can have their data deleted: in your app when they delete their account (
deleteUser), from your backend (one API call), or by your team in the dashboard. Signing out (logout) makes the device forget the chat. - The React Native and Flutter packages run the native iOS and Android SDKs, so the iOS and Android tables apply to them.
iOS: App Store privacy labels
The SDK ships a privacy manifest (PrivacyInfo.xcprivacy) that declares the types below, and Xcode adds it to your app's privacy report. It declares no tracking and no tracking domains. Its only required-reason API is UserDefaults (reason CA92.1: the SDK remembers which language it last reported).
| Apple data type | What exactly | Linked | Tracking | Purpose | When |
|---|---|---|---|---|---|
| Contact Info → Name | The name the user types before their first message, or the one you pass with setUser | Yes | No | App Functionality | Needed to start a conversation |
| Contact Info → Email Address | Only if the user gives one (or you pass it), so replies also reach them by email | Yes | No | App Functionality | Optional |
| User Content → Customer Support | The messages the user sends, and when they were sent and read | Yes | No | App Functionality | When the user writes |
| User Content → Photos or Videos | Photos the user attaches (system picker, no photo-library permission; resized, re-encoded, EXIF and location removed) | Yes | No | App Functionality | Optional |
| User Content → Other User Content | Files the user attaches (up to 10 MB each), with their file names | Yes | No | App Functionality | Optional |
| Identifiers → User ID | The user record DevReply creates for this person in your app, and your own user ID if you pass it with login | Yes | No | App Functionality | Automatic |
| Identifiers → Device ID | A random install token DevReply issues (kept in the Keychain), and the APNs push token if your app registers for push | Yes | No | App Functionality | Automatic; push token only with push |
| Diagnostics → Other Diagnostic Data | Device model, iOS version, your app's version and build, SDK version, language | Yes | No | App Functionality | Automatic |
| Other Data → Other Data Types | Custom attributes, only if you send them with setAttributes | Yes | No | App Functionality | Only if you send them |
Not collected: location, contacts, health, financial info, browsing or search history, sensitive info, purchases, crash data, performance data, product interaction, advertising data, IDFA. The SDK never shows the App Tracking Transparency prompt.
Apple lets you leave out data that users give in optional, infrequent customer-support requests that aren't part of your app's main purpose. Whether that applies is your call; the manifest declares everything, to be safe.
Android: Google Play Data safety
Answer Yes to "Does your app collect or share any of the required user data types?" and add these. For each: collected, not shared (DevReply is your service provider, which Play doesn't count as sharing), not processed ephemerally, purpose App functionality.
| Play data type | What exactly | Collected | Shared | Purpose | Required or optional |
|---|---|---|---|---|---|
| Personal info → Name | The name typed before the first message, or passed with setUser | Yes | No | App functionality | Required to start a conversation |
| Personal info → Email address | Only if the user gives one (or you pass it) | Yes | No | App functionality | Optional |
| Personal info → User IDs | The user record DevReply creates for this person in your app, and your own user ID if you pass it with login | Yes | No | App functionality | Required (automatic) |
| Messages → Other in-app messages | The messages the user sends in the chat | Yes | No | App functionality | Required to use the chat |
| Photos and videos → Photos | Photos the user attaches (system photo picker, no storage permission; re-encoded, EXIF removed) | Yes | No | App functionality | Optional |
| Files and docs → Files and docs | Files the user attaches, with their names | Yes | No | App functionality | Optional |
| App info and performance → Diagnostics | Device maker and model, Android version, your app's version and build, SDK version, language | Yes | No | App functionality | Required (automatic) |
| Device or other IDs | A random install token DevReply issues (encrypted with an Android Keystore key), and the FCM token if your app forwards it | Yes | No | App functionality | Required (automatic); FCM token only with push |
| Whatever your attributes contain | Custom attributes, only if you send them with setAttributes | If you send them | No | App functionality | Your choice |
Security practices: data is encrypted in transit (Yes). Users can request that data be deleted (Yes: in your app with deleteUser, or through you, from your backend or the dashboard).
The Android SDK has no third-party dependencies (no Firebase, no analytics). It does not read the Android ID or the advertising ID. It only asks for the notification permission (Android 13+) after the user's first message, and only if your app forwards push.
Web
No store form, but your site's privacy notice should cover the same data. The web chat collects the name, optional email, messages, photos and files, and custom attributes as above. For device details it sends only the browser name and major version, the OS, and your site's hostname (or the app version you pass), plus the language. No fingerprinting, no cookies. It keeps its install token and the chat's settings in localStorage on your site, which the chat needs to work. The script is served from api.devreply.com, not a third-party CDN.
What the SDK never touches
- No location, contacts, camera or microphone access, and no photo-library permission (the system picker hands over only what the user picks).
- No advertising IDs, no cross-app identifiers, no fingerprinting.
- No analytics or crash-reporting SDK inside. No logs or screenshots leave the device.
- The push permission is never forced: the chat offers it after the user's first message, and "Not now" really means not now.
What's on you
- Attributes you send. If you pass custom attributes (a plan, a purchase, a user ID from your own system), declare those types too, e.g. Purchases for a plan name.
- Your privacy policy. Mention that support messages are handled by DevReply as your processor, and link our subprocessors.
- Push. Pushes go through your own APNs key and your own Firebase project, and carry a short preview of the reply.
- Account deletion. If your app has accounts, call
deleteUser()in its delete-account flow (Apple requires account deletion in the app), andlogout()on every sign-out. If accounts are deleted on your server, delete the DevReply user from there:DELETE https://api.devreply.com/v1/project/users?user_id=…with a read-and-write secret key. Other requests: delete the user in the dashboard (the inbox's user panel → Delete user), or delete the app to remove all of its users' data.