Then I noticed what I was doing right after every switch.
I was digging through my clipboard.
Like most people who copy a lot, I had used clipboard managers for years. They all work the same way: one long list of everything you have copied, newest first.
That list is great for about ten minutes.
After that it becomes a timeline of your whole day. An API key you copied while debugging. A paragraph from a draft. A client’s order number. A URL from a meeting. A commit hash. Another paragraph.
When I came back to coding after an hour of writing, the snippet I needed was buried under everything I’d copied for the writing.
And sometimes it was worse than buried. Once or twice I pasted something from one client’s work into another client’s document. I caught it. Not everyone does.
Flincth already had a word for “the kind of work I’m doing right now”: a setup.
A setup chooses which apps belong to that work and where their windows go. But the arrangement on screen was only the visible part. What a setup really describes is a context.
The things you copy belong to a context in exactly the same way.
The snippets, IDs and links you paste while coding aren’t the ones you need while writing. So the clipboard history should switch when the setup switches.
That’s what Flincth does. Each setup keeps its own text clipboard history:
Switching doesn’t move, merge or clear anything. Each list simply stays where it was, waiting for you to come back.
I went back and forth on one decision more than any other.
Should an item copied in one setup also appear in a global list?
I decided no. Every item belongs to exactly one list. If something copied while “Client A” was active also showed up everywhere else, the separation would be decoration.
But a clipboard manager that can’t produce something you definitely copied is worse than no clipboard manager at all.
So the split decides what you see first, never what you can reach. The panel opens on the active setup’s list, and an All view sits right next to it. In All, every item shows which setup it came from. Search works across everything.
The quiet default keeps the noise out. The way out is one click away.
A clipboard manager sees everything you copy. That makes what it doesn’t record just as important as what it does.
Passwords. Password managers, including Keychain and 1Password, mark what they put on the clipboard as concealed. Flincth never records, shows or saves those items. A clipboard manager that ignored that mark would quietly become a plain-text password log.
Throwaway copies. Some apps mark their clipboard writes as transient or auto-generated. Flincth skips those too.
Anything, if you turn it off. Clipboard history can be switched off entirely. Switching it off deletes what was recorded rather than just hiding it.
Flincth records text: plain text, rich text as plain text, links and file paths.
It doesn’t record images. They are the second most copied thing, so this was a real trade-off. But images would make the history file thousands of times larger and much more worth stealing, for a feature that should first prove itself with text.
Copying the same text twice in a row doesn’t create a duplicate. The existing item simply moves back to the top.
History is saved, because a clipboard manager that forgets everything when you log out solves half the problem.
It lives in its own file inside the app’s sandbox, readable only by your user account and kept apart from your setups. Nothing in it is sent anywhere.
You decide how much of it there is:
And when you delete a setup, its clipboard history goes with it. The confirmation tells you how many items that is. A list that belongs to nothing and can’t be reached from anywhere is just a leak waiting to happen.
Every part of this works inside the Mac App Store sandbox.
Reading the clipboard needs no permission. Neither does the global shortcut that opens the panel. Flincth checks the clipboard for changes a couple of times a second, which is how clipboard managers on the Mac work, because macOS doesn’t announce when the clipboard changes.
Press your clipboard shortcut, type a few letters, pick an item, and it’s back on your clipboard, ready to paste.
It would be easy to read Flincth as a window manager with a clipboard manager bolted on. I understand why. On their own, each is a well-known kind of app.
But a plain clipboard history is a commodity. One that knows which work you’re doing follows naturally from the setups that were already there.
When I switch to Code now, my editor, terminal and docs move into place, and the last thing I copied for that code is the first thing I see.
That’s the whole point. Not one more list, but the right one.
Flincth is on the Mac App Store as a one-time purchase, with no account and no subscription.
Website: flincth.com
Mac App Store: Flincth – Workspace Manager
If you use a clipboard manager today, I’d like to know how you keep it from filling up with everything at once. And if you try Flincth, tell me which setup’s list fills up fastest.
]]>This post is about how it works underneath, because the most interesting part of building it wasn’t the idea.
It was a constraint.
If you have ever installed a window manager on a Mac, you have probably seen the prompt.
“This app would like to control this computer using accessibility features.”
Then you open System Settings, find Privacy & Security, scroll to Accessibility, and flip a switch.
There’s a good reason for that. The Accessibility API is how one app reaches into another app’s windows and moves them. It is the standard tool for the job.
It is also one of the most powerful permissions you can give an app. Accessibility access isn’t limited to windows. It lets an app read what is on screen in other apps and act on your behalf inside them.
I wanted Flincth on the Mac App Store. And that is where the standard tool stopped being available.
Apps on the Mac App Store must run in the App Sandbox.
A sandboxed app cannot use the Accessibility API to control other applications. It doesn’t matter how politely you ask the user. The sandbox simply doesn’t allow it.
A few long-standing window managers on the App Store predate that rule. A new app doesn’t get that treatment.
So I had a choice.
I could ship outside the App Store, ask for Accessibility access, and build the same thing everyone else builds.
Or I could find out whether a window manager could be built without it.
I chose the second, mostly out of curiosity. It turned out to shape the whole product.
Apple’s Shortcuts app has a small, easy-to-miss group of actions under Scripting → Windows:
Shortcuts runs those actions with its own permissions. A sandboxed app is allowed to ask Shortcuts to run a shortcut.
That was the opening.
Flincth doesn’t move any window itself. It works out exactly where every window should go, then hands that plan to a shortcut called Flincth Apply, which does the moving.
You install that shortcut once. The app walks you through it the first time you need it, and you can open it in Shortcuts and read every action it contains. Nothing about it is hidden.
The Shortcuts actions are simple. They move one window to one position and give it one size.
Everything else has to happen before Shortcuts is involved.
When you switch to a setup, Flincth:
Then it sends that whole list to the shortcut in a single run, instead of calling Shortcuts once per window.
One detail I tested before trusting it: the coordinates Shortcuts expects are global. A window given an X position past the width of your main display lands on the second display. If it had been the other way round, every placement would have had to carry its display along with it.
To place windows, and to put your desk back afterwards, Flincth also needs to know where windows are right now.
macOS has a function for that, CGWindowListCopyWindowInfo. It isn’t an Accessibility API and it works inside the sandbox.
Without Screen Recording permission it won’t tell you window titles. It still gives the position, size, owner and window number of every window. That turned out to be enough.
So Flincth identifies windows by app and position, not by title. I could have asked for Screen Recording to get the titles. I decided another privacy prompt was a worse trade than slightly harder window matching.
The result is a window manager that asks for no Accessibility access and no Screen Recording access.
A setup isn’t only about the apps you need. It is also about the ones you don’t.
Minimising another app’s windows would need Accessibility again. Hiding an app doesn’t. NSRunningApplication.hide() works inside the sandbox with no special permission.
So when you switch, apps outside the setup can hide. One call per app, and it is the same thing as pressing ⌘H.
It turned out to be the better behaviour anyway. Hidden apps come back exactly as they were, which made one of my favourite features easy to build: Not Flincth, a single click that returns your desk to how it looked before you started switching.
Building this way has real costs, and I’d rather be upfront about them.
It isn’t instant. Every move goes through Shortcuts, which is slower than an app moving windows directly. Switching a setup takes a moment to settle rather than happening in a single frame.
It needs a shortcut you install. That is one more step on day one. If the shortcut goes missing, Flincth notices on the next switch and offers to install it again.
It can’t cross desktops. No public API moves another app’s window to a different Mission Control desktop, and Shortcuts has no action for it either. Flincth places windows on the desktop you’re on, and gives each desktop its own arrangement.
It can’t enter or leave full screen. Same reason.
It depends on Apple. If Apple changes the Shortcuts window actions, Flincth has to adapt. There’s no back door to fall back on, by design.
When I started, the constraint felt like a handicap. Now it feels like the point.
Fewer permissions. Flincth never asks to control your computer. It moves windows through a shortcut you can read, and reads window positions without reading your screen.
A sandbox around everything else. Your setups and your per-setup clipboard history live inside the app’s sandbox on your Mac.
Apple review. Every version goes through the App Store, and so does every update.
A simpler product. Flincth doesn’t watch your windows all day. It arranges them when you switch and then gets out of the way.
Most of us reach for the most powerful API available, because it is the easiest way to make something work.
Taking that option away forced me to ask what the product actually needed. It needed to place windows when you switch setups. It didn’t need to control your Mac the rest of the time.
The narrower tool turned out to be enough.
Flincth is on the Mac App Store as a one-time purchase, with no account and no subscription.
Website: flincth.com
Mac App Store: Flincth – Workspace Manager
If you build Mac apps, I’d love to hear whether you’ve run into the same wall, and how you got around it. And if you try Flincth, tell me which setup you created first.
]]>It’s a setup I really enjoy. More screen space means I can keep my editor open, have a browser available for research, leave a terminal visible, and still have room for everything else I need throughout the day.
At least, that’s the theory.
In reality, I noticed that I was spending a surprising amount of time managing the setup itself.
Every time I changed what I was working on, my desktop needed to change with me.
When I was coding, I wanted one arrangement.
When I was researching something, I wanted another.
For meetings, writing, planning, or everyday tasks, I wanted something completely different.
And every time I switched context, I found myself doing the same thing:
Opening apps.
Moving windows.
Resizing them.
Dragging them between monitors.
Trying to remember where everything was supposed to go.
Then doing it all over again a few hours later.
Eventually I started wondering:
Why am I rebuilding the same desktop environments every day?
That question eventually became Flincth.
There are already plenty of great window management tools for macOS.
They can snap a window to the left side of the screen, move it to another display, maximize it, split the screen into sections, and perform all kinds of useful window operations.
But I realized that my problem was slightly different.
I didn’t really want to manage a window.
I wanted to manage what I was doing.
Consider a typical coding setup.
I might want:
When I stop coding and start researching something, the ideal arrangement changes.
Now I might want:
The individual windows aren’t the important part.
The relationship between the apps, their positions, the displays, and the task I’m doing is what matters.
That led me to a different way of thinking about desktop organization.
Instead of asking:
Where should this window go?
I wanted to ask:
What should my Mac look like when I’m doing this kind of work?
That became the core idea behind Flincth.
Flincth is built around workspaces.
A workspace represents an environment you use for a particular activity.
For example:
Coding
IDE + Terminal + browser arranged across your displays.
Research
Browser + Notes + reference applications.
Daily
Mail + Calendar + browser.
Writing
Your writing application with research material positioned alongside it.
You configure the environment once.
Then, instead of rebuilding it manually the next time you need it, you switch to that workspace.
Flincth takes care of arranging the applications and windows according to the layout you created.
The goal is simple:
Your desktop should adapt to what you’re doing – not the other way around.
The idea became particularly useful for me because I work with multiple displays.
A single-monitor desktop can become messy.
A multi-monitor desktop can become very messy.
Once applications start moving between displays, restoring a setup manually becomes increasingly annoying.
Maybe your IDE belongs on your main monitor.
Your browser belongs on another.
Terminal needs to sit next to the IDE.
Another application needs a smaller section of the secondary display.
You can absolutely arrange all of this manually.
The problem is that you have to keep doing it.
And that’s the part I wanted Flincth to eliminate.
A workspace isn’t tied to a single window or necessarily a single display.
It’s intended to represent the environment across your setup.
That means switching what you’re doing can also mean switching how your entire multi-monitor setup is organized.
Moving a few windows doesn’t sound like a serious productivity problem.
And individually, it isn’t.
Dragging a window takes seconds.
Opening an application takes seconds.
Resizing something takes seconds.
But the interesting part is how frequently those tiny interruptions happen.
You’re working on something.
You need to switch tasks.
Now you start preparing your computer for the new task.
Move this.
Open that.
Find another window.
Move it to the other monitor.
Resize it.
Close something else.
And only then do you actually start working.
The cost isn’t just the seconds spent dragging windows.
It’s the interruption.
I wanted switching environments to feel closer to changing modes than reorganizing a desk.
One shortcut.
New workspace.
Continue working.
While building Flincth, another problem became obvious.
The clipboard is also usually treated as one giant global stream.
You copy some code.
Then a URL.
Then something from Slack.
Then a paragraph from an article.
Then another piece of code.
A traditional clipboard history remembers all of it chronologically.
That’s useful, but it ignores context.
If I’m working inside a coding workspace, the clipboard items I’m interested in are often related to that work.
If I switch to research, the useful clipboard context changes too.
So I added workspace-specific clipboard history.
Each workspace can maintain its own text clipboard history.
That means the workspace doesn’t just organize what’s visible on your screens.
It can also help organize some of the temporary information associated with that activity.
This turned out to fit naturally with the original idea behind Flincth:
Different kinds of work have different contexts.
Another decision I made early was that Flincth should feel at home on macOS.
I didn’t want the product to feel like a web application placed inside a desktop window.
It’s designed as a native Mac utility and lives close to the way you already interact with macOS.
Workspaces can be accessed from the menu bar, and keyboard shortcuts make it possible to switch setups without interrupting your workflow.
I wanted Flincth to stay out of the way until you need it.
Configure your workspaces.
Use your Mac.
Switch when necessary.
That’s it.
There was also a question I kept asking while building features:
Does this actually need a server?
For most of what Flincth does, the answer was no.
Your workspace configuration belongs on your Mac.
Your clipboard history definitely doesn’t need to travel through somebody else’s server just to provide its basic functionality.
So Flincth doesn’t require an account or cloud service for these features.
Workspace and clipboard data stay locally on the Mac.
Apart from being a privacy decision, I like the simplicity of this approach.
Install the application.
Configure it.
Use it.
No account creation before you can organize your own desktop.
Subscriptions make sense for many products.
Services with ongoing infrastructure costs, constantly changing content, cloud processing, collaboration platforms, and other continuously delivered services can have very legitimate reasons for recurring pricing.
But I didn’t feel that model made sense for Flincth.
It’s a Mac utility.
You buy it.
You use it.
So I decided to launch Flincth as a one-time purchase rather than a subscription.
I wanted the business model to be as straightforward as the product itself.
One of the more interesting things I’ve learned from launching Flincth is that building a product and getting people to discover a product are completely different disciplines.
As a developer, it’s tempting to think mostly about the first part.
You identify a problem.
You design something.
You write the code.
You fix bugs.
You polish the interface.
Eventually you reach the magical moment where the application works.
Then you ship it.
And suddenly you discover another problem:
Nobody knows it exists.
Flincth is now live on the Mac App Store, which means I’ve moved from the development phase into a completely different experiment: distribution.
I’m starting small.
I’m learning about App Store search optimization.
I’m talking to Mac users.
I’m sharing the story behind the product.
I’m experimenting with communities where people care about Mac productivity.
And most importantly, I’m trying to understand how real users actually use workspaces.
Because there is a big difference between designing something for your own workflow and watching other people incorporate it into theirs.
Right now, I’m much more interested in the first 100 users than the first 100,000.
Those first users can answer questions analytics never will.
Do people understand the workspace concept immediately?
What workspaces do they create?
Do they primarily use Flincth with multiple monitors or a single display?
How often do they switch?
Which applications cause problems?
Does workspace-specific clipboard history actually change how they work?
What’s missing?
Those answers will shape where Flincth goes next.
That’s one of the things I find exciting about building an independent product.
The application that’s available today doesn’t have to represent the final idea.
It’s the starting point.
The biggest lesson so far isn’t technical.
It’s that small frustrations are interesting.
We naturally learn to tolerate repetitive actions on our computers.
Move this window.
Resize that one.
Open these three applications.
Arrange them again tomorrow.
None of those actions is painful enough individually to make us stop.
But when something happens dozens or hundreds of times, it’s worth asking a simple question:
Why am I still doing this manually?
Flincth started with that question.
I don’t think window management itself is the interesting problem anymore.
The more interesting question is how our computers can understand the different contexts in which we use them.
Coding isn’t just a collection of windows.
Research isn’t just another collection of windows.
They’re environments.
And I think our desktops should be able to switch between those environments as easily as we switch between tasks.
That’s what I’m trying to build with Flincth.
If you work with multiple monitors, frequently switch between different kinds of work, or simply find yourself rebuilding the same desktop layouts every day, I’d love to hear how you currently handle it.
Website: flincth.com
You can find Flincth – Workspace Manager on the Mac App Store:
And if you try it, I’m especially interested in one question:
What workspace would you create first?
]]>