Behind the Scenes of CommunityGlows: From a Browser Extension to a Desktop App

Lire cet article en français

Most of what I write on this blog is about your work: keeping clients apart, organising a day across several networks, posting from the right account. This article is different. It is the one place where I tell the story of how CommunityGlows is built, and why.

You do not need any of it to use the app. But if you have ever wondered why it is a desktop app rather than just an extension, how your profiles stay separate, or why Task Manager shows several processes when a few networks are open, the answers are here, in plain words.

I am Diane. I build CommunityGlows on my own, as an independent artisan. That shapes every choice below: I would rather pick a foundation I can maintain carefully for years than one that looks impressive and slowly eats all my time.

It started as a browser extension

CommunityGlows began as a browser extension for Chrome and Firefox, built with Vue, a common tool for web interfaces. The idea was simple: gather the social networks you use for work in one place, with your useful links and tasks next to them.

An extension is light and familiar. It lives in the browser you already use, and it opens each network in an ordinary tab.

That last point is also its limit. An extension runs inside your browser profile, so it shares that profile’s cookies and sign-ins. If you are signed in to LinkedIn as yourself in Chrome, every LinkedIn tab the extension opens is you as well. It cannot keep “my account” and “my client’s account” of the same network apart. That is not a bug I could fix; it is how browsers protect their own sessions.

The extension is still part of the plan, and it is in preparation. It just cannot do everything.

What I needed next

Two needs pushed me beyond the extension.

The first was the large screen. Working across several networks is calmer when they sit side by side, each in its own panel, instead of hiding in a row of tabs. That became the Bento cockpit of the Windows app, where you arrange networks into Scenes for a task, like “Replies” or “Publishing”.

The second was separation. Community managers and solopreneurs often look after a personal account, a brand and several clients, sometimes on the same network. I wanted each of those contexts to keep its own sign-in, so that switching profile really switches account. And I wanted the same idea to work on Android later.

So the question became: which foundation lets me keep the interface I already had, open many real websites side by side, keep their sessions apart, and reach both Windows and Android?

Choosing the foundation

There were three realistic options, plus a fourth that people often suggest.

Electron wraps a web interface together with its own copy of Chromium, the engine behind Chrome. Many well-known desktop apps use it. It would have given the desktop cockpit the same engine on every computer. But Electron targets desktop only, so Android would have needed a separate approach.

Flutter is a toolkit for building one interface across mobile and desktop. It is excellent when you start from scratch. For me, it meant rewriting the whole Vue interface in another language, Dart, and still embedding the systems’ own web views to show the networks, because Flutter does not display websites by itself. Two interfaces to maintain, for one product.

Forking Chromium, which means building my own version of the browser, would give the deepest control. It would also make me responsible for a whole browser: following every upstream change, shipping security fixes quickly, testing each version. Chromium’s own principles put fast updates and defence in depth at the heart of browser security. That is a full-time job for a team. For a solo artisan, it would have turned CommunityGlows into a browser-maintenance project.

Tauri is what I chose. It keeps a web interface, so the Vue code survived, and it adds native code where a platform needs it: Rust on the desktop side, Kotlin for Android. Most importantly, it does not ship its own browser engine. It uses the one the operating system already provides: WebView2 on Windows, Android System WebView on Android. Tauri documents this engine split.

Here is the honest trade-off, side by side:

What I needed	Tauri with system engines	Bundled or forked Chromium
Keep the existing Vue interface	Yes	Yes
One approach for Windows and Android	Yes, with native adaptations	Not directly
Identical engine on every computer	No, it follows each platform	Yes, on desktop
Keeping the engine updated and secure	Done by Microsoft and Google	My responsibility
Profiles, sessions and the cockpit	Still my work	Still my work

The last row matters most. No engine designs a product for you. Whatever I chose, I would still have to build what a CommunityGlows profile is, how a Scene is restored, and which data stays on your device.

What a WebView is, and what it is not

Each network you open in the app runs in a WebView: a real web engine embedded inside an application. It runs the site’s code, stores its cookies and data, and displays it. It is not a full browser, though. There is no address bar, no extension store, no browser profile manager.

On Windows, CommunityGlows uses WebView2, which is based on the Microsoft Edge engine. In its usual mode, Microsoft keeps it updated broadly at the pace of stable Edge, so the app gets a maintained engine without me packaging a copy of Chromium in every installer. Microsoft describes the WebView2 distribution models.

On Android, the engine is Android System WebView, and its exact version depends on the phone. That keeps the app light, but it means testing on different devices.

So Tauri saved me from maintaining an engine. It did not save me from building everything around it: profiles, opening and restoring panels, keeping sessions, sharing links into the app on Android. That native layer is where much of my time goes, and I think it is the right place for it.

How sessions stay apart

This is the part I care about most, because it is the part that protects your clients.

In the apps, the boundary is always a pair: one profile plus one network. LinkedIn in your “Personal” profile and LinkedIn in your “Client A” profile are two different pairs, so they are two separate sessions.

On Windows

In the Windows app, each profile-and-network pair gets its own dedicated WebView2 data folder. Its cookies, local storage, IndexedDB and cache live there, and never mix with another pair’s. When you sign in to a network in one profile, that sign-in does not appear in another.

On Android

In the Android app, each pair gets its own native Android WebView profile when the phone’s WebView supports it. That is the preferred mode.

Some devices do not support it. There, the app uses a fallback: a single WebView that saves and restores each pair’s cookies and its local storage, kept per exact website address. It works, but it covers less. It does not separate everything a site might store, such as IndexedDB, cached files or service workers, and switching is slower. When the app runs in this degraded mode, it says so rather than pretending the separation is complete.

The limits, said plainly

• Same network, same profile: two copies of one network inside one profile share that profile’s session. That is by design.
• Not a security sandbox: this is separation of sessions and storage. Anyone who can use your Windows or Android account is outside this boundary.
• Password managers stay outside the session boundary.
• The extension has no per-network isolation, as explained above.

A simple check you can do yourself

I test the boundary with what I call the A/B/A check, and you can do it in two minutes:

1. open a network in Profile A and sign in to Account A;
2. switch to Profile B and open the same network: Account A must not be there;
3. sign in to Account B;
4. go back to Profile A: Account A must come back, without any trace of Account B.

If that ever fails for a network, I want to hear about it. For the everyday side of this, see how to separate several social accounts on one device. Sign-ins also stay on the device where you made them; what stays local and what syncs explains the rest.

Why several open networks use memory

If you open Windows Task Manager with a few networks open, you may see several WebView2 processes and more memory in use than you would expect from a small app. That is usually not a leak, and the dedicated article on memory use goes into more detail.

Each panel holds a real website, not a picture of one. LinkedIn, Instagram or Gmail are full applications: their code, images, fonts, connections and sometimes video all have to stay in memory. The rule is simple: the more networks you keep genuinely open, the more pages your computer has to keep alive. It is the same with browser tabs.

Why there are several processes

WebView2 follows the same multi-process design as Microsoft Edge. Work is split between a main process, processes that draw the pages, and helpers for graphics, network or audio. Microsoft explains that the exact number depends on the sites and features in use. Several lines in Task Manager do not mean several copies of CommunityGlows are running.

This separation also helps: a problem in one site is better contained. And the per-pair session folders described above are part of why I do not simply share one engine for everything to save memory. Sharing more could cost less, but it would touch the boundary that keeps your clients apart. I will only change that after measuring real behaviour, not on a theoretical saving.

Warm pages, hidden pages, closed pages

When you leave a network and come back, it feels instant because the page was kept “warm”. That convenience uses memory. The Windows app keeps a limited pool of warm pages: when the pool is full, the oldest hidden ones are closed.

Three things are easy to confuse:

• Hiding a panel removes it from view, but its page may stay in memory for a quick return.
• Closing a page frees it; the next opening loads it again.
• Clearing a session removes the sign-in data, and you will need to sign in again.

Closing a page never signs you out. Your session stays on disk.

What you can do today

• Keep visible only the networks you need for the current task. A focused Scene, like “Replies”, is lighter than everything open all day.
• Pause videos or audio you are not watching; that reduces work for the processor.
• Restart the app when you want a completely fresh start. Closing a panel may not show an immediate drop in Task Manager, because its page can stay warm in the pool for a while.

Opening fewer networks at once is also a focus habit; managing several networks day to day talks about that side.

What I am working on

I am working on putting inactive pages to sleep: using fewer resources while you are not looking, and keeping the session. It is in development, not a shipped feature, and I have not set a date. It needs care: a sleeping page must not miss what matters to you, and it must wake up in the right profile, never in another one.

Would I make the same choice today?

For a desktop-only product whose whole point is browsing, I would look more seriously at shipping Chromium. A uniform engine and browser extensions could be worth the cost there.

For CommunityGlows as it is (an extension, a Windows app, an Android app and one shared interface, made by one person), I would keep this direction. Starting again on a Chromium fork would move my energy into browser maintenance, without solving Android.

That does not make the choice permanent. I keep measuring memory, session stability, how each network behaves and how much the native layer costs. A technical choice is good as long as it serves the people who use the product.

What this means for you

• Your sign-ins to social networks stay on your device.
• In the Windows and Android apps, each profile and network keeps its own session. The browser extension shares your browser’s sessions instead.
• Some behaviour differs a little between Windows and Android, because each uses its own system engine.
• Web engine updates from Microsoft or Google can change how a site behaves, independently of a CommunityGlows update.
• More open networks means more memory. You stay in control of how many are open.

I would rather tell you where my guarantees stop than hide them behind the word “cross-platform”. If you want to see the workspace this all serves, start with how Bento turns a large screen into a multi-network cockpit.