Kahoot for the desktop on a Mac: running a quiz from one window

A search for Kahoot for desktop usually starts with an assumption that turns out to be wrong: that somewhere there is an installer, and that finding it is the whole job. On a Mac the picture is stranger than that. There is a Mac line on the App Store listing, there is a browser editor that does the real work, and there is a separate join screen that players use. Three surfaces, one search term. The question worth answering is not where the download lives. It is which of those three surfaces needs to stop being a browser tab.

What the App Store listing actually says

The listing is Kahoot! Play & Create Quizzes, published by Kahoot ASA, in the Education category. It is free with in-app purchases, the download is 296.4 MB, and it is offered in English plus twenty more languages. The platform row at the top of the page reads iPhone, iPad, Mac.

The compatibility section is where the answer to the search sits. It names four platforms in one block: iOS 16.0 or later for iPhone, iPadOS 16.0 or later for iPad, macOS 13.0 or later for Mac, and visionOS 1.0 or later for Apple Vision. One listing covering that range is not four separate products. It is a single build that the developer has made available across several platforms, which is why the Mac line carries no separate version number of its own.

Kahoot says the same thing in plainer words on its own app page. The frequently asked questions section there describes the app as a free quiz and trivia game app for iOS, Android, and macOS. So macOS is named by the company, not just inferred from a store page.

What makes the search confusing is the sentence immediately underneath. When the same page explains how to get the app, it tells the reader to search for Kahoot in the App Store for iPhone and iPad, or Google Play for Android. The download instructions do not mention the Mac at all. A Mac user reading top to bottom sees macOS in one paragraph and two phone stores in the next, and concludes that something is missing.

Nothing is missing. The listing is real and installs. The gap is between what the app is good at and what a person sitting at a Mac is usually trying to do.

Where building and hosting really happen

Kahoot splits its product across two addresses, and neither of them is an installer.

The editor lives at create.kahoot.it. That is where a quiz gets built, where question types are chosen, where images and time limits are set, and where a draft sits until it is ready. It is a full authoring tool in a browser window, and it is the surface a teacher or a host spends the most time in.

The join screen lives at kahoot.it. That page does one thing: it takes a game PIN and a nickname. Kahoot's own documentation is explicit that players do not need to download anything and do not need an account. They open the join page in whatever browser is on whatever device they have, type the PIN, and they are in. Only the person running the game needs to be signed in.

That division explains the shape of a typical session. One machine shows the questions to the room. Everyone else answers on a phone. The machine showing the questions is almost always a laptop, and on a Mac that means a browser window doing three jobs at once: displaying the game, holding the host account, and sitting next to every other tab that happens to be open.

So the practical target is not a Mac binary for the whole product. It is a dedicated window for the host surface, which is a website, and which behaves better when it stops sharing a window with everything else.

Why a browser tab is a poor container for a live game

A live game is the one moment where the container matters more than the content.

The first problem is that a tab is closeable. Cmd+W is muscle memory, and it is one key away from Cmd+Q. A host who closes the game tab in front of thirty people has a worse afternoon than a host who has to click one extra time.

The second problem is that hosting is usually presenting. The game window goes on a projector or a shared screen, and everything the browser puts around it goes too: the tab strip with whatever else was open, the bookmarks bar, the address bar showing a URL that reveals a half-finished lesson plan. A window with only the game in it removes that whole category of accident.

The third problem is accounts. A teacher with a school account and a personal account, or an ambassador running sessions for two organizations, gets signed out of one by signing into the other, because a browser holds one set of cookies per profile. Switching back and forth in the middle of a week is a chore that never stops being a chore.

The fourth is Cmd+Tab. A window that appears in the app switcher can be reached in one gesture from a slide deck or a gradebook. A tab cannot. During a live game, where the host is moving between the question on screen and something else on the same machine, that difference is felt every few minutes.

None of this is a complaint about the browser. The browser is where Kahoot works, and it works well there. The complaint is about the window.

Comparing the routes to a dedicated window

Stated as a window rather than an app, the options are few and the differences are concrete.

Route	Setup	Shows in Cmd+Tab	Separate sign-in from the browser	Fits
Browser tab	None	No	No	Occasional play
Pinned tab	One click	No	No	One account, light use
App Store listing	Install from the store	Yes	Yes	Playing and browsing on a Mac
Safari, Add to Dock	Two clicks	Yes	Yes	One account, no installer wanted
Chrome, install page as app	Three clicks	Yes	Follows the Chrome profile	Already living in Chrome
Site to app tool	Pick the URL, build once	Yes	Yes, per app	Two accounts, or the editor and the join page side by side

Apple documents the Safari route, and the detail that matters is what the resulting window does not share.

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. In this way, it keeps your browsing separate, similar to using a Safari profile. Source: support.apple.com

The menu path is File then Add to Dock, or the Share button then Add to Dock, and it requires macOS Sonoma 14 or later. The window is saved to the Applications folder of the home folder, so it turns up in Spotlight and the Dock like anything else.

Chrome has an equivalent step. The path is the three dot menu, then Cast, save, and share, then Install page as app. Chrome's own help page describes the result as a way to have a website work as an app, reachable from the launcher. The difference from the Safari route is that a Chrome web app follows the Chrome profile it was installed from, so two accounts means two Chrome profiles rather than two independent windows.

A site to app tool covers the case the built in routes handle least well, which is wanting more than one of these windows at the same time with unrelated sign-ins. The same approach works for any address, so the supported services list is a reasonable place to see which everyday sites people put in the Dock this way.

Two windows, not one

The useful insight for a host is that the editor and the join screen are different jobs, and they benefit from being different windows.

The editor is a working surface. It is open for twenty minutes while a quiz gets built, then closed. It holds the account that owns the content. It wants to be next to a lesson plan, a textbook PDF, a spreadsheet of names.

The host view is a performance surface. It is open for ten minutes, it goes on a projector, and nothing else should be visible in it. Its worst failure mode is showing something that was not meant for the room.

Keeping those two in one browser window means the performance surface inherits the working surface's clutter. Splitting them means the projector only ever sees the game. On a Mac that is two Dock icons instead of one, which sounds like more but is less to think about, because each icon has one job.

There is a third window worth considering for anyone who runs sessions for a group they do not administer, which is the join page itself. Having kahoot.it in a window of its own makes it trivial to demonstrate joining on the shared screen without touching the host session, and it is the fastest way to check that a PIN is being read correctly before the room starts typing.

What the plan costs, and what it does not buy

Pricing is worth stating carefully, because it is easy to assume that paying unlocks a desktop application. It does not. What changes is the player limit and the feature set.

On the schools pricing page, the individual tiers in US dollars are a $3 per month tier billed annually at $36 with a player limit of 50, a $7 per month tier billed annually at $84 with a limit of 100, a $12 per month tier billed annually at $144 with a limit of 200, and a $19 per month tier billed annually at $228 with a limit of 800. Paying month to month costs $9, $15, $25 and $34.99 respectively. The page states that all prices include VAT. There is also a free tier, listed as Kahoot! Go, for the basics of game based learning.

Two things follow. The first is that the player limit is the number to check before anything else, because a class of 35 and a lecture of 120 land in different tiers. The second is that none of these tiers is the answer to the desktop question. The window is free to fix on any plan, including the free one.

The App Store listing also carries in app purchases with their own names and prices, which is how a household subscription gets bought rather than a school one. Anyone who already pays through a school or district should check what the account covers before buying anything a second time inside the app.

What to change first

Decide which single surface is worth a window: the editor, if most of the time goes into building quizzes, or the host view, if most of the time goes into running them in front of a room. Give that one a window using Safari's Add to Dock, and only add the second when the first proves it earns a Dock slot. If the answer turns out to be two windows with two different sign-ins, that is the point at which a tool like Kagemusha is doing something the built in routes cannot.