Books bought from the Kindle store are protected with DRM (digital rights management). The file is locked to Amazon’s apps and devices, and other apps can’t read the text inside. Books bought in Apple Books work the same way: they open in Apple Books and nowhere else.
That is why a speed reading app, including ours, can’t import them. It isn’t a missing feature; the text simply isn’t available to any other app.
You will find tools online that strip DRM from ebooks. Removing it usually breaks the store’s terms, and in many countries it is against the law, so we don’t recommend it and our app doesn’t support it.
Plenty of what people read is DRM-free:
Flincth Speed Reader, coming soon to iPhone and iPad, opens DRM-free EPUB, PDF (with a text layer), DOCX, TXT, RTF and Markdown files, web articles and pasted text. It shows them one word, phrase or short sentence at a time at the pace you set, keeps your place, and lets you pause to see the surrounding text.
A scanned PDF, which is a picture of a page rather than text, can’t be read; the app tells you so rather than showing an empty screen.
Read it in Amazon’s own apps, which can show your reading speed and how much is left. Amazon has offered a one-word-at-a-time mode on some devices in the past; check your Kindle app’s reading settings to see whether yours has it. For everything else, a DRM-free copy and a speed reading app work together without any workarounds.
If you are wondering whether speed reading works at all, we wrote up what the research says.
]]>The short version: they make you faster, and the faster you go, the more you lose. How much you lose depends on what you read and how the app shows it.
Most speed reading apps use RSVP, rapid serial visual presentation. Instead of a page, you see one word (or a few) at a time in a fixed spot, replaced at a pace you set in words per minute.
The idea is to remove the work your eyes normally do. When you read a page, your eyes jump from point to point, rest briefly, and sometimes jump back. RSVP keeps them still and moves the text instead.
Reading scientists have studied this for decades, and their findings point the same way.
Speed and understanding trade off. A major review of speed reading research by Keith Rayner, Elizabeth Schotter and colleagues (Psychological Science in the Public Interest, 2016) found no shortcut around this: as people read faster, they understand less. There is no technique that lets you take in a dense text at several times your normal speed without giving something up.
Looking back matters. In ordinary reading, a share of eye movements go backwards to re-read a word or phrase. A study by Schotter, Tran and Rayner (Psychological Science, 2014) found that when readers couldn’t look back, their comprehension of tricky sentences dropped. RSVP removes exactly this: once a word has gone, it’s gone.
Apps specifically. Acklin and Papesh (American Journal of Psychology, 2017) compared reading on the page with RSVP-style apps and found comprehension was better on the page than with either RSVP condition. Within RSVP, slower speeds helped people recall exact details.
None of this says RSVP is useless. It says the trade-off is real, and claims of reading at 1,000 words per minute with full understanding don’t hold up.
Used with that trade-off in mind, they are useful for:
They are a poor fit for textbooks, contracts, technical documents and anything you need to remember precisely.
The research shaped Flincth Speed Reader more than any feature list:
That doesn’t beat the research; nothing does. It aims for a pace where you are faster than usual and still understand.
Speed reading apps work for reading faster. They don’t work for reading faster and understanding everything. Start at a comfortable pace, a little above your normal speed, use them for the right kind of text, and slow down when it matters.
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?
]]>