> ## Documentation Index > Fetch the complete documentation index at: https://developer.neurofit.app/llms.txt > Use this file to discover all available pages before exploring further. # Privacy and compliance > What the SDK does and does not do with data, how to answer the App Store and Google Play privacy questions, permissions, consent copy, and the not-a-medical-device position. The SDK runs entirely on the device with deterministic signal processing, not machine learning. No images are stored or transmitted; camera frames are analysed in memory and discarded, and the only output is the `VitalsResult` handed to your app (heart rate, HRV (RMSSD), breathing rate and related measures). The SDK makes no network calls, stores nothing, and has no analytics or crash reporting of its own. What your app then does with that result is your decision and your responsibility. This page helps you make and document it. ## What leaves the device Nothing, from the SDK. You can confirm this with a network monitor during a reading, and source licensees can audit the code. The SDK does not read identifiers (no IDFA, no advertising id, no device id), does not read contacts, location or photos, and does not write to disk. ## Camera and accelerometer The reading uses two sensors: * **Rear camera and torch.** The fingertip covers the lens; the torch lights it. Frames are analysed in memory and discarded. * **Accelerometer.** Active from `start()` until the session stops or goes idle, at about 50 Hz. Its samples are used only while a reading is measuring, to help estimate breathing rate from the phone's small movements while it rests on the body or in the hand; samples outside a reading are discarded. Turn it off with `motionBreathing = false` if you prefer; the breathing rate then comes from the pulse signal alone (as it does on a device without an accelerometer). Neither sensor stream is retained after the reading. The camera and torch are released when the reading completes or fails, after a cancel without auto-restart, and on `stop()`; on Android the SDK also clears the camera settings it applied, so the next camera feature in your app starts from the platform defaults. ## App Store (iOS) ### App Privacy answers The SDK itself collects no data, so it adds no data types to your App Privacy section. Answer for what your app does with the result: | Your app | App Privacy answer | | - | - | | Shows the result and keeps it only on the device | The SDK adds nothing. Data kept on device is not "collected" under Apple's definition. | | Uploads results to your servers | Declare **Health and Fitness** (the category Apple uses for heart rate and similar readings). Mark it "linked to the user" if it is tied to an account, and choose the purposes that apply (App Functionality, Analytics, ...). | | Shares results with a third party | Declare the sharing as well, and consider whether it counts as tracking under Apple's rules. | ### Privacy manifest The SDK ships a `PrivacyInfo.xcprivacy` manifest that declares no tracking and no collected data types. Xcode merges it into your app's privacy report automatically. ### Camera usage string `NSCameraUsageDescription` is required. iOS shows it in the permission prompt, and a vague string is a common review rejection. Say what the camera is for, in the user's words: ```xml theme={null} NSCameraUsageDescription Measure your heart rate and HRV with a 60-second fingertip reading over the rear camera. No photos or video are saved. ``` Avoid "This app needs camera access" and avoid mentioning features you do not have. ### Motion Core Motion accelerometer sampling does not show a permission prompt. Adding `NSMotionUsageDescription` is still recommended: it costs nothing, some reviewers look for it, and it documents the sensor in your app's own terms. Name the accelerometer in your consent copy as well (below), so the description of the reading is complete. ```xml theme={null} NSMotionUsageDescription Your phone's motion sensor helps follow your breathing during a reading. ``` ## Google Play (Android) ### Permissions The SDK requires the `CAMERA` runtime permission and nothing else. It does not need `INTERNET`. Declaring the camera and flash as optional features keeps your app installable on devices that lack them; the SDK reports support at runtime. ```xml theme={null} ``` `VitalsSDK.hasCameraPermission(context)` and `VitalsSDK.requestCameraPermission(activity) { granted -> }` handle the runtime request. Show a short rationale first; the prompt itself says only "camera". ### Data safety form The SDK collects and shares nothing, so it adds no entries. If your app uploads results, declare **Health info** under Health and fitness, state whether it is shared, and whether it is required or optional. If your app is in a health category, review Google Play's health apps requirements for the declaration and privacy policy they expect. ## Consent copy Where you ask for consent (or explain the feature), name both sensors, the duration, what is computed, and what you do with the result. A template: > **Vitals reading.** This 60-second reading uses your phone's rear camera and flash to measure the pulse in your > fingertip, and the accelerometer to follow your breathing. The reading is processed on your phone. No photos or > video are saved. The result (heart rate, HRV (RMSSD), breathing rate and related measures) is stored in your > account so you can see your progress. You can delete your readings at any time in Settings. Adjust the last two sentences to match what your app actually does. ## Regional notes * **EU/EEA and UK.** Once you store a result and link it to a person, it is health data under the GDPR (a special category). That normally means explicit consent, a clear purpose, retention limits and a way to delete. The SDK's on-device design keeps the processing local until you decide to store or send the result. * **US.** If your app is covered by HIPAA (for example, offered through a covered entity), the result is PHI once stored; the usual safeguards apply to your storage and transport, not to the SDK, which stores nothing. * **Children.** Do not offer the reading to children without the consent your jurisdiction requires. The validation study included adults only. This is orientation, not legal advice. Have counsel review your consent flow and store policies. ## Not a medical device The NEUROFIT Vitals SDK is a general wellness tool. It is not a medical device and does not diagnose, treat, mitigate or prevent any disease or condition. Keep your own claims in the same place: * Describe HRV (RMSSD), heart rate and breathing rate as wellness and self-tracking metrics. * Do not use the readings to detect arrhythmias or any medical condition, and do not imply that you do. * Avoid words like "diagnose", "detect", "clinical" or "medical grade" in features built on the SDK. * Include a short disclaimer where results are shown, for example: "For wellness and self-tracking. Not a medical device. Talk to a healthcare professional about any health concern." If you plan to make a health claim, involve regulatory counsel first; the position above is what NEUROFIT's own app takes. ## Security * License keys are verified offline with a public key compiled into the SDK. There is nothing to phone home to. * The SDK does not log metrics or frames. Its own logging (`os.Logger` under subsystem `com.neurofit.vitals` on iOS, `Log` with tag `NeurofitVitals` on Android) is off by default; `VitalsSDK.isLoggingEnabled` (iOS) and `VitalsSDK.loggingEnabled` (Android) turn it on for debugging, and it then contains state transitions and capture decisions only, never metric values, frames or license contents. * The license key is verified in memory on each launch and never written to disk. * Source licensees can build from source and audit every path. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.