DEV Community: Puneetpal Arneja

Laravel Sanctum vs Passport for Mobile Apps (2026)

Puneetpal Arneja — Sat, 24 Oct 2026 01:57:12 +0000

For a mobile app that talks to its own Laravel API, use Sanctum. It issues one revocable token per device from a login endpoint you control, supports abilities and expiry, and has nothing to configure beyond a trait. Passport is a full OAuth2 server, and the only mobile cases that need one are apps you do not own asking for access to your users’ data, or other servers authenticating as themselves.

That is the short answer, and it matches what the Laravel docs say. The rest of this article is the reasoning, the parts of each package that matter once the app is in production, and the code for the places where Sanctum’s simplicity leaves a gap. It is one part of a larger guide to Laravel as a backend for mobile apps, which covers versioning, response shape, pagination, and push alongside authentication.

What Sanctum Actually Is

Sanctum is two separate features in one package, and only one of them applies to a native app.

API tokens. Modelled on GitHub personal access tokens. createToken() on the user writes a row to personal_access_tokens with a SHA-256 hash of a random string and returns the plain text once. The client sends it as a Bearer header and Sanctum looks the hash up on every request. Tokens can carry abilities, which work like scopes, and an optional expiry.
SPA cookie authentication. No tokens at all. A browser frontend on the same top-level domain logs in through the normal web guard and Sanctum lets the session cookie authenticate API routes, with CSRF protection intact. The statefulApi() middleware decides which origins get this treatment.

A mobile app uses the first feature only. There is no browser, no cookie jar worth trusting, and no CSRF problem, so the cookie half of Sanctum does not apply. The docs are explicit that API tokens are for mobile apps and third parties while first-party SPAs should use the cookie flow; the mistake worth avoiding is doing it the other way round.

What Passport Actually Is

Passport is a complete OAuth2 authorization server built on league/oauth2-server. It registers the /oauth/authorize and /oauth/token endpoints, stores clients and their redirect URIs, issues RSA-signed JWT access tokens together with refresh tokens, and implements the standard grants: authorization code (with or without PKCE), client credentials, device authorization, and the older password and implicit grants, which are off unless you turn them on.

The important word is server. Passport exists so that other applications can obtain access to your API on a user’s behalf, with the user approving a scope list on a consent screen you render. When the only client is your own app, every one of those moving parts is still present and still has to be configured, deployed, and kept secure, but none of them is doing anything you need.

Why Mobile Apps Almost Always Want Sanctum

Your own iOS or Android app is a first-party client. The user types their credentials into a screen you built, so there is no delegation to model and no third party to keep at arm’s length. What the app needs from the token system is narrower than OAuth2 and more specific:

One token per installed device, named so the user can recognise it in a sessions list.
The ability to revoke one device without logging out the others, and all of them at once on a password reset.
A token that survives app restarts for weeks, not minutes, because re-login on a phone costs you users.
Optionally, a token that can do less than the user can, so a stolen token from a read-only screen cannot place orders.

Sanctum covers each of these with a line or two. The login endpoint below follows the shape in the docs, with an expiry and abilities added, and device_name supplied by the app from the device model or a user-chosen label.

<?php
// routes/api.php
Route::post('/auth/login', function (Request $request) {
    $request->validate([
        'email' => ['required', 'email'],
        'password' => ['required'],
        'device_name' => ['required', 'string', 'max:100'],
    ]);

    $user = User::where('email', $request->email)->first();

    if (! $user || ! Hash::check($request->password, $user->password)) {
        throw ValidationException::withMessages([
            'email' => ['The provided credentials are incorrect.'],
        ]);
    }

    $expiresAt = now()->addDays(30);

    $token = $user->createToken(
        $request->device_name,
        ['orders:read', 'orders:write', 'profile:read'],
        $expiresAt,
    );

    return response()->json([
        'token' => $token->plainTextToken,
        'expires_at' => $expiresAt->toIso8601String(),
    ]);
})->middleware('throttle:login');

Returning expires_at alongside the token is a small addition that pays for itself later: the app can decide when to rotate without parsing anything, and support can see at a glance why a device was signed out.

Abilities are enforced on routes with the two middleware Sanctum ships, Laravel\Sanctum\Http\Middleware\CheckAbilities and CheckForAnyAbility. They are not aliased by default in Laravel 11 and 12, so register them once in bootstrap/app.php.

<?php
// bootstrap/app.php, inside withMiddleware()
$middleware->alias([
    'abilities' => CheckAbilities::class,  // token must have every listed ability
    'ability' => CheckForAnyAbility::class, // token must have at least one
]);

// routes/api.php
Route::get('/orders', [OrderController::class, 'index'])
    ->middleware(['auth:sanctum', 'abilities:orders:read']);

Route::post('/orders', [OrderController::class, 'store'])
    ->middleware(['auth:sanctum', 'abilities:orders:write']);

// Inside a policy, combine the token check with ownership
return $user->id === $order->user_id && $user->tokenCan('orders:write');

Revocation is a delete. Logout removes the current device’s row; a password reset, email change, or “sign out everywhere” removes them all. Because only hashes are stored, a leaked database does not yield usable tokens, though you should still rotate after an incident.

<?php
// Logout: only this device
Route::post('/auth/logout', function (Request $request) {
    $request->user()->currentAccessToken()->delete();

    return response()->noContent();
})->middleware('auth:sanctum');

// Password reset listener: every device, then the user logs in again
class RevokeTokensOnPasswordReset
{
    public function handle(PasswordReset $event): void
    {
        $event->user->tokens()->delete();
    }
}

// A sessions screen: revoke one named device the user picked
$request->user()->tokens()->where('id', $request->integer('token_id'))->delete();

What You Give Up: Refresh Tokens and Rotation

Sanctum has no refresh tokens. A token is valid until it expires or is deleted, and the default is that it never expires, because expiration in config/sanctum.php is null. That default is fine for a developer’s personal access token and wrong for a phone that can be lost, so the first production decision is to set it.

<?php
// config/sanctum.php: minutes, applies to every token without its own expiry
return [
    'expiration' => 60 * 24 * 30,
];

// routes/console.php: expired rows stay in the table until this runs
Schedule::command('sanctum:prune-expired --hours=24')->daily();

Once tokens expire you need an answer to “what happens on day 31?” Forcing a re-login is acceptable for some products and a churn problem for others. The alternative is rotation: an authenticated endpoint that issues a replacement with the same name and abilities and deletes the token that called it, in one transaction so a crash between the two statements cannot leave the user with zero tokens or two.

<?php
Route::post('/auth/token/rotate', function (Request $request) {
    $user = $request->user();
    $current = $user->currentAccessToken();
    $expiresAt = now()->addDays(30);

    $fresh = DB::transaction(function () use ($user, $current, $expiresAt) {
        $token = $user->createToken($current->name, $current->abilities, $expiresAt);
        $current->delete();

        return $token;
    });

    return response()->json([
        'token' => $fresh->plainTextToken,
        'expires_at' => $expiresAt->toIso8601String(),
    ]);
})->middleware(['auth:sanctum', 'throttle:rotate']);

On the client, call it when expires_at is within a few days, on app foreground, and store the new token before discarding the old one. Two details keep this honest. The endpoint requires a valid token, so an expired token cannot be refreshed; that is the trade-off versus an OAuth2 refresh token, which outlives the access token by design. And the endpoint needs its own rate limiter, because a captured token can otherwise be renewed forever by whoever holds it. If a long-lived credential that survives access token expiry is a hard requirement, that is a genuine reason to look at Passport.

When Passport Is the Right Choice

Three situations call for a real OAuth2 server, and they are about who the client is rather than how large the app is.

Apps you do not own. A partner’s app, a customer’s integration, or a public developer platform where someone else’s code asks for access to your users’ accounts. The user has to see what is being requested and approve it, and the client must never see the user’s password. That is the authorization code grant with PKCE.
Machine-to-machine. A reporting job, a warehouse system, or another one of your services calling the API as itself rather than as a user. That is the client credentials grant.
Real refresh semantics. A short-lived access token plus a longer-lived refresh token, with both lifetimes set centrally and refresh tokens revocable on their own.

Setup starts with php artisan install:api --passport, then passport:keys on each environment to generate the RSA key pair that signs tokens. The user model takes Passport’s HasApiTokens trait and the OAuthenticatable interface, and the api guard in config/auth.php switches to the passport driver. Scopes and lifetimes live in a service provider.

<?php
// app/Providers/AppServiceProvider.php
class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Passport::tokensCan([
            'orders:read' => 'Read your order history',
            'orders:write' => 'Place orders on your behalf',
            'profile:read' => 'Read your profile',
        ]);

        Passport::defaultScopes(['profile:read']);

        Passport::tokensExpireIn(CarbonInterval::hours(1));
        Passport::refreshTokensExpireIn(CarbonInterval::days(30));
        Passport::personalAccessTokensExpireIn(CarbonInterval::months(6));

        // Opt-in only, and the docs no longer recommend it. Leave it out
        // for a first-party mobile app; use Sanctum for that instead.
        // Passport::enablePasswordGrant();
    }
}

For a mobile app that belongs to someone else, create a public client, which has no secret, since a secret compiled into an app binary is not a secret. The app opens the authorization URL in a system browser sheet (ASWebAuthenticationSession on iOS, Custom Tabs on Android), receives the code on its redirect URI, and exchanges it together with the code verifier.

<?php
// Create the PKCE client once; Passport prints its client ID
// php artisan passport:client --public

// The mobile client builds the challenge from a random 43-128 char verifier
$codeVerifier = Str::random(128);
$codeChallenge = strtr(rtrim(base64_encode(hash('sha256', $codeVerifier, true)), '='), '+/', '-_');

// Step 1: open in the system browser
$authorizeUrl = 'https://api.example.com/oauth/authorize?'.http_build_query([
    'client_id' => $clientId,
    'redirect_uri' => 'com.partner.app://oauth/callback',
    'response_type' => 'code',
    'scope' => 'orders:read profile:read',
    'state' => $state,
    'code_challenge' => $codeChallenge,
    'code_challenge_method' => 'S256',
]);

// Step 2: exchange the code; no client_secret for a public client
$response = Http::asForm()->post('https://api.example.com/oauth/token', [
    'grant_type' => 'authorization_code',
    'client_id' => $clientId,
    'redirect_uri' => 'com.partner.app://oauth/callback',
    'code_verifier' => $codeVerifier,
    'code' => $code,
]);

// Protect routes by scope with auth:api and the scope middleware
Route::get('/orders', [OrderController::class, 'index'])
    ->middleware(['auth:api', CheckToken::using('orders:read')]);

// Machine-to-machine routes use the client as the resource owner instead
Route::get('/reports/daily', DailyReportController::class)
    ->middleware(EnsureClientIsResourceOwner::using('reports:read'));

Passport does not ship a mobile SDK, and the challenge and exchange above would normally run in Swift or Kotlin; the PHP form is here because it is the same algorithm and lints. The server side is the routes Passport registers plus the consent view you provide through Passport::authorizationView().

Passport Costs You Should Price In

Token size. Access tokens are RSA-signed JWTs that encode the client, user, scopes, and expiry, and come out around a kilobyte. A Sanctum token is the row ID, a pipe, and a 40-character random string. Per request that is noise; across a screen that fires a dozen calls on a cellular connection it is measurable, and it is the kind of thing that shows up when you profile a slow list.
Key management. passport:keys writes a private and public key to storage/. They must not be in git, every server that validates tokens needs the public key, and rotating the pair invalidates every token signed by the old one. Most teams load them from PASSPORT_PRIVATE_KEY and PASSPORT_PUBLIC_KEY environment variables, or point Passport::loadKeysFrom() at a mounted secrets path.
Revocation sets a flag rather than deleting the row. Expiry is encoded inside the signed token, so the expires_at column is informational and cannot be edited to shorten a token. To cut one off you call $token->revoke(), and separately $token->refreshToken?->revoke(), otherwise the client simply refreshes. Revoked and expired rows accumulate until passport:purge runs, so schedule it.
More tables, more grants, more surface. Five tables instead of one, a consent screen to design, redirect URI validation to get right, and the discouraged password and implicit grants sitting one method call away from being enabled by a well-meaning teammate.

<?php
// Revoke one connection, access and refresh token together
$token = Passport::token()->find($tokenId);
$token->revoke();
$token->refreshToken?->revoke();

// Password reset: every token the user has issued to any client
$user->tokens()->each(function (Token $token) {
    $token->revoke();
    $token->refreshToken?->revoke();
});

// routes/console.php
Schedule::command('passport:purge')->hourly();

Decision Table

Concern	Sanctum	Passport
Client you own (iOS, Android, Flutter)	Yes, the intended use	Works, but over-built
Third-party apps with user consent	No	Authorization code + PKCE
Machine-to-machine	Long-lived token on a service user	Client credentials grant
Token format	Opaque id\|random, hash stored	RSA-signed JWT, about 1 KB
Refresh tokens	None; rotate with a custom endpoint	Built in, separate lifetime
Scopes	Abilities per token	Scopes declared with tokensCan()
Expiry	Config minutes or per-token date; null by default	tokensExpireIn(); one year by default
Revocation	Delete the row	revoke() token and refresh token
Secrets to manage	None beyond APP_KEY	RSA key pair per environment
Database	One table	Clients, codes, tokens, refresh tokens, device codes
Housekeeping	sanctum:prune-expired	passport:purge

Migrating Between Them

The constraint that shapes every mobile migration applies here too: installed app builds keep using whatever token they were issued, for as long as users keep them. You cannot swap the guard on a Tuesday. Plan for a window where both guards accept requests.

Passport to Sanctum is the common direction, usually when a team discovers it adopted OAuth2 for one client it owns. Install Sanctum and add a second guard (sanctum is already a driver), publish a new login endpoint that issues Sanctum tokens, and ship an app build that uses it. Existing builds keep calling the Passport routes until their tokens expire; shorten tokensExpireIn() ahead of the switch so that window is weeks rather than a year. Protect shared routes with auth:sanctum,api so either guard can authenticate during the overlap. Once your build adoption analytics show the old builds are gone, remove the Passport guard, its routes, and the tables.

Sanctum to Passport happens when a partner programme arrives. The snag is that both packages ship a trait called HasApiTokens with the same method names, so one User model cannot simply use both. The cleanest path is to move the first-party app onto Passport as well, either through the PKCE flow in a system browser sheet or through Passport’s own createToken() for personal access tokens, which has a similar signature but mints a JWT. The same overlap window applies, with the Sanctum guard kept alive until old builds have gone. If the partner surface is small, it is worth asking first whether a separate, narrowly scoped Passport resource server in front of the same database would cost less than migrating your own app.

Either way, the migration is mostly a guard switch plus patience. The code that changes is the login endpoint, the route middleware, and the token-revocation paths listed above; business logic should not know which package authenticated the request.

Sources

Where This Fits

Pick Sanctum, set an expiry, add the rotation endpoint, and spend the time you saved on the controls that fail security reviews more often than the token library does: ownership checks on every lookup, rate limits on login, and logs that can answer who read what. Those are worked through in the Laravel API security checklist. If you would rather have someone build the auth layer and the API around it, see backend API development.

Originally published at puneetpal.dev.

How Long Does It Take to Build an iOS App? (2026 Timeline)

Puneetpal Arneja — Sat, 24 Oct 2026 01:57:06 +0000

Short answer: building an iOS app takes about 3 to 5 weeks for a TestFlight prototype, 4 to 8 weeks for a store-ready MVP, 4 to 8 months for a production app with payments and offline support, and 8 months or more for complex or regulated apps. Those ranges run from kickoff to App Store availability, review included.

Timelines slip for consistent reasons, and almost none of them are engineering speed. The schedule is usually lost in the weeks before development starts and the weeks after feature work “finishes”, two phases that rarely appear on the plan at all. Here is where the time goes, with ranges you can plan against.

Timeline and budget move together, so this pairs with what an iOS app costs, which uses the same tiers. If the ranges below look longer than you have, the lever is scope rather than staffing, which is what the MVP playbook is about.

iPhone App Development Timeline at a Glance

Kickoff to App Store availability, assuming a dedicated team and decisions made promptly.

App type	Timeline	Team	What’s included
Prototype	3-5 weeks	One developer	One workflow, mock data, TestFlight only
MVP	4-8 weeks	One developer, part-time design	Auth, a backend, one core workflow built properly, analytics, store launch
Production app	4-8 months	One to two developers, design, QA	Several workflows, payments, push, offline behaviour, a test suite, a real release process
Complex or regulated	8+ months	Three or more, plus security and backend	Compliance review, security assessment, and approval gates outside your control

The most common planning error is quoting the MVP range for a production app. The features look similar on a list; the difference is everything that makes an app supportable. If you are unsure which row you are in, MVP vs full build walks through that decision.

Budget follows the same rows. In the cost guide an MVP runs $15K-$40K. The production row splits in two: a standard app at $40K-$80K over 4-6 months, and a complex app at $80K-$150K over 6-8 months. Complex or regulated work starts at $150K. All of those assume US rates.

What Are the Phases of iOS App Development?

For an MVP at the top of its range, eight weeks from kickoff to the App Store, the split is roughly:

Discovery and scoping: 1 week. Which single workflow ships, what the API contract looks like, what is explicitly out. Skipping it moves the time into development, where it is more expensive.
Design: 1-2 weeks, overlapping development once the first flows are settled. Standard iOS components keep this short.
Core development: 3-4 weeks. The part everyone estimates, and the part least likely to be the problem.
Integration and hardening: 1-2 weeks. Real data, real devices, slow networks, and the edge cases the happy path hid.
Store preparation and review: 1 week. Screenshots, privacy declarations, a demo account for the reviewer, submission, and one likely rejection cycle.

A four-week MVP is the same five phases with one workflow, standard components, and a backend that already exists. Discovery and store preparation shrink to days rather than weeks; nothing is skipped.

A production app at six months, the middle of its range, stretches every phase rather than adding new ones: 2-3 weeks of discovery, 4-6 weeks of design overlapping development, 12-16 weeks of core development, 4-6 weeks of integration and hardening, and 1-2 weeks of store preparation and review. Design and development overlap, which is how 23-33 weeks of phase time fits a roughly 26-week calendar.

In both cases development is about half the calendar. Teams that compress by cutting discovery and hardening are removing the phases that prevent the overrun.

What Slows Down iOS App Development?

A backend being built in parallel is the single largest source of slippage. Mobile work stalls against unfinished or changing endpoints, and the delay is invisible until it is on the critical path. Contract-first API design, with the mobile team working against mocks, is the mitigation.

After that, in rough order of damage:

Design decided during development, where every unresolved screen becomes a blocking question mid-sprint.
Slow decisions. A team waiting two days for an answer loses more time than any technical problem will cost them.
Third-party dependencies such as payment providers, identity verification, and enterprise SSO, each of which runs on someone else’s timeline and approval.
The device and OS matrix, where older devices and the current beta both surface issues late if they are not tested continuously.

How Long Does App Store Review Take?

Review itself is fast in 2026, typically 24 to 48 hours. The cost is a rejection on a first submission, which commonly comes from:

Privacy manifest and tracking declarations not matching actual SDK behaviour
Missing in-app account deletion where an account can be created
Subscription terms and pricing not presented as required
Permission prompts without a clear justification string
Demo credentials that do not work for the reviewer

Each is avoidable and each costs a round trip of a few days. Plan one rejection cycle into a first launch and treat it as normal rather than as a failure.

Two other review steps catch teams out. External TestFlight testing needs its own beta review before outside testers can install a build, so the first external beta should not be scheduled for the day before a demo. And while Apple accepts expedited review requests for urgent cases such as a critical bug fix, that is a request rather than a guarantee, so it is not a planning tool. Apple documents the process and current guidance on its App Review page.

How Can You Build an iOS App Faster?

These work. Most other accelerations trade schedule for rework:

Cut scope, not phases. The only reliable lever. Fewer workflows built properly beats more workflows built thinly.
Finish design before the sprint that needs it. Not before the project; before the sprint.
Define the API contract first. Mobile and backend then proceed in parallel against mocks instead of sequentially against reality.
Put someone with authority in the standup. Decision latency is a schedule item.
Ship to TestFlight from week one. Release problems found in week two are cheap; found in week eleven they are the critical path.

What does not work: adding developers to a late project, running QA only at the end, and treating store submission as an afterthought.

How Do You Estimate Your Own App’s Timeline?

Work through these in order before trusting any single number, including the ones above:

Pick the row honestly. Count the workflows a user must complete on day one, not the features on the wish list. One workflow is an MVP; several, with payments and offline behaviour, is a production app.
Check the backend. If it does not exist yet or is changing, assume it is on the critical path and plan the API contract first.
Count the outside approvals. Payment providers, identity checks, enterprise SSO, and compliance sign-off each add a timeline you do not control.
Add the phases estimates leave out. Discovery, integration and hardening, store preparation, and one review rejection cycle.
Price it alongside the schedule. Time and budget move together; the iOS app cost breakdown uses the same tiers and shows the hours behind each one.

If the result is longer than you have, cut scope rather than phases. The mobile MVP playbook covers how to choose what stays. When you want a delivery plan built around your own constraints, that is part of my iOS app development work.

Originally published at puneetpal.dev.

Laravel API for Mobile Apps: Backend Design Guide (2026)

Puneetpal Arneja — Sat, 24 Oct 2026 01:57:00 +0000

Laravel works well as the backend for iOS, Android, Flutter, and React Native apps if the API is designed around one fact: you cannot force users to update. Version every route, return one predictable JSON shape, issue revocable per-device tokens, paginate with cursors, and ship a minimum-supported-build check in the first release.

A web frontend and its API deploy together, so a breaking change is fixed in one release. A mobile client is different. Once a build is approved and installed, it keeps calling your API exactly as it was compiled to, sometimes for years. Every decision below follows from that constraint. This guide covers the design side; for hardening the same API, pair it with the Laravel API security checklist.

Is Laravel a good backend for a mobile app?

For most product apps, yes. Laravel gives a mobile team authentication, queues, scheduled jobs, notifications, file storage, validation, and an ORM out of the box, so a small team can ship a complete API without assembling a framework from parts. It is a weaker fit for workloads dominated by long-lived connections or heavy computation.

Where it fits well:

Transactional product apps: accounts, orders, bookings, content feeds, subscriptions, admin workflows. This is the bulk of what mobile apps need from a server.
Small teams who want one conventional codebase that a new hire can read on day one.
Apps with background work (push notifications, upload processing, syncing with third-party systems), because queues and the scheduler are first-party.

Where I would look elsewhere, or add a separate service:

Real-time systems where WebSocket fan-out is the core product rather than a feature.
CPU-heavy pipelines such as media transcoding or model inference, which belong in dedicated workers.
Teams whose entire skill set is in another ecosystem. The best backend is one your team can operate at 2 a.m.

How should a Laravel API shape JSON for mobile clients?

Return every resource through an API Resource class and every error through one envelope. Mobile decoders are strict: Swift’s Codable and Kotlin serializers fail on unexpected types, so a field that is sometimes a string and sometimes null, or an error that is sometimes HTML, becomes a crash or a blank screen in production.

Laravel API Resources decouple the response from the database schema, which is exactly what an API serving old app builds needs. Rename a column and the resource keeps emitting the old key.

class OrderResource extends JsonResource
{
    public function toArray(Request $request): array
    {
        return [
            'id' => $this->public_id,          // never the auto-increment key
            'status' => $this->status->value,  // backed enum, stable strings
            'total' => [
                'amount' => $this->total_minor, // integer minor units, not floats
                'currency' => $this->currency,
            ],
            'updated_at' => $this->updated_at->toIso8601String(),
        ];
    }
}

Rules that keep decoders working across releases:

Only additive changes within a version. Adding a field is safe; removing, renaming, or changing a type is a new version.
Money as integer minor units with a currency code. Dates as ISO 8601 with an offset.
Enums as strings, and clients that map unknown values to a fallback case instead of failing the whole decode. Swift: give the enum a raw value and a custom init(from:) that falls back to .unknown.
JSON for every error, including 401, 404, 422, 429, and 500. A mobile client cannot do anything useful with an HTML error page.

Laravel decides whether to render an exception as JSON from the Accept header, and mobile HTTP clients do not always send one. Force it for API routes in bootstrap/app.php and render your envelope from the same place:

// bootstrap/app.php
return Application::configure(basePath: dirname(__DIR__))
    // ...routing and middleware...
    ->withExceptions(function (Exceptions $exceptions) {
        $exceptions->shouldRenderJsonWhen(fn (Request $request) => $request->is('api/*'));

        $exceptions->render(function (ApiException $e, Request $request) {
            return response()->json([
                'error' => [
                    'code' => $e->code(),          // stable, machine-readable
                    'message' => $e->getMessage(), // display text, safe to change server-side
                    'fields' => [],
                ],
            ], $e->status());
        });
    })->create();

The code is what the app branches on, so it never changes once shipped. The message is copy you can reword without a release. fields carries per-field validation messages for 422 responses and is otherwise empty, so the client always has one decoder and one error-handling path.

Which authentication should a mobile app use with Laravel?

For a first-party app, use Laravel Sanctum API tokens: one token per device, named after the device, scoped with abilities, and revocable by deleting a row. Reach for Passport only when you need an OAuth2 server for third-party clients. Self-contained JWTs make revocation harder than it needs to be.

Sanctum vs Passport vs JWT for mobile apps

Factor	Sanctum tokens	Passport (OAuth2)	JWT package
Token type	Opaque, stored hashed in the database	OAuth2 access and refresh tokens	Signed, self-contained token
Revoke one device	Delete the token row	Revoke the token and its refresh token	Needs a denylist until expiry
Refresh flow	Not built in; use expiry plus re-login or a custom rotate endpoint	Built in	Provided by the package
Third-party clients	Not designed for it	Yes, including authorization code with PKCE	Not designed for it
Setup and upkeep	Low, first-party	Higher: clients, grants, keys	Moderate, community-maintained
Best fit	Your own iOS, Android, Flutter, or React Native app	Platforms where partners need delegated access	Stateless verification across several services

Issue the token from a login endpoint that takes a device_name, so users can see and sign out individual devices, and a lost phone can be revoked without logging out everything else:

$token = $user->createToken(
    $request->input('device_name'),    // e.g. "iPhone 16 - iOS"
    ['orders:read', 'orders:write'],   // abilities checked per route
    now()->addDays(30),                // per-token expiry
);

return ['token' => $token->plainTextToken];

On both sides of the token lifecycle:

Store the token in the platform keystore: the iOS Keychain or Android Keystore-backed storage. Never in UserDefaults, plain shared preferences, or AsyncStorage.
Set an expiry. Sanctum tokens never expire unless expiration in config/sanctum.php is set (minutes) or createToken() gets a date. Pair it with a scheduled sanctum:prune-expired so the table does not grow forever.
Revoke on risk events. A password change, account recovery, or “sign out all devices” should delete the relevant token rows immediately.
Treat a 401 as a state, not an error. The client clears the stored token and returns to sign-in once, rather than retrying in a loop.

For the client side of the same problem, the mobile banking security checklist covers token storage, session handling, and the controls a security review expects in the app.

How do you version a Laravel API so old app builds keep working?

Put the version in the URL, starting at /api/v1 on day one, and only make additive changes inside a version. Every request carries the app’s version in headers, and a public policy endpoint tells each platform its minimum and recommended version, so you can prompt or force an update before you remove anything an old build depends on.

// routes/api.php
Route::get('/app/version-policy', VersionPolicyController::class);   // public, cacheable

Route::prefix('v1')->middleware('app.version')->group(function () {
    Route::post('/auth/token', [AuthController::class, 'store'])
        ->middleware('throttle:auth');

    Route::middleware(['auth:sanctum', 'throttle:api'])->group(function () {
        Route::get('/orders', [OrderController::class, 'index']);
        Route::delete('/auth/token', [AuthController::class, 'destroy']);
    });
});

The contract is small. The client sends X-App-Version (semver), X-App-Build and X-App-Platform (ios or android) on every request. GET /app/version-policy?platform=ios returns minimum, recommended, latest, store_url and an optional message. The app.version middleware answers any request from a version below minimum with 426 Upgrade Required and the same JSON, and adds Deprecation and Sunset headers below recommended. A Swift client using URLSession:

struct VersionPolicy: Decodable {
    let minimum: String
    let recommended: String
    let latest: String
    let storeUrl: URL
    let message: String?
}

func fetchVersionPolicy() async throws -> VersionPolicy {
    var components = URLComponents(string: "https://api.example.com/app/version-policy")!
    components.queryItems = [URLQueryItem(name: "platform", value: "ios")]
    var request = URLRequest(url: components.url!)
    let info = Bundle.main.infoDictionary
    request.setValue(info?["CFBundleShortVersionString"] as? String, forHTTPHeaderField: "X-App-Version")
    request.setValue(info?["CFBundleVersion"] as? String, forHTTPHeaderField: "X-App-Build")
    request.setValue("ios", forHTTPHeaderField: "X-App-Platform")

    let (data, response) = try await URLSession.shared.data(for: request)
    guard (response as? HTTPURLResponse)?.statusCode == 200 else {
        throw URLError(.badServerResponse)
    }

    let decoder = JSONDecoder()
    decoder.keyDecodingStrategy = .convertFromSnakeCase
    return try decoder.decode(VersionPolicy.self, from: data)
}

A deprecation policy that holds up:

Log X-App-Version on every request. You cannot retire a version without knowing which builds still call it.
Run versions side by side. v2 controllers reuse the same services and models; only the resources and request validation differ.
Soft prompt, then hard block. Raise recommended first, and only raise minimum once usage of the old version is negligible by your own numbers, not by the calendar.
Treat a 426 from any endpoint as “show the update screen”, so even a build that never fetched the policy shows something sensible.

Header-based versioning (Accept: application/vnd.example.v2+json) is tidier in theory. In practice a URL prefix is easier to grep in logs, route in a load balancer, and explain to the person writing the Android client.

How should pagination and sync work for offline-first apps?

Use cursor pagination for lists and an updated_since parameter for sync. Offset pagination skips or duplicates rows when data changes between page requests, which happens constantly on a phone with a flaky connection. Cursors are stable, and delta sync means the app downloads only what changed.

$orders = $request->user()->orders()
    ->withTrashed()   // include soft-deleted rows as tombstones
    ->when($request->filled('updated_since'), fn ($query) =>
        $query->where('updated_at', '>', $request->date('updated_since')))
    ->orderBy('updated_at')
    ->orderBy('id')   // tie-breaker: cursor columns must be unique together
    ->cursorPaginate(min($request->integer('per_page', 50), 100));

return OrderResource::collection($orders);

Details that decide whether sync is reliable:

Deletions must sync too. Soft deletes with a deleted_at in the resource let the client remove local rows it would otherwise keep forever.
The client stores the server’s timestamp, not the device clock, as its next updated_since value. Return it in the response; device clocks drift.
Writes are idempotent. Accept a client-generated UUID or Idempotency-Key header on create requests, store it with the row, and return the existing record on a repeat, so a retry after a dropped response does not create a duplicate.
Conflicts have a rule decided up front: last write wins, server wins, or a 409 with both versions that the app resolves. Undefined behaviour here turns into data loss.

How do you send push notifications from Laravel?

Send them from queued jobs, never inside the request. Store each device’s push token against the user and platform, dispatch a queued notification, and deliver through APNs for iOS and Firebase Cloud Messaging for Android. For APNs, use token-based authentication with a .p8 signing key rather than a certificate; the key does not expire and works across all your apps. For FCM, use the HTTP v1 API; the legacy API was shut down in 2024 and some older packages still target it.

Register tokens on every launch with an upsert endpoint. Push tokens change, and the app is the only party that knows when.
Prune invalid tokens when APNs returns 410 or FCM reports UNREGISTERED, otherwise the queue spends its time on devices that no longer exist.
Keep payloads small and non-sensitive. Send an identifier and let the app fetch the detail over the authenticated API; lock screens are not private.
Separate queues by priority so a bulk marketing send cannot delay a time-sensitive transactional alert.

How should mobile apps upload files to a Laravel backend?

Let the app upload directly to object storage with a short-lived presigned URL, then tell the API the upload finished. Streaming large photos or videos through PHP ties up workers on slow mobile connections. Laravel generates presigned S3 upload URLs, so the API only authorizes and records the file.

['url' => $url, 'headers' => $headers] = Storage::disk('s3')
    ->temporaryUploadUrl(
        'uploads/'.$request->user()->id.'/'.Str::uuid().'.jpg',
        now()->addMinutes(5)
    );

return ['upload_url' => $url, 'headers' => $headers];

A presigned PUT cannot enforce a size limit, so after the app confirms the upload, check the object server-side: Storage::size() against your cap, the real content type from the bytes rather than the extension, and that the key belongs to the caller. Push any processing such as thumbnails onto a queue. Never trust the file type the client claims.

What rate limits does a mobile API need?

At minimum, a general per-user limit for authenticated routes and much stricter limits on login, one-time codes, and password reset. Key limits by user ID when authenticated and by IP otherwise. Mobile carriers put many users behind shared IP addresses, so IP-only limits punish legitimate users.

Laravel’s named rate limiters express this in a few lines. The numbers below are starting points; tune them from your own traffic:

// AppServiceProvider::boot()
RateLimiter::for('api', function (Request $request) {
    return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
});

RateLimiter::for('auth', function (Request $request) {
    return [
        Limit::perMinute(5)->by(strtolower((string) $request->input('email')).'|'.$request->ip()),
        Limit::perMinute(20)->by($request->ip()),
    ];
});

The throttle middleware adds Retry-After and X-RateLimit-* headers to the 429 for you; make sure the body is still your error envelope, and make the client honour Retry-After with jittered backoff. A client that retries instantly on failure turns a brief incident into a self-inflicted outage. The OWASP API Security Top 10 lists unrestricted resource consumption and broken authorization among the most common API risks, and both apply directly to mobile backends.

What should you monitor on a mobile backend?

Error rates and latency per endpoint, broken down by app version and platform. A backend change that looks healthy overall can break one older build entirely, and you will only see it if requests carry the client build and your dashboards can filter by it.

Request context: client platform, build, and a request ID. Generate the ID in middleware, put it in Log::withContext(), and return it in a response header so support can match an app report to a server log.
Error tracking on both sides, with the same request ID visible in app crash reports and server exceptions.
Queue health: backlog depth, failed jobs, and job duration. Laravel Pulse or a hosted APM covers the basics; Horizon adds detail if you run Redis queues.
Version adoption: requests per build over time, which is the number you need before retiring an API version.

Where does Next.js fit next to a Laravel mobile backend?

Beside Laravel, not in front of the mobile app. Next.js works well for an admin dashboard, marketing site, or web version of the product, consuming the same Laravel API or a separate web backend-for-frontend (see Next.js web development). The mobile app should call Laravel directly through its versioned API.

Adding a Next.js layer between the app and Laravel means two services that must both stay compatible with every installed build. Keep the mobile contract in one place. If you are planning the stack as a whole, my Laravel API backend development service covers the API, admin tooling, and infrastructure together.

What should you build first?

Before the first app release, get the decisions that are expensive to reverse in place: the /api/v1 prefix, the response and error envelope, per-device Sanctum tokens with an expiry, the version-policy endpoint with a minimum version, and app version logging. Everything else in this guide can be added later without breaking installed apps. Cursor pagination is the one I would move up the list if the app has any list that grows, because switching from offset to cursor later changes the response shape.

If you are still scoping the product, the mobile MVP playbook covers what to include in a first release, and mobile app development covers the client side. When you want the backend designed and built alongside the app, I offer Laravel backend and API development for mobile apps.

Frequently Asked Questions

Should a mobile app use Laravel Sanctum or Passport?

Use Sanctum when your own first-party app is the only client. It issues revocable per-device tokens with very little setup. Choose Passport only when you need a real OAuth2 server, for example when third-party developers or partner apps must obtain delegated access to your users' data.

How long should a Laravel API keep supporting an old version?

Long enough that almost no active installs still depend on it. Set the window from your own analytics on build adoption rather than the calendar, announce it in-app before removal, and raise the minimum version in the version policy (old builds then get a 426 and an update screen) so the last stragglers see an update prompt instead of broken screens.

Can Laravel handle real-time features for a mobile app?

Yes. Laravel broadcasting with Laravel Reverb, or a hosted WebSocket service, covers live updates while the app is in the foreground. Push notifications through APNs and FCM still handle the background case, because mobile operating systems suspend open sockets when the app is not active.

Should a mobile app call Laravel directly or go through Next.js?

Call Laravel directly. A mobile client gains little from an extra hop, and every layer is another thing that has to stay backward compatible with old app builds. Next.js earns its place for the admin panel, marketing site, or a web client, not as a proxy in front of the mobile API.

Originally published at puneetpal.dev.