We just released Laravel Mobile Pass, a package that lets you generate those Apple and Google passes from a Laravel app and send updates to already issues passes.

Together with the package, we also published a demo site where you can create Apple Wallet passes and push an update so you can see it all working on your own iOS device.

Dan Johnson and I have been working on it for a while. Let me walk you through what it can do.

A simple example

Here's the shortest useful thing you can build with it. An Apple Wallet boarding pass for a flight:

use Spatie\LaravelMobilePass\Builders\Apple\AirlinePassBuilder;
use Spatie\LaravelMobilePass\Enums\BarcodeType;

$mobilePass = AirlinePassBuilder::make()
    ->setOrganizationName('Artisan Airways')
    ->setSerialNumber('ART-103')
    ->setDescription('Boarding Pass')
    ->addHeaderField('flight-no', 'ART103', label: 'Flight')
    ->addHeaderField('seat', '66F')
    ->addField('departure', 'ABU', label: 'Abu Dhabi International')
    ->addField('destination', 'LHR', label: 'London Heathrow')
    ->addSecondaryField('name', 'Mary Smith')
    ->setBarcode(BarcodeType::Pdf417, 'ART-103-66F')
    ->save();

Calling save() gives you back a MobilePass model. Nothing is written to disk. The whole pass (fields, images, barcode, the lot) lives as a row in the mobile_passes table that ships with the package.

Handing the pass to a user

So in the example above, the $mobilePass variable contains MobilePass Eloquent model. It plays nice with the parts of Laravel you already know. Here are a few ways you can use it to send a mobile pass to a user

Return it straight from a controller. The model implements Responsable, so the package takes care of signing and serving the .pkpass file.

// in a controller
return $mobilePass;

Attach it to an outgoing mail. The model also implements Attachable, which means you can drop it into a Mailable's attachments() method and Laravel figures out the rest.

class FlightBooked extends Mailable
{
    public function __construct(public MobilePass $mobilePass) {}

    public function attachments(): array
    {
        return [$this->mobilePass];
    }
}

The user taps through, sees the pass preview in Apple Wallet, and taps Add.

Apple then calls back to your app to register the device against the pass. The package handles that endpoint and stores the registration. That link between pass and device is what lets you push updates later.

Pushing a live update

Here's the part I like most. If a seat gets reassigned or a gate changes, you can update the pass from your app and the version on the user's phone updates within a minute, without them doing anything.

$mobilePass->updateField('seat', '13A');

Under the hood, the package dispatches a job that notifies Apple through APNs. Apple pings the device. The device fetches the new version from your server. Wallet swaps the old pass for the new one.

Now this all happens silently, without warning the user. If you want the user to see a notification when the value changes, pass a changeMessage:

$mobilePass->updateField(
    'seat',
    '13A',
    changeMessage: 'Your seat was changed to :value',
);

Very cool! If you tap that notification, you,'ll notice that Passbook highlights what was changed.

Google Wallet is supported too

Google Wallet works a little differently. Google wants you to declare a Class once (a shared template for a batch of passes) and then issue individual Objects against that class. The package covers both.

use Spatie\LaravelMobilePass\Builders\Google\EventTicketPassBuilder;
use Spatie\LaravelMobilePass\Enums\BarcodeType;

$mobilePass = EventTicketPassBuilder::make()
    ->setClass('spring-tour-2026')
    ->setAttendeeName('Mary Smith')
    ->setSection('Floor A')
    ->setRow('12')
    ->setSeat('24')
    ->setBarcode(BarcodeType::Qr, 'TICKET-12345')
    ->save();

Returning $mobilePass from a controller does the right thing on either platform. Android users get redirected to the Google Wallet save URL. iPhone users get the .pkpass download. The Responsable implementation picks the right response for the platform the pass was built for.

A few more things worth knowing

Picture the boarding pass from earlier. You hand it to the user three days before the flight. They install it and promptly forget it exists. An hour before departure, or the moment they walk into the airport, the pass drifts onto their lock screen without them doing anything. By the time they reach the gate, their thumb is already on it.

That trick is called pass relevance, and wiring it up is two calls on the builder:

$builder
    ->addLocation(latitude: 25.2528, longitude: 55.3644)
    ->setRelevantDate($flight->departs_at);

The location turns on the geofence. The date turns on the clock. Combine both and Wallet shows the pass at the right place and the right moment. It's the small thing that makes a Wallet pass feel like it belongs on the device instead of inside an email.

Passes don't need to stick around once they've served their purpose. When a coupon has been redeemed or a ticket is from last night, call expire() on the model and Wallet greys it out and drops it from the lock screen:

$mobilePass->expire();

If you issue Google Wallet passes, you probably want to know when someone actually saves one to their Wallet, or later removes it. Google pings your app on both events. The package listens for those callbacks and fires regular Laravel events you can subscribe to:

Event::listen(GoogleMobilePassSaved::class, function (GoogleMobilePassSaved $event) {
    // $event->mobilePass is now on the user's Wallet
});

Drop in a listener if you want to record activations, send a thank-you email, or kick off any other flow. It's the kind of integration that would otherwise involve reading Google's callback spec and signing JWTs by hand. You shouldn't have to.

Try it live

We put up a demo at mobile-pass-demo.spatie.be. Pick a pass type on the landing page, scan the QR code with your iPhone, install the pass, and hit the simulate-change button. Your Wallet pulls the new version a moment later. The full source of the demo app is on GitHub if you want to see how everything ties together.

In closing

At Laracon India 2025, Dan Johnson showed me a prototype he had been hacking on for generating Apple Wallet passes. I loved the idea, we decided to team up, and this package is what came out the other end. It took a while to get here, but we finally gave it the polish we wanted.

Mobile passes aren't new. Apple shipped Wallet (back then called Passbook) with iOS 6 in 2012, and Google followed with their own Wallet passes a few years later.

Given the two have been around for that long, I was surprised nobody had built a solid Laravel package around either platform yet. Luckily there's one now. Hope you like it!

The code is on GitHub. The full documentation is at spatie.be.

This is one of the many packages we've created at Spatie. If you want to support our open source work, consider picking up one of our paid products.

We care about using AI in a particular way. It should help support agents write better replies, not substitute for them. The human stays in charge of the conversation, and the model does the unglamorous work of drafting, rephrasing, and suggesting links. There There is in private beta right now, and you can apply for early access at there-there.app.

We're building There There with Laravel and Inertia, and we lean heavily on the latest features Inertia v3 brings. This post is about another one: prefetching on hover.

Using prefetch on hover

In a helpdesk, a support agent flips between views constantly. My open tickets, unassigned, waiting, spam, team views, custom filters. Every switch triggers a fresh page load against a different filter. If each switch blocks on a round-trip, the sidebar starts to feel like dead weight.

Inertia v3 has a built-in prefetching API that covers this neatly. Instead of waiting for the click, we fetch the view's data as soon as the cursor hovers over the link, and keep the result in a short-lived cache so the actual navigation feels instant.

Here's the core of our sidebar view link.

<Link
    href={buildViewUrl(view)}
    prefetch="hover"
    cacheFor="30s"
    preserveState={isOnTickets}
    preserveScroll={isOnTickets}
>
    <Icon className="size-4" />
    <span>{view.label}</span>
</Link>

prefetch="hover" is the whole mechanism. After the cursor sits on the link for 75ms, Inertia fires the underlying request in the background. When the agent actually clicks, the response is already in memory, and the page swaps without a network wait.

cacheFor is where the real tuning happens. The default is 30 seconds. For our ticket views, that's a sweet spot: long enough that flipping back and forth feels free, short enough that the counts don't go visibly stale. You can push it higher for more static lists, or drop it to "0" for views where freshness matters more than speed.

Here it is in action. The cursor hovers, Inertia warms the cache in the background, and the click lands on data that's already there.

One small gotcha is worth flagging. When an agent navigates away from a view, you often want to cancel any in-flight requests so you don't paint stale data. The obvious call is router.cancelAll(), but that also cancels prefetches that are happily warming the cache for views the agent is about to visit.

Inertia v3 lets you scope that. Here's how we cancel the active visit without touching prefetches.

router.cancelAll({ async: false, prefetch: false });

The flags tell Inertia to keep background prefetches and async visits (like an infinite scroll) alive, while cancelling the normal page visit. The agent gets an immediate navigation and the sidebar stays primed for the next move.

In closing

Prefetching on hover is one of those features that costs almost nothing to turn on and changes how the app feels. One prop, a cache duration, and you're done. The cancellation scoping is the one detail worth knowing about, because without it you'll undo your own optimisation the first time you navigate away from a view.

You can read more in the Inertia v3 prefetching guide. And if you'd like to try There There yourself, we're in private beta right now and you can apply for early access at there-there.app.

One thing we care about in particular is using AI to help humans craft better responses, not to replace them. The agent stays in charge of the conversation. The model just helps them reply faster and a little sharper. There There is in private beta right now, and you can apply for early access at there-there.app.

We're building There There with Laravel and Inertia, and we lean heavily on the latest features Inertia v3 brings. In this post I'd like to give one example: optimistic updates.

Using optimistic updates

A support agent toggles a lot of small things in the course of a day. Adding a tag to a ticket, granting a teammate access to a channel, flipping a workflow on or off. Each of those is a single click that triggers a server round-trip.

If the UI waits for that round-trip before showing the change, the app feels sluggish. Not broken, just slow. And in a tool you live in all day, that compounds.

Inertia v3 ships with a first-class optimistic updates API that handles this nicely. Instead of waiting on a response, we immediately update the UI to reflect the change and let Inertia roll it back if the request fails.

Here's how it looks on our member detail page. An admin can toggle whether a teammate belongs to a team. The list of teams comes in as a prop, and we render a switch next to each one.

{teams.map((team) => (
    <div key={team.id}>
        <span>{team.name}</span>
        <Switch
            checked={team.is_member}
            onCheckedChange={() => handleToggleTeam(team)}
        />
    </div>
))}

When the switch is flipped, handleToggleTeam runs.

function handleToggleTeam(team) {
    const optimistic = router.optimistic((props) => ({
        teams: props.teams.map((t) =>
            t.id === team.id ? { ...t, is_member: !t.is_member } : t,
        ),
    }));

    if (team.is_member) {
        optimistic.delete(removeTeamMember.url({
            team: team.ulid,
            user: member.ulid,
        }), { preserveScroll: true });

        return;
    }

    optimistic.post(addTeamMember.url({
        team: team.ulid,
        user: member.ulid,
    }), {}, { preserveScroll: true });
}

The function we pass to router.optimistic receives the current props and returns the keys we want to patch. Inertia applies that patch immediately, so the toggle in the UI flips before the request leaves the browser. When the response comes back, Inertia merges the real server props on top.

I like the chained style here because the same optimistic patch can lead to either a post or a delete. We capture the optimistic builder once and pick the verb after.

Here it is in action. The toggle flips immediately, and the request happens in the background.

For simpler cases there's a second style. You pass optimistic straight as an option to the verb. Here's our workflow toggle:

function handleToggle(workflow) {
    router.patch(workflowToggle.url(workflow.ulid), {}, {
        optimistic: (props) => ({
            workflows: props.workflows.map((w) =>
                w.id === workflow.id ? { ...w, is_enabled: !w.is_enabled } : w,
            ),
        }),
    });
}

Same idea. You describe the patched shape, hand it to Inertia, and let it deal with the rest.

If the server returns a non-2xx response, Inertia reverts the optimistic change automatically. There's no manual restore code to write. Validation errors land where you'd expect, and only the keys you touched in the callback are snapshotted, so unrelated state stays untouched. Concurrent requests each carry their own snapshot, which means a slow request won't undo a faster one that already returned.

In closing

Optimistic updates used to mean keeping a parallel copy of state, reverting it on rejection, and reasoning carefully about race conditions. With Inertia v3, you describe the next state and that's it. The whole interaction is about ten lines.

You can read the official documentation in the Inertia v3 optimistic updates guide. And if you'd like to try There There yourself, we're in private beta right now and you can apply for early access at there-there.app.