Libby for Mac: library books in a window that stays open

The App Store search comes up empty, and that is not an oversight. OverDrive publishes Libby for phones and tablets, and for a computer it publishes a web address. That answer is correct and slightly unsatisfying, because reading a borrowed novel in the same window that holds work email is not reading. What follows is what the web version actually is, the one thing about it that can lose data, and how to give it a window that behaves like an application.

Why the Mac route is a web address

Libby's help centre lists compatible devices precisely. The app can be downloaded on iOS 10 and later from the App Store, on Android 7.1 and later from Google Play, and on newer Fire tablets from the Amazon Appstore. Then comes the line that answers the search: a Windows computer, a Mac computer or a Chromebook uses Libby in a web browser at libbyapp.com, and the suggested browsers are the latest versions of Chrome, Safari, Firefox or Edge.

That is the whole of it. There is no Mac build, no Catalyst version, and no desktop installer waiting behind a sign-in. The getting started page repeats the same split, listing app stores for the three mobile platforms and libbyapp.com for the three computer platforms.

What that means in practice is that the reading surface on a Mac has no icon, no Dock presence and no place in the application switcher. It shares a window with whatever else the browser is doing, which for most people is the reason a borrowed book goes unread for three weeks and is returned automatically.

The site is the app, not a preview of it

It is worth being clear that libbyapp.com is not a cut down catalogue. The Shelf works there, with Loans, Holds, Timeline and Notices, and magazines appear on the Magazine Rack. Search and the library browse view are there. Tags work, including tagging a title to keep track of it without borrowing. The reading and listening interfaces are there. The functional gap between the browser version and the mobile app is much narrower than the packaging suggests, with one significant exception covered further down.

Where Libby keeps its data

This is the part that changes how a Mac setup should be arranged, and it is documented in an unusually direct way.

Libby has no account. OverDrive's help centre states that Libby does not work the way most services do, that there is no true Libby account, and that consequently there is no Sign out button. Data is split in two. Some of it is tied to the device, specifically tags and the timeline. The rest is tied to the library card: loans, holds, borrowing history and reading progress.

For a browser, "tied to the device" means tied to that browser's stored site data. Tags built up over two years and a timeline of everything read live in the browser profile that visited libbyapp.com, not on a server keyed to a username. The help centre is explicit that tags and timeline cannot be recovered once deleted unless a recovery passkey exists or Libby is in use on another device.

The failure mode to know about

Two ordinary actions can therefore remove data that feels like it should be safe. The first is resetting the app from inside Libby: Menu, then Reset Everything under Your Information, which OverDrive describes as removing all data associated with Libby from that device. That one is deliberate and clearly labelled.

The second is less obvious. Clearing cookies and site data in the browser, or using a cleanup utility that does the same thing, removes the device side of Libby along with everything else. Loans and holds come back when the library card is added again, because those belong to the card. Tags and the timeline do not. The card survives a wipe and the reading history does not.

Back up before rearranging anything

OverDrive documents the fix, and it should be done before any change to how Libby is opened. The route is Menu, then Back Up Your Data under Your Information, then Create Recovery Passkey, then following the prompts to use Face ID, a fingerprint, a PIN or another method. The passkey is stored in the device's password manager, and OverDrive notes that Libby does not receive biometric information or the device PIN.

Availability has limits worth reading. Passkeys can be created in Libby on Android 9 and later, iOS 17 and later, and some desktop computers, and the option does not appear on a device that does not support them. Passkeys update automatically and one passkey can be used on several devices, so this is normally a one time task. A setup code is the other documented route for moving data to another device.

With that in place, a wiped browser profile becomes an inconvenience rather than a loss.

Three ways to give Libby a window

Route	macOS needed	Session and tags	Name and icon
Safari, Add to Dock	Sonoma 14 or later	Separate from Safari	Set at creation, changeable
Chrome, Install page as app	Any current Chrome	Shared with that Chrome profile	Managed by Chrome
A site to app tool	Varies by tool	Separate per app	Set freely

Apple documents the first route in detail. From macOS Sonoma 14 onward, open the page in Safari and choose File then Add to Dock from the menu bar, or use the Share button then Add to Dock, type a name and click Add. The result is saved to the Applications folder inside the home folder and opens from the Dock or Spotlight. Apple states that it functions independently of Safari and shares no browsing history, cookies, website data or settings with it.

That independence cuts both ways here, and it is important to understand which way. A Safari web app built from libbyapp.com starts with an empty site data store, so it begins as a fresh Libby: the library card has to be added again and existing tags are not there. With a recovery passkey that is a two minute recovery. Without one, the tags in the old Safari profile stay in the old Safari profile.

Chrome's route is documented as More, then Cast, save, and share, then Install page as app, with an Install button appearing at the right of the address bar on some sites. Because the installed app belongs to the Chrome profile that created it, an existing Libby setup in that profile carries straight over, tags included. That is the least disruptive route for anyone who has been using Libby in Chrome for years.

A tool that turns a website into a standalone Mac app is the third option, and the reason to reach for it is usually more than one card or more than one reader. Two people sharing a Mac, or one person holding cards at a city library and a university library, are two separate Libby setups, and separate apps with separate profiles keep them apart in a way that one browser cannot. The Features page covers what is set per app in that arrangement.

Settings that matter for a reading window

Name it for what it is. Libby is the name on the site, so a window called Libby is already better than a tab. If two windows exist for two cards, name them after the libraries instead.

Size it for reading, not for browsing. A reading window wants to be tall and no wider than a comfortable line of text, which is roughly the opposite of how a browser window is usually left. Setting that once and letting the window remember it is most of the benefit.

Turn on a confirmation before ⌘Q if the tool offers one. Quitting mid chapter is harmless for progress, because reading position is tied to the card and syncs, but quitting an audiobook mid sentence is annoying enough to be worth a dialog.

Hide the tab strip. The entire point is a window that cannot fill up with other pages. A reading window with eleven tabs has become a browser again.

Think about what the window opens on. The Shelf is the sensible landing place for a reader who already has loans out, because it goes straight to Loans, Holds, Timeline and Notices. The library browse view is the better choice for someone who mostly uses Libby to look for the next book. Either is better than a home screen that has to be clicked through, and any route that allows the starting address to be set to the current page makes this a one time decision.

Leave restoring the previous view turned on if the tool offers it. Reading position itself is tied to the card and comes back regardless, but returning to the same page of the same title rather than to a shelf is the difference between picking a book up and finding it again.

Notifications are worth a decision

Libby surfaces notices for loans and holds inside the app, under Notices on the Shelf, with control over what is announced under Menu and Notifications. Whether a wrapped window should also be allowed to raise macOS notifications depends on how holds are used. Someone waiting on a popular title benefits from a hold becoming available appearing on screen. Someone who reads one book a month does not need the interruption, and turning the permission down for that window alone is the cleaner choice.

What a window cannot give back

There is one clear limit, and OverDrive states it without ambiguity: an internet connection is always needed to use libbyapp.com. Offline downloading is a mobile app behaviour. The help centre describes books and audiobooks being downloaded over Wi-Fi by default in the Libby mobile app, with a card and checkmark icon marking a downloaded loan and a cloud icon marking one that will be streamed.

A wrapped window is still the website, so it inherits that requirement exactly. Building a Mac app from libbyapp.com does not create an offline library, does not cache a novel for a flight, and does not change how magazines are handled. Anyone whose main need is reading without a connection should be reading on a phone or tablet, where the app handles it, and treating the Mac as the place to browse, borrow and manage holds.

Nothing about a window changes lending either. Titles, formats, copies and wait times are decided by each library, and the help centre notes that selection varies because every library chooses what to offer. A better window does not shorten a queue.

What to change first

Create a recovery passkey from Menu, then Back Up Your Data, before touching anything else. Then build one window from libbyapp.com, preferring the Chrome route if a Libby setup with years of tags already lives in Chrome, and size it as a reading column rather than a browser. If two cards or two readers share the Mac, Kagemusha is one way to give each one its own app with its own tags and timeline.