Why a native client app beats a mobile gallery link

TL;DR — Almost every gallery platform works on a phone. Far fewer put the photos in the client’s camera roll, keep a 400-photo download alive when the screen locks, or reach the client at all once the delivery email is buried. Those gaps are structural: they come from what a browser is allowed to do on iOS, not from how well the gallery is built. Be especially wary of a branded “client app” that turns out to be a web page saved to the home screen — it inherits every one of those limits, and the photos never actually reach the client’s device.

Your clients are going to open their photos on a phone. Not exclusively — someone will pull them up on a laptop to pick the frame-worthy one — but the first look, the one they take screenshots of and send to their mother, happens on a phone within minutes of your delivery email landing.

So the interesting question isn’t whether a gallery is “mobile friendly.” Everything is mobile friendly. The question is what happens over the next twenty minutes: where the photos end up, whether the download finishes, and whether the client can find them again next week.

Those answers differ sharply depending on whether your client is in a browser or a real installed app. Here’s what actually separates them, and where a browser is genuinely fine.

Where the photos actually land

This is the difference that matters most, and it’s the one clients feel immediately.

When someone downloads a gallery in a mobile browser, they get a ZIP file. It goes to the Files app on iOS, or the Downloads folder on Android. It is not in their camera roll. It is not backed up to iCloud or Google Photos. It does not appear when they search their photos for “beach.” To do anything with it, they have to find the Files app, tap the archive to unzip it, then share images out one at a time.

Most people never do this. They screenshot the gallery instead — and now the photo they send to their family is a compressed screenshot of your work, with your gallery’s UI cropped out of the edges.

An installed app writes directly to the photo library. In ApertureBook’s app, a bulk download saves each photo to the camera roll and groups them into an album named after the gallery, so “Sarah & Tom — Wedding” shows up as its own album in Photos. From there the photos behave like every other photo the client owns: backed up, searchable, AirDropped, set as a lock screen, posted without an export step.

That single difference — album versus archive — changes what the client does with your photographs.

The middle column is the one to watch, and it deserves its own section.

The download that dies halfway

Delivering 400 full-resolution photos to a phone is a long transfer. On hotel wifi it can run for several minutes.

In a browser, that transfer is at the mercy of the tab. The client locks their phone, switches to Instagram, or the browser decides to reclaim memory — and the download is gone, usually with no useful error. They start over. Often they give up and email you asking for a Dropbox link, which is the outcome you bought gallery software to avoid.

A native app can hold the system awake for the duration. ApertureBook’s app keeps the screen from sleeping while a bulk download runs and releases it the moment the transfer finishes. And if a download is interrupted anyway, it resumes from where it stopped rather than restarting from the first photo.

It also has to respect that iOS lets people grant photo access in degrees. A client can allow “add photos only” rather than full library access — in which case album grouping isn’t available, so the app saves each photo to the camera roll without it, instead of failing. The client gets their photos; they just don’t get the album. Handling that quietly is the kind of thing nobody notices, which is the point.

How the client finds out at all

Your delivery email competes with everything else in an inbox. It’s opened once, or it isn’t.

Push notifications are the only channel that reaches a phone’s lock screen, and this is where the browser gap is widest — not because web push doesn’t exist, but because of how it works on iOS. Since iOS 16.4, Safari supports web push, but only for sites the user has explicitly added to their Home Screen via Share → Add to Home Screen. An ordinary Safari tab has no access at all. So a client who taps your gallery link and never performs that obscure two-step ritual can’t receive a notification, no matter what the platform supports.

Practically, that means web push reaches close to none of your clients, because almost nobody adds a photo gallery to their Home Screen.

An installed app asks for notification permission the normal way, at a moment that makes sense, and registers with Apple’s and Google’s push services. After that you can tell a client their gallery is ready, their proofs are back, or their invoice is due, and it arrives on the lock screen.

The white-label “app” that is a bookmark

There’s a third category between browser and app, and it’s the one worth being sceptical about, because it is sold hardest.

The pitch is appealing: your own branded client app, with your studio name and logo, no app store, no review process, available instantly. Some platforms put it on a higher-priced tier as a marquee feature.

What’s actually being shipped is a progressive web app — a website with an icon and a manifest file. The client “installs” it by opening a link in Safari, tapping Share, scrolling the sheet, and choosing Add to Home Screen. Nothing is downloaded. Nothing is reviewed by Apple or Google. The result is a bookmark that opens a browser without the address bar.

This isn’t a fringe reading of the technology; it’s how the pattern is openly marketed across SaaS generally. Vendors describe unlocking “a white label mobile app using progressive web apps” once you set a custom domain — the app is the white labelling.

To be fair to the format: a PWA is a legitimate and often sensible way to build software. It updates instantly, it costs a fraction of two native codebases, and for a dashboard or a membership portal it’s frequently the right call. The problem is narrower than “PWAs are bad.” It’s that photo delivery depends on precisely the capabilities a PWA doesn’t have.

• It cannot save to the camera roll. A PWA runs in the browser sandbox and has no access to the iOS Photos framework. Saving to the photo library is exactly the sort of privileged operation that access is withheld for. So a branded PWA gives your client the same ZIP in the Files app that a plain browser link does — with your logo on it.
• Push barely exists. On iOS, web push requires that the client completed the Add to Home Screen ritual, and it arrived only in iOS 16.4. An ordinary Safari tab has no access at all. So notifications work solely for the small fraction of clients who performed a multi-step manoeuvre most people have never heard of.
• Storage is capped. iOS holds PWAs to a small cache quota — roughly 50MB — which is under two full-resolution photographs. Meaningful offline access to a wedding gallery isn’t on the table.
• The install is the weak point. A native app is one tap from a store listing, a flow every phone owner has completed dozens of times. Add to Home Screen is a five-step sequence through a share sheet. Clients who won’t install a real app from the App Store are not more likely to complete a stranger sequence, and every client who skips it gets a plain web page.

The part nobody mentions: the photos never leave

The deeper issue is architectural. A PWA is a window onto the vendor’s storage. No copy is ever transferred to the client’s device — every view is a fetch from the server.

That makes your client’s access entirely dependent on the gallery staying live: on your subscription staying current, on your storage not filling, on the gallery not passing its expiry date. The “app” on their home screen is only ever as durable as your account. When the gallery goes, the icon remains and opens to nothing.

Here’s the honest version, because it applies to us too: every hosted platform reclaims storage eventually. ApertureBook galleries auto-expire on a date you set, and when they do the photos are deleted to free space — the same as anywhere else. Permanent hosting for every gallery you’ve ever shot is not a service anyone sells at these prices.

The distinction isn’t who hosts forever. Nobody does. It’s whether the client ended up with their own copy before that day arrives. Photos saved to the camera roll are the client’s, on the client’s phone, backed up to the client’s iCloud — and they survive your gallery expiring, your plan changing, and your leaving the platform entirely. A PWA never produces that copy, so the moment hosting ends, so does the client’s access.

That’s the question to put to any “branded app” feature: when this gallery expires, what does my client still have?

Getting in without a password

The other half of “the client can’t find their photos” is login.

ApertureBook’s app claims its own links, so a client tapping a link in your email opens the app, on the right screen, already signed in — not a browser tab asking them to authenticate again. If the app isn’t installed, the same link opens on the web instead. The client never has to know which case they’re in.

That’s a capability a browser can’t fully replicate: a web page can’t intercept a link destined for another app, and it can’t carry a signed-in session across from mail to browser as reliably.

The parts that aren’t the photos

Delivery is only part of what a client does with you. They also sign a contract and pay an invoice, and both are noticeably worse in a mobile browser.

• Signing. A drawn signature in a browser is a canvas element fighting the page’s own scroll — clients routinely scroll the page instead of drawing a line. The app uses a native signature pad, so drawing is just drawing.
• Paying. In the app, paying an invoice opens the platform’s own payment sheet, which is where Apple Pay and Google Pay live. That’s a face-scan-and-done transaction versus typing a 16-digit card number on a phone keyboard. Cards that get typed on phones get abandoned.

The small things that add up

None of these decides a purchase, but together they’re most of why an app feels better than a website that happens to be on a phone:

• Photos fade in from a blurred placeholder generated from the image itself, so the grid is never a wall of gray boxes.
• Scrolling a large gallery recycles images properly instead of stuttering as it loads.
• Selecting photos gives a small haptic tap, so bulk selection feels physical.
• The session is stored in the device keychain, not in browser storage that Safari may clear after a week of not visiting — which is exactly the interval at which a client comes back to show someone.

That last one is worth dwelling on. Safari aggressively evicts storage for sites you haven’t opened recently. A client who viewed their gallery once, then returns a fortnight later to show a friend, has a good chance of being logged out and unable to remember how they got in. An installed app is still signed in.

When a browser is genuinely fine

Being honest about this matters, and we ship both — ApertureBook’s client experience runs in a browser as well as a native app, deliberately.

A browser is the right call when:

• The client is a business — a marketing team pulling assets into a brand folder wants a ZIP on a desktop, and an app would be in the way.
• They’re on a desktop already, where downloads land in a real filesystem and none of the mobile constraints apply.
• It’s a one-off, like a headshot session where two files are the whole delivery. Nobody installs an app for two files.
• The client simply won’t install anything. Some won’t. They should still get their photos.

The mistake isn’t offering a browser experience. It’s offering only that, and describing it as an app.

What to check on any platform

If you’re weighing platforms, these five questions separate them faster than a feature grid:

You can answer all seven from a platform’s own documentation and a search of the two app stores, in about ten minutes. Where an answer is hard to find, that’s an answer too.

The one to lead with is the second. If the install instructions involve a share sheet, you are not looking at an app — you are looking at your logo on a website, priced as an app.

---

ApertureBook delivers private client galleries on the web and through a native app your clients install from the App Store or Google Play — with save-to-camera-roll, push notifications, in-app invoice payment and e-signatures included on every plan. See the client app, or start free.