Auction houses with their own app in the store

What a native app actually changes

The honest answer is one thing above all others: push notifications. A bidder who has your app installed can be told that a lot on their watchlist closes in ten minutes. That message arrives on the lock screen, not in an inbox with four hundred unread emails.

For a timed auction, where most of the value is decided in the final minutes, that difference shows up directly in the closing prices. Everything else the app does — browsing the catalogue, bidding, tracking a watchlist — the mobile website also does perfectly well.

Branding, not co-branding

The apps are published under the auction house's own developer account, with their name, their icon and their look. A bidder searching the store finds the auction house. Nothing indicates that the platform underneath is shared with other auction houses, because from the bidder's side it is not shared in any way that matters.

The same platform underneath

The app is not a separate product with its own data. It talks to the same public API as the website, which means catalogue, bids, watchlists and account details are the same records seen from a different surface. A bid placed in the app appears on the website immediately, and vice versa, because there is only one bid.

This also means the app does not need its own back office. Lots published from the Manager appear in the app without a second publishing step.

When it is not worth it

An app is a module on top of the platform, and it carries store review cycles and two more release channels to keep current. If your bidders are trade buyers who sit at a desk, or your sales are infrequent enough that nobody would keep an app installed between them, the mobile website is the better answer and we will say so.

The auction houses that get the most from it are the ones with a returning bidder base and a regular calendar — wine, art, audiovisual, vehicles — where the same people come back every month.