Building Backend APIs for Mobile Apps (iOS, Android, Flutter) on Domain India Hosting

Every iOS, Android, React Native or Flutter app that has logins, feeds, uploads or payments needs a backend API. This guide covers the decisions that matter for a mobile backend: the API style, authentication, push notifications, file uploads, offline sync, payments, versioning and security, and which kind of Domain India hosting suits each stage of your app.

1. What a mobile backend must handle

Every mobile app (iOS, Android, React Native, Flutter) talks to a backend for:

• sign-up and login (email, Google, Apple, phone OTP);
• content feeds, loaded lazily and paginated;
• file uploads (profile photos, documents, audio);
• push notifications;
• real-time updates (chat, live scores, order tracking);
• analytics events;
• payments (Razorpay or Stripe for Indian and global customers);
• offline sync (the app works without internet and syncs on reconnect).

2. Which Domain India hosting fits your stage?

User numbers below are rough guides; what matters is what your backend needs to run.

What decides the move:

• Shared hosting runs request/response apps only. Long-running processes such as WebSocket servers and queue workers are stopped, cron runs at most every 4 minutes, there's no Redis, and Composer isn't pre-installed (run composer.phar over jailed SSH, or build vendor/ locally and upload it).
• The App Platform auto-detects Node.js apps (other languages need your own Dockerfile) and includes PostgreSQL and free SSL, but has no WebSockets, no Redis and no SSH.
• A VPS (from ₹553 a month, excluding GST) gives you full root access for anything else. It is self-managed and includes no backups, so you patch and back it up yourself.

Mobile backends are API-only (no HTML rendering), so a small server goes a long way. Load-test your own API before you size a server.

3. Choosing the API style

REST: simple, works everywhere, easy to cache. The best default.

GraphQL: lets each screen ask for exactly the fields it needs, which keeps payloads small on slow mobile networks. See our GraphQL articles.

gRPC: mostly for internal services; rarely called directly from mobile apps.

WebSockets or Server-Sent Events: for real-time features such as chat and live tracking. See real-time sync and push notifications for mobile apps.

For most apps: REST with JSON, plus WebSockets for the real-time screens. Add GraphQL when several clients need very different data from the same endpoints.

4. Authentication patterns

Pattern 1: JWT access tokens with refresh tokens

The usual choice for mobile, where cookie sessions are awkward.

Node.js example:

import jwt from 'jsonwebtoken';
import crypto from 'node:crypto';

const sha256 = (s) => crypto.createHash('sha256').update(s).digest('hex');
const DAY = 24 * 60 * 60 * 1000;

async function issueTokens(userId) {
  const accessToken = jwt.sign({ sub: userId }, ACCESS_SECRET, { expiresIn: '15m' });
  const refreshToken = crypto.randomBytes(32).toString('base64url');   // opaque, not a JWT
  await db.refreshToken.create({
    data: { userId, hash: sha256(refreshToken), expiresAt: new Date(Date.now() + 30 * DAY) },
  });
  return { accessToken, refreshToken };
}

app.post('/auth/refresh', async (req, res) => {
  const stored = await db.refreshToken.findFirst({
    where: { hash: sha256(String(req.body.refreshToken ?? '')) },
  });
  if (!stored || stored.revoked || stored.expiresAt < new Date()) {
    return res.status(401).json({ error: 'invalid_refresh_token' });
  }
  // Rotate: the old refresh token can't be used again
  await db.refreshToken.update({ where: { id: stored.id }, data: { revoked: true } });
  res.json(await issueTokens(stored.userId));
});

If a revoked refresh token is ever presented again, treat it as stolen and revoke all of that user's tokens. More detail is in JWT security best practices.

Pattern 2: Sign in with Apple and Google

Social login removes password handling. Apple's App Review rules require iOS apps that offer a third-party login (such as Google) to also offer a privacy-focused login option; Sign in with Apple is the usual way to meet that.

• iOS: Sign in with Apple returns an identity token (a JWT). Verify its signature against Apple's published keys, and check the issuer, audience and expiry.
• Android: Google Sign-In (Credential Manager) works the same way, with Google's keys.

Your backend stores a provider + providerUserId → internalUserId mapping.

Pattern 3: biometric unlock (on the device)

Face ID or the fingerprint sensor unlocks the stored refresh token on the device, and the app then uses it as normal. Your API never sees biometrics; it only sees a refresh request.

5. Push notifications

There are two delivery services: Firebase Cloud Messaging (FCM) for Android and Apple Push Notification service (APNs) for iOS. The simplest path is FCM for both, because Firebase relays to APNs for you.

The raw HTTP v1 call looks like this (the access token is a short-lived OAuth token from your service account, which the Admin SDKs handle for you):

curl -X POST "https://fcm.googleapis.com/v1/projects/YOUR_PROJECT/messages:send" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"message":{"token":"DEVICE_TOKEN","notification":{"title":"Order shipped","body":"Track now"}}}'

Libraries: firebase-admin for Node.js and for Python, and kreait/firebase-php for PHP (on shared hosting, install it with Composer on your own computer and upload vendor/).

6. File uploads

Direct-to-storage with presigned URLs (recommended):

• the app asks your API for an upload URL (POST /upload-url with the file type and size);
• the API checks the request and returns a presigned URL valid for a few minutes, for S3, Cloudflare R2 or Backblaze B2;
• the app uploads straight to storage, with no hop through your server;
• the app tells your API the final object key.

This saves your server's bandwidth, CPU and upload limits. See Cloudflare Workers and R2 storage for an R2 example.

Upload through your API suits only small files:

import multer from 'multer';
import fs from 'node:fs';
import crypto from 'node:crypto';
import { PutObjectCommand } from '@aws-sdk/client-s3';

const upload = multer({ dest: '/tmp/uploads', limits: { fileSize: 5 * 1024 * 1024 } });

app.post('/upload', upload.single('file'), async (req, res) => {
  const allowed = { 'image/jpeg': 'jpg', 'image/png': 'png', 'image/webp': 'webp' };
  const ext = allowed[req.file?.mimetype];
  if (!ext) return res.status(415).json({ error: 'unsupported_type' });

  // Never use the client's file name in the key
  const key = `users/${req.user.id}/${crypto.randomUUID()}.${ext}`;
  await s3.send(new PutObjectCommand({
    Bucket: 'uploads', Key: key,
    Body: fs.createReadStream(req.file.path), ContentType: req.file.mimetype,
  }));
  fs.unlink(req.file.path, () => {});
  res.json({ key });
});

If a PHP API on shared hosting receives uploads itself, the upload limit is 256 MB on cPanel and 64 MB on DirectAdmin.

7. Offline sync

Weak 4G, lifts and metro tunnels mean many users are offline for part of the day, so plan for it:

1. Optimistic writes: the app writes to local SQLite first, then syncs, with a "syncing" indicator.
2. Pull-based sync with timestamps: GET /sync?since=LAST_SYNC_TIMESTAMP returns everything changed since then.
3. Sync libraries such as PowerSync or WatermelonDB handle much of this for you. (MongoDB's Atlas Device Sync for Realm has been discontinued.)

Your backend needs:

• an updatedAt timestamp on every row, set on each change;
• soft deletes (a deletedAt column instead of deleting the row);
• a way to list IDs deleted since a timestamp, so apps can remove them too.

8. Payments in India

The usual choice is Razorpay (UPI, cards, netbanking, wallets, subscriptions); Stripe suits international cards.

The flow is the same with both official mobile SDKs: your backend creates the order through the gateway's API, passes the order ID to the app, the app opens the gateway's checkout, and the app sends the result back to your backend, which verifies the signature before marking the order paid. Also handle the gateway's webhook, because the app may close before it reports back. See our Razorpay integration article.

9. Versioning your API

Users don't all update their apps, so old builds will call your API for months or years.

Put a version in the URL (/v1/, /v2/) and keep the old version running for as long as a meaningful share of users is on builds that call it:

GET /v1/feed   # older app builds
GET /v2/feed   # current

Have the app send an X-App-Version header. It lets you adjust responses for older builds and, when you must, return a "please update" response below a minimum version.

10. Security essentials

FAQ

Ready to build your app's backend? Start small on cPanel hosting, deploy a Node.js API on the App Platform, or take full control on a VPS. Not sure which fits? Open a support ticket.