IDrive for Mac: the backup console in a window of its own

Searching for IDrive for Mac turns up two different things wearing the same name. One is a downloadable application that runs on the machine and does the actual backing up. The other is a web console in a browser, which is where backup sets across several computers get inspected, restores get started, and account settings live. Both are official, both are necessary, and the split is the reason people end up unsure which one they are supposed to be using. The client is a solved problem: download it and it works. The console is the part that spends all day as a forgotten tab, and that is the part worth rearranging.

What IDrive publishes for the Mac

The download page lists three separate clients, and only two of them have a Mac build.

The Full Client for Mac is the main one. The version currently offered is 3.5.10.81, released in July 2024, with older builds going back to 2012 still listed underneath it for accounts that need them. The stated system requirement is macOS High Sierra 10.13 or greater, which is an unusually low floor and good news for an older Mac that newer software has started refusing.

The Thin Client also has a Mac build, offered as version 3.5.10.23 from July 2024. Its description is the interesting one. IDrive describes it as an application with a limited interface that performs backup, restore, and settings management via the web. That is not a compromise, it is a design statement: the vendor itself treats the browser as the place where a backup estate is managed, and the local process as the thing that carries out instructions.

The Basic Client, described as a simplified version of the full client for quickly setting up a backup of an entire computer or selected folders, is listed with a Windows download only.

Why the client's release date matters

A desktop client dated July 2024 is not abandoned, but it is stable in a way a web console is not. Features, reporting views, and account controls land in the browser first and reach a native client later, if at all. Anyone whose work with IDrive is mostly inspection rather than configuration is going to spend most of their time in a browser regardless of which client is installed, which makes the container that browser page sits in a real question rather than a cosmetic one.

The console is a web page, not the client

Signing in happens at the account login form on idrive.com, and what opens is the part of the product that no local application replaces. Managing computers over the web is listed among IDrive's own features, and for good reason: a laptop, a desktop, a NAS, and a server can all report into one account, and no single machine's local client can show the state of the others.

Restores are the clearest case. A restore initiated from the console reaches a machine that is not the one being sat in front of. So is anything to do with the account itself: which computers are registered, how much of the plan is used, and which plan is in force.

The two surfaces do different jobs

Job	Local client	Web console
Running a scheduled backup	Yes	No
Seeing every registered computer at once	No	Yes
Restoring to a different machine	No	Yes
Checking plan usage and registered devices	No	Yes
Working while the machine is offline	Yes	No

Read that table as a division of labour rather than a ranking. The consequence is simply that a browser page is a permanent fixture of using this product, not a place visited once during setup.

Why that page deserves a window

Three things make a backup console different from an ordinary tab.

The first is duration. A restore of any size is measured in hours, and the page that reports its progress needs to survive an afternoon of unrelated browsing. A tab in a strip of twenty is one accidental close away from losing its place, and one browser restart away from an uncertain state.

The second is the session. A browser profile is shared by everything inside it. Clearing cookies to fix an unrelated site, or a privacy extension that prunes storage on a schedule, takes the console session with it. Signing back in is not difficult, but it happens at the exact moment someone is trying to confirm that a restore is still running.

The third is retrieval. Command and Tab reaches a browser, not a backup console. On a day when a machine has failed, the number of seconds between wanting the console and seeing it is the difference between a calm hour and a bad one.

Three routes to a window of its own

None of these involve IDrive. They are macOS and browser features applied to a URL.

Route	Requires	Session	Extensions	Opens on
Safari, Add to Dock	macOS Sonoma 14 or later	Separate from Safari	Per web app, off by default	Any URL chosen
Chrome, Install page as app	Chrome	Shared with the Chrome profile	Inherited from the profile	Any URL chosen
A site to app tool	macOS 12 or later	Separate per app	Supported per app	Any URL chosen

Apple's note on Safari web apps sets out the first route precisely. From macOS Sonoma 14 onward, File then Add to Dock saves a webpage as a web app that functions independently of Safari, sharing no browsing history, cookies, website data, or settings with it. The app lands in the Applications folder of the home folder, so nothing system wide is installed and no administrator password is requested, which matters on a managed Mac. Its settings panel carries an Application Name field, an Application URL field with a Set to Current Page button, an icon picker, and an Extensions tab.

Chrome's equivalent is documented in its help pages under More, then Cast, save, and share, then Install page as app. The installed app belongs to the Chrome profile that created it, so the console session carries over with no second sign in. The same inheritance is what stops a second account living beside the first.

The third route exists because the other two build one window at a time from a menu. A purpose built tool gives each app its own browser profile, keeps Chrome extensions working inside it, and creates several windows from a list. The Features page covers the differences that matter in practice.

More than one account, more than one window

IDrive's plan structure is where multiple sessions come from. Basic is free with 10 GB and no credit card required. Personal covers one user across multiple computers, starting at 5 TB. Team starts at five computers and five users. Business offers unlimited users across multiple computers, servers, and NAS devices.

Those shapes produce predictable situations. A consultant with a personal account and a client's business account. A family account alongside a work account. An administrator who holds the Business login and a second, smaller account for a side project. In every case the requirement is two consoles alive at once, not one console that switches, and one browser profile cannot do that because it holds one session per site.

Profile isolation is the whole of the answer. Two windows, two cookie stores, two logins, neither aware of the other, both open on the same screen. The Supported services list shows which sites most often get treated this way, and a backup console is a textbook case because the cost of signing into the wrong one is measured in restored files.

Choosing the address the window opens on

The detail that decides whether this is worth the effort is which address the window is built from. Building it from idrive.com lands on a marketing page, and every launch then costs two clicks to reach anything useful. Building it from the login form lands on the sign in screen, and once the session is established the window opens on the console itself.

A better habit is to sign in first, navigate to the view that a particular job starts from, then copy the address out of the bar and point the window at that. Apple's web app settings make this correctable rather than final: the Application URL field has a Set to Current Page button, so a window built on the wrong view can be repointed without being rebuilt. Chrome's installed apps do not offer the same field, so the address is chosen once at creation.

Name the window after the job

Two windows on the same service are indistinguishable in the Dock unless they are named and iconed apart. A window called IDrive says nothing when there are two of them. Windows called Home Backup and Client Backup say everything, and the application switcher starts offering the distinction a person is actually holding in their head rather than the name of a product.

The same reasoning applies to icons. Both routes allow any image, and spending one minute on two visibly different icons removes a whole category of mistake, which is the mistake of starting a restore in the wrong account. On a backup console that is not a cosmetic concern.

What does not follow the window

Three habits break on day one, and all three are worth testing before a routine is rebuilt.

Extensions do not come along by default on the Safari route. A password manager that was filling the IDrive login inside the browser is absent from a new Safari web app until it is enabled in that web app's Extensions tab. The first sign in therefore happens in a window that has never seen the vault, which is where most people conclude the route is broken.

Links clicked elsewhere still open in the default browser. A console link in an email alert opens wherever macOS sends links, not in the dedicated window. That is an operating system routing rule rather than a fault in any route, and it means the browser copy stays in the picture. Keeping that browser signed into the same account avoids a detour later.

Downloads and file dialogs behave normally. A restore that ends in a download, and a file picker used to choose where restored files land, both use the standard macOS panels, because the window is a real application as far as the system is concerned. Notifications are the one permission that has to be granted again: Apple's documentation notes that the Dock icon can carry an unread count, and that the request must be answered inside the web app rather than in the browser.

What to change first

Install the Full Client from IDrive's download page, because the local half of the job genuinely needs it, then build one window on the console login and leave the browser out of the routine. If a second account or a second estate needs its own icon after that, a tool such as Kagemusha keeps several windows with separate sessions without repeating a menu sequence for each one.