Multiple accounts and app sharing: three problems

Searches about multiple accounts and sharing an app arrive from three completely different situations, and the advice that fits one of them actively damages the other two. One person holding several accounts of the same service has a switching problem. A team passing one login around has a control problem. Several people using one Mac has an operating system problem. The first step is deciding which of the three is on the table, because the three fixes have nothing in common.

Three situations wearing the same words

The switching problem looks like this: one address for the current employer, one for a client, one personal, all on the same service, all needed on the same afternoon. Nothing is being shared with another human being. The friction is entirely about which session the browser will hand over when a link is clicked.

The control problem looks different: one paid seat, one password, four people who need it. Nobody is switching accounts, because everyone is using the same one. The friction shows up later, at the moment somebody leaves, or the moment a two factor prompt appears on a phone belonging to a person who is on holiday.

The third problem is domestic or hardware bound: one Mac, several macOS user accounts, one application that everyone wants to use. This one has an official answer built into the operating system, and it is the least discussed of the three because it is the least painful.

Everything below treats them separately. Applying the wrong answer is not neutral. Solving a control problem with a browser profile leaves the audit trail exactly as absent as it was, and solving a switching problem by sharing credentials creates a control problem that did not previously exist.

One person, several accounts of the same service

Some services build multi account support into the product. Google is the most documented example, and its help pages are unusually frank about where the separation stops.

Your accounts have separate settings, but in some cases, settings from your default account might apply. Source: support.google.com

The detail behind that sentence is the part worth knowing. Google states that when several accounts are signed in at once, it may be unable to determine which one is in use, for instance when a new browser window opens, and that in those cases settings from the default account may be applied. Web and app activity and ad personalisation are named directly. The country used by the Google Play Store follows the default account too, which is why a person signed into accounts in two countries can be shown the wrong catalogue.

The default account, in most cases, is simply the first one signed in during that browser session. That is the whole rule, and it explains a category of confusing behaviour: everything works correctly until the browser is restarted in a different order.

Services that do not build a switcher at all are the harder case. There the only separation available is the one the browser provides, because a login lives in a cookie and cookies belong to a browser profile rather than to a tab. A second profile, or a browser that gives each app its own persistent window, is the entire toolkit. The differences between products in that second category are covered in Compared with Wavebox.

Several people, one login

Sharing a password is fast to set up and expensive to unwind, and the expense arrives in a predictable order.

Two factor authentication breaks first. A code sent to one person's phone means everyone else waits for that person to be awake and reachable. Moving to an authenticator app helps only if the shared secret is stored somewhere the whole group can reach, which recreates the original problem one layer down.

The audit trail disappears next. Every action in the service is attributed to one account, so a deleted record, an outbound message, or a settings change has no author. Nothing in the tool can answer the question of who did it, and reconstructing that from memory is unpleasant in exactly the situations where it matters.

Offboarding is the expensive one. Removing one person's access means changing the password, which signs out everyone. What should be a single administrative action becomes a coordinated event, and the pressure to postpone it is what leaves former colleagues holding working credentials.

Before any of that, there is a smaller failure that shows up on day one. Many web applications assume one session per account and behave oddly when that assumption is broken. Two people editing the same record at the same time may produce a last write wins result with no warning. Some services sign out the earlier session when a new one starts, which turns a shared login into a queue where each person quietly evicts the last. Read receipts, presence indicators and notification badges all become meaningless, because the service is describing a person who does not exist.

Support is the other early casualty. When something goes wrong, the vendor will correspond with the address on the account, and any identity check will be aimed at that one person. A group that cannot answer a security question about an account it shares has a slow week ahead of it.

There is also a plain commercial point. Plans are usually priced per seat, and the terms of service set out what an account holder may do with the credentials. Those terms differ between products and they change, so the only reliable answer is to read the current terms for the specific plan in use rather than to assume the common case.

The supported ways to share access without sharing a password

Several services provide a mechanism for exactly this, and the mechanisms are more capable than most people expect. Gmail delegation is a good worked example because the limits are published.

Google states that a personal gmail.com account can add up to 10 delegates and a work or school account up to 1,000, and that with typical use 40 delegates can access one account at the same time. A delegate can read, send and delete messages. When a delegate sends a message, the delegate's own address appears on it, which is the audit trail that a shared password destroys. A delegate cannot change the password and cannot use chat.

A delegate is someone who can read, send, and delete emails in your account for you. When a delegate sends a message from your account, their email address appears. Source: support.google.com

Two operational details matter when setting this up. The invitation sent to a delegate expires after one week, and access can take up to 24 hours to begin working. A team that grants delegation on the morning it is needed will conclude that it is broken.

Arrangement	Who the service thinks acted	Removing one person	Two factor prompts
Shared password	The account, not the person	Password change, everyone signed out	Land on one device
Delegated access	The delegate	Remove that delegate only	Stay with the account owner
Separate seats	Each person	Deactivate that seat	Each person has their own

Delegation is not the only supported shape. Team products commonly ship two others. The first is a role or permission level, which lets a second person into the same workspace with a narrower set of abilities, so a bookkeeper can see invoices without being able to change bank details. The second is a guest or external collaborator, which admits somebody to one channel, one project or one document rather than to the whole account. Both cost less than a full seat in most pricing models, and both keep each person's name attached to their own actions.

The pattern to look for in any product is a settings page that names people rather than devices. If such a page exists, the supported route is there, and it is almost always cheaper in total than the cleanup that shared credentials eventually require.

Where a service offers none of these, a password manager with a shared vault is the fallback rather than the goal. It fixes distribution and rotation. It does not create an audit trail, because the service still sees one account.

Sharing an application between user accounts on one Mac

This third situation has a clean answer. An application installed in the top level Applications folder is available to every user account on that Mac. An application installed in a personal Applications folder inside a home directory belongs to that user alone. Most installers default to the first, which is why this usually works without anyone thinking about it.

What does not carry across is everything the application stores per user. Preferences, sign in state, browser profiles, and keychain entries all live inside each home directory, so the same application launched by two macOS accounts behaves like two separate installations that happen to share one copy of the code. For a licence tied to a person rather than to a machine, that distinction is the one that decides whether a second activation is needed.

Switching between the accounts does not require logging out. Apple documents fast user switching as an administrator enabled option:

If your Mac has multiple users, an administrator can turn on fast user switching, which allows you to quickly switch between accounts when more than one user is logged in at the same time. Source: support.apple.com

The control is added from the Menu Bar section of System Settings and can be placed in the menu bar, in Control Center, or both. The cost is memory, since both sessions stay loaded, and files that need to move between the accounts have to go through the shared folder rather than through either home directory.

Worth noting for the switching problem: separate macOS user accounts also separate browser sessions completely, which makes them a heavy but genuinely airtight answer to holding two accounts of one service. Heavy because every switch means re entering a password and leaving behind every open window on the other side.

Deciding which one is actually the problem

One question separates them. Does anyone else need to see what is inside the account.

If the answer is no, this is a switching problem, and the fix belongs to the browser. Named sets of applications, each holding its own session, remove the question of which account is in front by making it visible, which is the idea behind Workspaces.

If the answer is yes, this is a control problem, and no browser setting will touch it. The fix is delegation, an extra seat, or a role in the service itself. A browser can only decide which credentials get sent. It cannot record who was sitting at the keyboard.

If the answer is that several people share the machine rather than the account, the fix is macOS user accounts and fast user switching, and no additional software is required at all.

What to change first

Write down the three or four services in question and mark each one as switching, control, or machine. The list usually splits, and the control entries are the ones to move to delegation or a proper seat this week. For the switching entries, a browser that keeps each application in its own window with its own session removes the daily cost, and SpaceDeck is built around that shape on macOS.