Django Mobile App Backend Production Checklist

Problem statement

A Django REST Framework or Django Ninja API backs your mobile apps. Unlike a web frontend you redeploy at will, mobile apps stay installed in old versions for months, run on flaky networks, store tokens on devices that get lost, and depend on push notifications. Backend changes that are fine for a website can break thousands of installed apps. This checklist covers what a Django backend needs to serve mobile clients reliably.

1. Use short-lived access tokens with refresh tokens and server-side revocation (for example SimpleJWT with a blacklist, or opaque tokens).
2. Version the API (URL or header) and keep old versions working until a forced-upgrade threshold.
3. Send push notifications (APNs, FCM) from Celery with retries, and prune invalid device tokens.
4. Rate limit per user and per device, design endpoints for retries (idempotency keys), and paginate everything.
5. Log app version and platform with every request, and support a minimum-version check for forced upgrades.

Checklist

Authentication and sessions

• Access tokens short-lived (minutes); refresh tokens longer and rotated on use.
• Server-side revocation: logout, password change, and "log out all devices" invalidate refresh tokens.
• Tokens stored in the platform keychain or keystore by the app, never in plain storage.
• Sign in with Apple and Google token verification done server-side with audience checks.

Compatibility and versioning

• API versioning strategy (path /api/v2/ or Accept header) documented.
• Only additive changes within a version: new optional fields, no removed or renamed fields.
• Minimum supported app version endpoint or header check, returning a clear "update required" response.
• Old versions tracked by traffic share before deprecation; sunset dates communicated in-app.

Push notifications and async work

• Device tokens stored per user and device, with platform and app version.
• Pushes sent from Celery tasks with retries; invalid or unregistered tokens removed on provider feedback.
• APNs keys and FCM credentials stored as secrets and rotated; separate sandbox and production configuration.
• Notification sends triggered after commit, idempotent to avoid duplicates.

Network resilience and limits

• Idempotency keys for create and payment endpoints so retries on flaky networks do not duplicate actions.
• Pagination on every list endpoint; compact payloads; gzip or Brotli compression.
• Per-user and per-IP throttling; separate stricter limits for auth endpoints.
• Large uploads (photos, video) direct to object storage with presigned URLs.

Observability

• App version, platform, and device model logged (low-cardinality) with requests and errors.
• Error rates and latency dashboards broken down by app version to spot bad releases.
• Sentry or similar on both the backend and the apps, linked by request IDs.

Explanation

Web frontends and backends are usually deployed together, so API changes are coordinated. Mobile apps break that link: each installed version is a separate client that may live for a long time, and you cannot force updates instantly. Unreliable networks make retries common, and lost devices make token revocation important. A Django backend built for mobile therefore emphasizes compatibility, idempotency, revocable authentication, and per-version visibility.

Edge cases / notes

• Offline sync. Apps that sync data offline need conflict handling (timestamps or version fields) on the server.
• Certificate pinning. If apps pin certificates, coordinate certificate and CA changes carefully to avoid locking them out.
• App Store requirements. Account deletion must be available in-app for iOS; the backend needs a deletion endpoint.

Next steps

• Cover general API concerns with the Django API Production Checklist.
• Configure limits with Configure Django REST Framework Throttling for Production.
• Handle media from devices with Handle Large and Resumable File Uploads in Django.

FAQ

How should a Django API authenticate mobile apps?

With short-lived access tokens and rotating refresh tokens that the server can revoke.

How long must old API versions keep working?

Until traffic from app versions using them falls below a threshold and a minimum version is enforced.

Where should push notifications be sent from?

From Celery tasks, with retries and cleanup of invalid device tokens.

How do I find which app version causes errors?

Log app version and platform on each request and break down error dashboards by them.