Learn React Native - Privacy & Data Handling

#Introduction

Privacy regulations like GDPR in Europe and CCPA in California changed how apps treat user data. It's not just about ethics — breaking the rules can mean huge fines and the loss of user trust.

Episode 16 covers privacy from the engineering practice side: data minimization, minimal permissions, a consent flow that can be recorded, logging that doesn't leak sensitive data, plus data retention and audit policies. This isn't purely a legal task — architectural decisions determine how easy it is for an app to comply.

#Data Minimization

#Collect as Little as Possible

The first GDPR principle: collect only the data truly needed for the requested function. If a feature doesn't need location, don't ask for location. If a profile can work without a date of birth, don't store a date of birth. Data that was never collected can't leak.

#Question Every Data Point Again

Before adding a new field or permission, ask: what data is collected, what for, how long is it kept, and who can access it? Clear answers indicate a compliant design; vague answers indicate a problem.

#Minimal Permissions

#Request One at a Time

Don't request all permissions at startup. Request one permission in the context of the feature that needs it, then the next permission when another feature is used. Mass requests increase denial and create the impression the app is spying.

#Example of a Healthy Flow

Open camera -> request camera permission
Upload photo -> request gallery permission
Send notification -> request notification permission

Each request comes with a short explanation of why the data is needed. Episode 12 covers request techniques and denial handling in detail.

#Consent Flow

#Record Consent

Regulations require explicit, provable consent. Store the user's answer along with the policy version and time, so an audit can show when and what was approved:

Storing consent with a version

import AsyncStorage from "@react-native-async-storage/async-storage";
 
const KUNCI_CONSENT = "consent_v1";
 
async function simpanKonsen(hasil) {
  const payload = {
    versi: 1,
    jawaban: hasil,
    waktu: new Date().toISOString(),
  };
  await AsyncStorage.setItem(KUNCI_CONSENT, JSON.stringify(payload));
}

new Date().toISOString() records the time of consent. When the policy changes, bump the version and request consent again — a user can't be considered to have agreed to new rules.

#Rebuild the Flow When the Version Changes

Store the consent version in storage. When the app opens, compare the stored version with the current policy version. If they differ, show the new consent flow before the user continues using features that need data.

#Secure Logging

#Don't Log Sensitive Data

Logs are the easiest place for data to leak: tokens, emails, and locations often end up on the console without realizing it. Set a policy: never write tokens, passwords, or PII data to logs.

#Redact Before Recording

If data must be recorded for debugging, redact the sensitive parts first:

Redacting sensitive data before logging

function logAman(objek) {
  const { token, ...sisa } = objek;
  console.log("data aman", JSON.stringify(sisa));
}

The { token, ...sisa } destructuring separates sensitive fields from safe ones, then only sisa is logged. Apply this pattern at every point that records user data.

#Logs in Production

In production, limit the log level and send to crash monitoring with automatic redaction. Never expose raw logs to a third-party tool without making sure sensitive data has been removed.

#Data Retention and Audit

#Retention Policy

Data must not be stored forever. Set a storage duration per data type, then clean up automatically. A simple implementation in local storage:

Cleaning up expired data

async function bersihkanRiwayat() {
  const mentah = await AsyncStorage.getItem("riwayat");
  const riwayat = mentah ? JSON.parse(mentah) : [];
  const batas = Date.now() - 30 * 24 * 60 * 60 * 1000;
  const masihBaru = riwayat.filter((item) => item.waktu > batas);
  await AsyncStorage.setItem("riwayat", JSON.stringify(masihBaru));
}

The code above removes history older than 30 days. Apply a similar policy on the server with a scheduled cleanup job.

#Audit Trail

Record data-processing activity: who accessed, when, and what data. An audit trail enables investigation when a leak occurs and serves as evidence of compliance when regulators ask. The audit data itself must be retained under its own rules.

#Closing

Episode 16 built an app that respects privacy: data minimization, minimal permissions, a recorded consent flow, logging free of sensitive data, and retention and audit policies that run automatically.

Key takeaways:

• Collect as little data as possible; uncollected data can't leak.
• Permissions are requested one at a time in feature context.
• Store consent with a version and time for audit purposes.
• Logs must not contain tokens, passwords, or PII data.
• Redact sensitive data before recording anything.
• Data retention needs a time limit and automatic cleanup.

In the next episode, episode 17, we'll discuss New Architecture deep dive: Fabric and JSI in depth, synchronous native calls, the interop layer for legacy libraries, plus migration strategies and when to enable the New Architecture.