A Leonardo AI desktop app on a Mac: generating in its own window

Generation work does not fit the rhythm a browser was designed for. A prompt goes in, a queue forms, and several minutes pass before anything is worth looking at. During those minutes the tab is supposed to sit there quietly, and instead it is one keystroke from being closed, one crowded tab strip from being lost, and one notification from being interrupted. Anyone who has rebuilt a prompt after an accidental Cmd+W has already worked out why people search for a Leonardo AI desktop app on a Mac.

What Leonardo publishes for a computer

The pricing page opens with a claim that sounds like it settles the question and does not.

One subscription, all platforms Source: leonardo.ai

The platforms being referred to are the creative surfaces, not the operating systems. The same heading spells it out: create across image, video, design and motion. One subscription covers all of that, which is genuinely useful to know before comparing plans, but it says nothing about where the software runs.

Where it runs, on a Mac, is a browser. The Leonardo.Ai image generator published by Leonardo Interactive Pty Ltd is free on the App Store, and Apple's metadata for that listing does not include Mac in its device support. That closes off the route that quietly solves this problem for a lot of services, where an iPhone or iPad build can be installed on Apple silicon because the developer allowed it. On a Mac there is no Leonardo application to install, native or borrowed from iPad.

So the platform on a Mac is the web app, and improving the experience means improving the window around it rather than waiting for a download that is not coming.

The plan decides how much the window matters

The pricing page lists four monthly tiers, all quoted before tax, and the differences between them explain why a lost session hurts more on some plans than others.

Plan Monthly Fast Tokens Token Bank Personal AI models Simultaneous generations
Free $0 150 per day 150 Not listed Not listed
Essential $12 8,500 per month 25,500 10 2
Premium $30 25,000 per month 75,000 20 3
Ultimate $60 60,000 per month 180,000 Not listed above Not listed above

Two lines in that table change how a working session should be arranged.

The free plan's allowance is 150 fast tokens per day rather than per month. A daily allowance means a wasted generation is a wasted fraction of today, not of a large monthly pool, so a session interrupted halfway through a set of variations costs real output. Anyone on the free tier has the strongest practical reason to protect the window.

The paid tiers move to monthly allowances with a token bank several times larger, and they add concurrency: two simultaneous generations on Essential, three on Premium, with a generation queue of ten listed on Premium. Premium also lists unlimited image generation for select models at a relaxed pace. Relaxed pace and a queue of ten describe the same situation from two directions, and it is a situation where the page needs to stay open and undisturbed for a long time while work completes in the background.

The pricing page also notes that the free tier keeps creations public while the paid tiers make them private, and that quality settings move from basic to enhanced. Those are worth checking against the actual use before choosing a tier, since a client project and a personal experiment have different requirements there. Personal collections are limited to one on the free tier and listed as unlimited from Essential upward, which matters as soon as a second project starts. The number of personal AI models also rises with the tier, from ten on Essential to twenty on Premium, so anyone training styles rather than prompting from scratch should read that column before the token column.

Why a queue and a browser tab work against each other

A generation queue is a background process with a visible front end. Browsers are built for the opposite: foreground pages, most of them closed within minutes, with whatever is behind treated as less important. Four specific frictions follow.

The close is one keystroke away

Cmd+W shuts the frontmost tab without asking, and in a strip of twenty tabs the frontmost is regularly not the intended one. Work that has been queued is generally safe on the server side, but the prompt being refined, the reference image loaded into the editor and the settings arrived at over twenty minutes are not the kind of state that survives a closed tab gracefully.

Background tabs are not privileged

Browsers reclaim resources from pages that have sat in the background for a long time. A page holding a canvas, several loaded images and an open connection is a heavy page by any measure. A window holding one site and nothing else meets fewer of these problems simply because fewer things are competing inside it.

The editor wants the whole window

Prompt work is narrow. Canvas and editing work is not. Precision editing that preserves composition and character needs screen area, and a window that also carries a tab strip, a bookmarks bar and an address bar is giving away a strip of that area permanently.

Coming back to it is a search

Twenty tabs deep, the favicon is four pixels of colour. Returning to a queue that finished ten minutes ago means scanning the strip or typing the address again, which is an odd amount of effort to reach something already open.

What belongs in the window, and what does not

A dedicated window is more useful when it is pointed at one job rather than at a whole account. Leonardo spans image, video, design and motion on one subscription, plus billing, model libraries, personal collections and a developer API. Putting all of that behind a single icon recreates the tab strip inside a smaller window.

The division that holds up in practice is between producing and everything else. The window is for producing: the prompt, the queue, the editor, the current set of variations. Billing, plan changes, reading documentation, browsing other people's work and anything involving a support form stay in the ordinary browser, where a back button and a tab strip are genuinely wanted. A window with no navigation controls is a poor place to work through a settings page.

Two practical consequences follow. The first concerns downloads. Finished images have to land somewhere, and a separate window will use the same download location as the rest of the system unless told otherwise, which means a generation session quietly fills the same folder as invoices and email attachments. Deciding on a destination before the first batch saves a sorting job later.

The second concerns how many windows are worth having. Someone whose work is entirely still images needs one. Someone alternating between image generation and video work has a case for two, pointed at the two surfaces, because switching between them is then a Cmd+Tab rather than a navigation inside a window that has no back button. That is a judgement about workflow rather than a rule, and it is cheap to test: build the second window, use it for a week, and delete it if the icon never gets clicked.

What does not belong in either category is the account itself. Anyone sharing a machine, or running a personal account beside a studio account, should decide which sign-in the window holds before building it, because a window that quietly holds the wrong account is a worse problem than a tab strip.

The route macOS already provides

Apple added a documented way to turn any page into a standalone application, at no cost.

Starting with macOS Sonoma 14, you can use Safari to save any webpage as a web app, so that you can use it independently of Safari. Source: support.apple.com

In Safari the path is File then Add to Dock. Apple's page states the result is saved to the Applications folder of the user's home folder and can be opened from the Dock or from Spotlight, which makes it a real item on disk rather than a bookmark with an icon attached.

Four of the settings Apple documents earn their keep here. The URL the window opens can be set, so it can land on the generation view rather than a marketing page. The navigation controls can be hidden, which returns the strip of vertical space that a canvas actually uses. The name and icon are chosen by the reader, so the Cmd+Tab entry reads as a tool. And a web app can be added as a login item so it opens at sign-in.

There is one detail worth reading before relying on notifications, because getting it wrong is easy and silent.

Web apps support an additional notifications feature: The number of unread notifications appears as a red badge on the app's icon in the Dock. To use this feature, respond to the website's notifications request in the web app, not in Safari. Source: support.apple.com

For work that finishes on its own schedule, a badge on a Dock icon is the difference between checking a window every two minutes and getting on with something else. Granting the permission in Safari first and expecting the web app to inherit it is the mistake to avoid.

Where the free route stops

The other documented behaviour is the one that decides whether Add to Dock is enough.

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

Its own cookie store means its own sign-in, which is exactly what is needed by anyone running a personal account alongside a client or studio account. It is also where the limits start. The route is Safari only, so a session living in Chrome has to be established somewhere new. It produces one window per URL, so a second account is a second web app assembled, named and given an icon by hand. The available behaviour is the set of switches Apple exposes, and nothing more.

A site to app tool covers the ground past that line: a window with its own session regardless of which browser holds the main one, a second window for a second account on the same host, a prepared icon, and control over how the window behaves. The supported services list shows the pattern applied across the sites people keep open for hours, and generation tools sit in the same family as the other long running work that nobody wants to lose track of.

What to change first

Open the generation view in Safari, choose File then Add to Dock, hide the navigation controls to get the vertical space back, and allow notifications inside the new window rather than in Safari so the Dock badge works. Run one full session of variations in it before changing anything else. Where a second account or a non-Safari session is the obstacle, Kagemusha handles the same idea with the session separation built in.

Frequently asked questions

Is there an official Leonardo AI app for macOS?

No. The App Store listing for the Leonardo.Ai image generator is published by Leonardo Interactive Pty Ltd and Apple's metadata for it does not include Mac in its device support, so it cannot be installed on Apple silicon the way some iPad apps can. On a Mac the product is reached through a browser.

Does the free plan really reset every day?

The pricing page lists 150 fast tokens per day on the free tier, against monthly allowances on the paid tiers. That is worth planning around, because a daily allowance cannot be saved up for a large batch and an interrupted session costs a share of that day's output.

Will queued generations be lost if the window is closed?

Queued work generally continues on Leonardo's side, so the images are not the fragile part. What a closed window loses is everything in front of it: the prompt being refined, the reference images loaded into the editor, and the settings arrived at over the previous half hour.

Why do Dock notification badges not appear after setting up a web app?

Because the permission was almost certainly granted in Safari rather than in the web app. Apple's documentation states that the notifications request must be answered in the web app itself for the unread count to appear as a badge on its Dock icon. Clearing the site's data and asking again from inside the window is the fix.

Can a personal account and a client account be used at the same time?

Yes, by giving each one its own window. Apple's documentation states that a Safari web app shares no cookies or website data with Safari, so one account can stay signed in inside the web app while the other stays signed in to the browser. A third account needs a third window with its own session.

Back to all posts