It’s been over a year and a half in the making (and so much longer since the last substantial update to the app), and now it is finally here.
I’m so very happy to announce the release of ScreenFloat 2, available now!

Re-written completely from the ground up in Swift and based on Core Data, ScreenFloat 2 keeps true to its roots – floating screenshots, and the Shots Browser – and builds upon them in multiple, very useful ways.

If you’d like to skip all the details and just download the trial or get the app from the Mac App Store, please feel free to scroll all the way down.

What is ScreenFloat?

At its core, ScreenFloat creates floating screenshots.
Think of it as Picture-in-Picture for your screenshots and recordings: it keeps information always in sight, no matter what window, (fullscreen-) app or Space you’re in.
It’s useful in so many ways: you want to remember something, you want to transfer information from one app to another, you want to keep a visual reference to something on screen – anything you can screenshot, you can float with ScreenFloat.

In the Shots Browser, your shots are stored and organized.
It keeps your desktop clutter-free and your shots always at your disposal.

What’s New with ScreenFloat 2’s Floating Shots?

ScreenFloat 2 brings a lot of changes to floating shots, so here are the most important ones.

+ Screen Recordings
A floating screen recording

Not only can ScreenFloat 2 take screenshots, it can also record your screen, together with (optional) microphone- and system audio. Of course, these recordings can be floated and interacted with, like you would any other screenshot.
They can be trimmed, rotated, cropped and muted. Still-images can be easily extracted.

+ Text-, Face- and Barcode Detection
Copying text detected in a Shot, quick-redacting faces and text, and viewing a QR code’s contents is easily done.

Every shot you take is analyzed for text, faces and barcodes.
It’s so easy to view the contents of a QR Code (supported are urls, calendar events, vCards and more), or quickly redact information, with a simple right-click.

+ Annotation, Markup and Redaction (non-destructive)
Annotations, Markup and Redactions in action

You can add annotations and markup to shots: freedraw, rectangles, ovals, lines, arrows, stars, checkmarks, x-marks, text, smart enumerated lists, highlights and redactions.
All of this is non-destructive. That means you can always come back and make changes, or delete them all and revert to the original image.
Double-click a tool or an annotation to edit its properties, like line weight, font, or color.

+ Crop, Rotate, “Fold”, Resize, “De-Retinize”
By “folding” a shot, you can remove a middle section of it, and the remaining two parts get stitched together.

Crop shots, rotate them, “fold” them(see video above), and resize them effortlessly.
Reduce a shot’s resolution from its “retina” dpi of >= 144 to 72 dpi when you want to save some space, or know you won’t need the higher resolution going forward.

+ Quick Drag
Dragging from floating shots has become much more useful

Drag a floating shot’s document icon to any app to share the image as you see it via drag and drop.
Or click the document icon, and get access to quick export options so you’re able to drag out a different format, at a different quality, “de-retinized”, at a different size, and with or without annotations/markup.

+ Color Picker
Pick colors from floating screenshots and -recordings.

When you option(⌥)-click-drag on a floating shot, the color picker will appear. When you release the mouse button over a pixel, you’ll be able to copy that pixel’s color’s values, a color sample image, and even drag out the color onto a target in another app.

+ Double-click Action Workflows

Set up custom, keyboard-modifier-key-based double-click workflows, like:
– Reduce the floating shot’s opacity to 40% and make it ignore mouse clicks
– Edit the shot with annotations, and when I’m done, upload it to iCloud(see above)

What’s New in the Shots Browser?

Apart from adding the ability to rate and favorite shots, here are the most important new features in the Shots Browser.

+ iCloud Sync

Your shots, tags, annotations/markup and metadata are synced over iCloud across your devices.
You have the last say over what gets synced, though: all shots, only image or video shots, or only shots up to a certain file size.

+ Privacy

With Privacy enabled, your Trash and any folder that may contain hidden shots require authorization before you can access their contents.

+ Smarter Smart Folders, Search, System-Wide Spotlight Search

Smart Folders come with a lot of new criteria for you to find just the shots you’re looking for.
These are also available in the Shots Browser’s search.
Shots are (optionally) indexed with Spotlight, so you can find them system-wide.

(Spotlight) Search and Smart Folder criteria not only find attributes you give your shots (like filenames or tags), but also what’s in a shot, like texts, or barcode contents.

+ Tag Browser

With the Tag Browser, you rename, favorite, merge and delete tags, so you can keep things clean, neat and organized.

+ Exporting, Sharing

Export shots in the format, quality, size and resolution you need. With or without annotations and metadata.
Upload multiple or large shots to iCloud and share a link to that, instead of attaching a large file.

What else is New in ScreenFloat 2?

+ Siri Shortcuts

Automate taking screenshots, timed screenshots and recordings with Siri Shortcuts. Add a title, notes, tags, and move them into folders, all in one go.

+ Widgets

Access your shots, folders, picked colors and more with ScreenFloat’s widgets.

Availability and Pricing

Alright, let’s get down to the nitty-gritty.

– ScreenFloat 2 requires macOS 12 Monterey or newer.macOS 13 Ventura or newer required for recording your microphone/system audio alongside screen recordings.
– A (free) iCloud account is required if you wish to have ScreenFloat synchronize your library across your devices.

ScreenFloat 2 is a free upgrade for existing customers of the app. If you’d like to support my work beyond its one-time purchase price, there’s a completely voluntary and optional tipping mechanism (in-app-purchase) available in ScreenFloat 2’s settings.

There’s a free, 28-day trial for you to download here (direct download link)
You can purchase ScreenFloat exclusively on the Mac App Store at USD 6.99 / EUR 7,99 / GBP 6.99 for a limited time, then the price will go up to USD 14.99 / EUR 15,99 / GBP 14.99.
It is at this time localized into English, German and Chinese (Simplified).

Downloads and Links

Download the ScreenFloat 2 28-day free trial
Download the ScreenFloat 2 Press Kit

Visit the ScreenFloat 2 Website
Check out ScreenFloat 2’s Usage Tips
Get to Know ScreenFloat 2 – Blog Series

ScreenFloat 2 on the Mac App Store
Eternal Storms Software Productivity Bundle (save ~25% on ScreenFloat, Yoink and Transloader)

Eternal Storms Software YouTube Channel

Contact & Connect
Eternal Storms Software Privacy Policy

Support / Feedback / Questions

If you have any questions or feedback, please do not hesitate to write me.
If you’d like to review ScreenFloat 2 in a publication of some sort (blog, news site, podcast, etc), you’re more than welcome to write me and I’ll get you the information you need.
I do look forward to hearing from you.

I hope you’ll enjoy ScreenFloat 2. I couldn’t be happier it’s finally out!

Read more

I like to be prepared for worst-case-scenarios.
And when I found out my Mac app ScreenFloat didn’t work anymore on Apple’s upcoming macOS Sierra because of a new sandbox restriction (you can read the backstory here), I knew fixing it could have gone one of two ways:

  1. Apple fixes it for me in a new beta of macOS Sierra (which, as I now know, is what happened in the form of a new sandbox entitlement), or
  2. I’d have to write my own solution for creating screenshots, basically reimplementing macOS’ screencapture command line utility

At the time, I didn’t know Apple would provide a new sandbox entitlement, so for me, the only choice was to take a couple of days and reimplement macOS’ screencapture‘s functionality.
Now, when I say “reimplement”, I mean I looked at the features I needed in ScreenFloat and implemented them, leaving those I didn’t need aside (fullscreen screenshots, screenshot sounds or capturing windows’ shadows, to name a few).
Time was of the essence, after all, and I didn’t know how long it would take me to implement this stuff.

Deconstructing screencapture

Before I started working on my own solution, I thought it’d be good to understand how macOS’ screencapture utility was implemented.
I executed ‘strings /usr/sbin/screencapture’ in Terminal thinking I could find a clue as to how capturing the screen was done, but all I could find were references to private APIs, like CGSGetScreenRectForWindow or CGSGetWindowLevel:

CGSGetScreenRectForWindow failed: %d
CGSGetWindowLevel failed: %d

I could not find any references as to how capturing the screen is done, but I suspect the CGDisplay* APIs are used, and ‘nm /usr/sbin/screencapture’ seems to confirm that theory:

U _CGDisplayBounds
U _CGDisplayCreateImage
U _CGDisplayCreateImageForRect

Next, I wanted to know how screencapture draws its selection rectangle and cursor.
Knowing there’s basically no drawing on screen without an NSWindow, I created a small app that would filter out screencapture‘s windows during an interactive screenshot, create an image of each and write them to disk.
In doing so, I learned the following:

  • screencapture uses 5 windows to display its selection rect: 4 for the edges and 1 for the fill
  • These windows are present even if you’re not currently making a selection (albeit transparent), and they follow around your mouse cursor
  • The selection cursor isn’t drawn in its own window, it’s an ordinary NSCursor, using private APIs to set it
screencapture CLI's windows during selection

The windows surprised me.
Why would you need 5 windows to draw something you could draw in one, using Core Animation or an NSView?

screencapture has existed since Mac OS X Jaguar (10.2), and there was no Core Animation framework yet, so that’s out of the running.
That leaves NSView’s -drawRect:. Why not use that? Frankly, I don’t know. But I suspect it’s a performance thing – perhaps drawing 5 individual single-colored windows was faster on Mac OS X Jaguar (and still might be on today’s macOS) than one NSView’s -drawRect: and they just kept going with it over the years.
A friend and indie-colleague of mine, Andreas Monitzer (@anlumo1 on twitter) confirmed my suspicions: “Single-colored windows don’t need -drawRect:, and that’s probably just way more efficient.”

Also interesting is that screencapture adds specific Spotlight metadata tags to the screenshot files it creates:

  • kMDItemIsScreenCapture – a boolean value indicating whether the image file is a screenshot (YES). Only present when the file is a screenshot, so there’s no case where NO would be specified – the tag would be missing instead.
  • kMDItemScreenCaptureType – the type of screenshot: “display” for a fullscreen screenshot, “window” for a window-selected screenshot and “selection” for an interactive screenshot.
  • kMDItemScreenCaptureGlobalRect – Not really a rectangular value. As far as I can tell, it only contains the interactive screenshot’s origin point’s x value (where on the screen the screenshot was taken).

To set the cursor, I suspect there’s some private API magic at play.
An app can set its cursor in different ways: via cursor rectangles or directly via NSCursor. But it only works if the app is active and its window is frontmost – something that isn’t the case with screencapture.
‘nm’ reveals the private API CGSRegisterCursorWithImages, and several more:

U _CGSCreateRegisteredCursorImage
U _CGSGetCurrentCursorLocation
U _CGSHardwareCursorActive
U _CGSHideCursor
U _CGSRegisterCursorWithImages
U _CGSSetSystemDefinedCursor
U _CGSShowCursor
U _CoreCursorSet

So much goodness I’m not able to use in a Mac App Store app, just because it’s hidden away in a private API…

screencapture also does another thing I was interested in: When you press ⌘-⇧-4, followed by the space bar, you can move your mouse cursor over individual windows to screenshot them exclusively, and it’ll tint it to let you know about the selection.
I have no idea how it’s done – it’s either a window that gets painted over the selected window, inserted at the correct hierarchy level, or it’s a private API that lets you paint over any NSWindow.


Now I was ready to begin

Reimplementing screencapture

In reimplementing the features I needed, I had to hit several milestones:

Milestone #1: Actually capturing the screen somehow

Because I was using screencapture via NSTask to do all the heavy lifting for me, I had no idea where to start for creating user-selected screenshots.
I started with giving AVFoundation a try, as I remembered a couple of WWDC sessions mentioning capturing the screen – for video. Soon enough, though, issues popped up.
Like the image’s compression. A screenshot created with AVFoundation wasn’t anywhere near the quality a screencapture screenshot has – although it was to be expected, since it’s for videos, and videos are heavily compressed.
When text is involved, it’s especially painful:

Comparison of AVFoundation capturing and screencapture's outputLeft: AVFoundation’s output. Right: screencapture‘s

There are different quality settings you can try to play with to improve the shot a little, but it’ll never come close to anything screencapture produces. That’s just unacceptable.
After poking around screencapture, I learned Apple provides APIs for exactly this purpose: CGDisplayCreateImage, to capture an entire screen, and CGDisplayCreateImageForRect, for a manual selection, which is what I was interested in.

#Milestone 2: Drawing into a completely transparent NSWindow

For NSWindow to react to mouse events, it needs to have a colored background with an transparency value of at least 0.05. That sounds very low, but it’s still very noticeable when it’s suddenly put over your screen. You may not be able to pinpoint it, but you know something happened.

A white window with an alpha value of 0.05Left: The desktop. Right: The desktop below a white window with an alpha value of 0.05

That’s why I’m very grateful to Nick Moore, indie developer of PilotMoon fame.
He discovered that you can have a completely transparent NSWindow accept mouse events, by setting its contentView’s layer’s contents to a transparent NSImage.

#Milestone 2: Selection Drawing

With that out of the way, I could move on to actually drawing a selection.
For what the selection would look like, I didn’t have to think much. I wanted to keep it consistent with screencapture: white borders with a white-transparent fill.
But the APIs I’d use to draw the selection were up to me.
Since I didn’t want to use 5 windows like screencapture does, I briefly experimented with NSView’s -drawRect:, but discarded that in favor of something more modern and more performant: CAShapeLayer.
In my tests, it’s looks and feels just as the original, and even if it’s not, it’s indistinguishable to my eyes (on a retina MacBook Pro Mid-2012).

The selection’s functionality would have to be the same as screencapture‘s – drag to select, keep the space bar pressed to move the selection, release the space bar to continue the selection, press the space bar once to enter window-selection mode, press it again to exit again. Nothing that couldn’t be done with NSResponder’s ordinary methods.

Moving a selection with the space barMy reimplementation’s behavior when using the spacebar to move the selection.

Milestone #3: Custom Selection- and Window Capturing

Because of CGDisplayCreateImageForRect, creating a screenshot of a custom selection is fairly straightforward.
Window capturing is a little more work. You *could* do it with CGDisplayCreateImageForRect, but you’d have remnants beneath the window’s rounded corners of anything that was below it at the time of the capture.
It’s good to know Apple provides an API for those cases as well, then: CGWindowListCreateImage. It will let you define the window you’d like to capture and the “features” it should have (shadows, no shadows, include windows below it, don’t include them, etc).
You can get a reference to the window you’d like to capture using CGWindowListCopyWindowInfo – it’ll give you its rect on screen, its window level and more information about it.

Milestone #4: Window Selection Drawing

That last API, CGWindowListCopyWindowInfo, also comes in handy when drawing the window selection (for when you hit the spacebar).
After all, you need to know where all the windows are and their dimensions on the screen, so you can draw the selection accordingly.
Once I have that information, it’s easy to put up another CAShapeLayer above the selected window.
But wait. What if the selected window is beneath another window, or several windows?

Faulty Window SelectionA first try at implementing window selection, clearly failing for windows that are beneath other windows.

That’s where it gets tricky and why I assume Apple is using private APIs here, which lets it either insert a new, selection-color-colored, translucent window into the window hierarchy at the right position or draw directly onto the window.

My solution was to use another CAShapeLayer.
It’s based on CGPath (which I convert to from an NSBezierPath) to draw the colored overlay.
I use the results from CGWindowListCopyWindowInfo to find out which windows are atop the currently selected window, create an NSBezierPath from their bounds, subtract them from my initial NSBezierPath and feed that to the CAShapeLayer.
It works pretty well:

Working Window Selection

It didn’t work like this right away, though. There was a lot of trial and error, sweat and, yes, tears involved in this. But I think it was worth the effort. Doesn’t it look just like the original?

Milestone #5: Drawing the Cursor

The cursor in screencapture has a unique feature: it displays the coordinates next to it, or if a selection is being made, the dimensions (width and height) of that selection.
I wanted the very same thing, so custom drawing was necessary.

I started out using NSCursor, but for every mouse move I’d need to create a new NSImage with the coordinates (or dimensions) and set it as the cursor – that seemed pretty inefficient to me.
I then moved on to using part NSCursor, part CATextLayer. The NSCursor part would be the crosshair, a constant image, set-it-and-forget-it.
The text layer would be updated in -mouseMoved:, updating its position to be next to the cursor and its contents to reflect the cursor position or dimensions.
Sure enough, it worked, but when moving the mouse cursor around fast, the text layer would “lag behind”, not correctly sticking to the cursor. It’s nothing major, but it bothered me.
With this, we come to my final approach.
I hide the system cursor entirely and draw both the crosshair and the text using CALayers. Since they both are now updated inside the same -mouseMoved: (or -mouseDragged:) call, there’s no noticeable “lag” for the text layer – they now move together nicely, as if drawn in one NSCursor object.

Milestone #5: Focus without focus

The tricky thing about screencapture is that it has mouse and keyboard focus without it taking you out of the app you’re in (the window’s close, minimize and fullscreen buttons are not greyed out, for example).
Again, in my desire to be consistent with the Apple-provided command line utility, I needed the very same thing.

It’s difficult to get certain NSResponder method calls if your window is not key, and it prompted another trial and error session to get the right combination of -isKeyWindow, -acceptsFirstResponder, etc.
It now works, but it’s not as nice as Apple’s implementation.
Which brings us to the Caveats section.

Caveats of my implementation

Caveat #1: “Across-Screens Screenshots”

With screencapture, you can make a selection that spans several displays, due to the way it’s implemented (using NSWindows to draw the selection).
With my implementation, that’s not possible, as I put up one transparent window for each screen that’s connected to your Mac. But I settled – I think it’s very rare you’d make that sort of a selection.

Caveat #2: The Cursor

In some cases, the system cursor will pop up again, and it won’t go away until a new screenshot session is started.
This is the hideous result:

The system cursor drawn above the custom cursor

Caveat #3: Capturing Fullscreen Windows

When you click the green fullscreen button on a window, it transitions from being one window into being two windows without you knowing about it – one for the the titlebar/toolbar (which moves down a little when you move your mouse to the top edge of your screen to reveal the menu bar), and one for the actual window.
screencapture is somehow aware of this, and when you do a window selection, it will properly draw its selection rectangle above the entire window.
My implementation doesn’t know about fullscreen windows and treats those two windows separately:

My implementation's fullscreen window selection bugInstead of the entire window, just the titlebar and its shadow are selected.

I haven’t found a solution to this, yet.

Caveat #4: Exposé

When you start Exposé to show all open windows, screencapture can be used to screenshoot them individually.
My implementation falls short of that, as Exposé seems to be a semi-modal mode where other windows can not be moved over it.
Of course, screencapture can.

Pros of my implementation

Apart from these caveats, I also see a couple of upsides to having your own implementation:

Pro #1: Control over the UX

With a custom implementation, I can change anything I want at any time, be it any cursor icon or the behavior in general. I don’t have that luxury with Apple’s built-in tool.

Pro #1 and a half: Timed Shots

Speaking of UX:
Yes, Apple’s built-in tool features timed shots (a screenshot that is not created immediately, but after a small delay). But I think it’s clumsily implemented.
When you start a timed shot:

  • You don’t know how much time there’s left until the shot is taken
  • You can’t click anything beneath the selection rectangle

With a custom implementation, I can provide a better experience here.

Pro #2: Screenshot placement

Something that concerns ScreenFloat exclusively is the placement of the floating shot after taking it.
Using screencapture, I just centred the shot at the mouse cursor. It works, but it’s not very nice.
With a custom implementation, I know exactly where the screenshot was taken and can place it accordingly:

Screenshot Appearance

or I can do a little animation to make it more clear that a screenshot was created:

Screenshot Appearance Animation

Pro #3: Sandbox

With a custom implementation, I don’t need to worry about temporary entitlements – it works without any.

Open Source?

I’m planning on making the source available at some point, but before I do, there’s still a couple of things I need to do, like implement timed shots, which I haven’t gotten around to yet.
Also, so I don’t make a fool of myself, I need to clean up the code, and that’s dependent on the free time I get, which recently is little (I’m not complaining – I love being busy).

Anyway, this has been quite the journey, and if I can manage to fix some of the caveats I described above, I might use my own implementation instead of Apple’s built-in screencapture CLI in ScreenFloat at some point. But for now, I’m happy I’m again able to use Apple’s built-in tool.

Eternal Storms Software Logo– – – Do you enjoy my blog and/or my software? – – –
Stay up-to-date on all things Eternal Storms Software and join my low-frequency newsletter (one mail a month at most).
Thank you 🙂

Read more

ScreenFloat Mac App Icon

Today I finally was able to release ScreenFloat 1.5.13 on the Mac App Store. It’s a free update for existing customers of the app.
A 15-day trial can be downloaded for free from the website, even if you’ve tried it before.

What Is ScreenFloat?

ScreenFloat lets you create screenshots that float on top of everything, enabling you to keep an eye on information you currently need without having to switch back and forth between windows, applications or spaces.

Customers use it in all sorts of cases – when coding for code snippets, when making wire transfers for IBAN numbers and such, when working in Photoshop to compare images, the list goes on and on.

ScreenFloat in Action

Basically, any time you need to keep something in your field of view or need to remember something on screen, ScreenFloat is there for you. The floating shots follow you around, no matter what window, app or space you are in, or you can pin them to specific spaces.

Shots you close are not deleted, but kept for you in the Shots Browser, where you can organize and categorize them:

ScreenFloat's Shots Browser

What’s New in ScreenFloat v1.5.13?

• Most importantly, ScreenFloat now works on macOS Sierra.
As I wrote about earlier, macOS Sierra has a new sandbox entitlement that was prohibiting ScreenFloat from performing correctly, so that is fixed now.
While I was at it, I put the screenshot creation into its own XPC process, so I could isolate the new entitlement from the rest of the app, as Apple encourages doing.
• Aside from now working on macOS Sierra, it fixes two bugs and a (rare) crash, so I definitely recommend updating to version 1.5.13.

A Little Background on ScreenFloat’s App Store Review

When I first submitted this update of ScreenFloat to the Mac App Store, I included this line in is App Store description:
“Improves compatibility with macOS Sierra”
The update was rejected because of it. You are not allowed to mention Apple pre-release software in your App Store description. Instead, they suggest you use this line:
“Improves compatibility with an upcoming OS”
I think that’s rubbish. Everyone knows what the next OS is going to be called – it was publicly unveiled already under that name, so the likelihood of it changing now is virtually zero.
Secondly, they have a public beta out, for crying out loud. It’s in peoples’ hands already, but they don’t want developers to let their customers know that the app now works on Apple’s latest and greatest new system?
So I sent an appeal to the Review Board, it got rejected, I submitted the app again with the suggested line and it went through.
Still, I don’t think “an upcoming OS” is helping anyone. In fact, it’s more confusing than anything, if you ask me. “An upcoming OS” is ambiguous, whereas “macOS Sierra” lets the user know exactly what you mean.
Anyway, this will be my process from now on: Submit with my original line mentioning the OS update explicitly, getting rejected, appealing and then submitting with their suggested line. Perhaps they’ll get tired of it and let it through at some point. Probably not, though.

Pricing and Availability

ScreenFloat v1.5.13 is available for purchase on the Mac App Store for the price of $8.99 / £6.99 / €8,99. It is a free update for existing customers of the app.
A 15-day trial can be downloaded for free from the website, even if you’ve already tried the app.
ScreenFloat runs on Macs with OS X Lion 10.7.3 or newer.

If you’re interested in writing about ScreenFloat, you can download its press kit here, which contains screenshots, icons, a short sample video and further information.
A limited amount of promotional codes are available to members of the press at press(at)eternalstorms(dot)at.


ScreenFloat Website

ScreenFloat on the Mac App Store

ScreenFloat Demo Download

ScreenFloat Press Kit

ScreenFloat Video Preview on YouTube

I’m looking forward to hearing from you and to see what you think about ScreenFloat 1.5.13. If you like the app, please consider leaving a little review on the Mac App Store, it would help me out a lot! Should you have any feedback or questions, please be sure to get in touch, I’d love to hear from you! Thank you.


Eternal Storms Software Logo

– – – Do you enjoy my blog and/or my software? – – –
Stay up-to-date on all things Eternal Storms Software and join my low-frequency newsletter (one mail a month at most).
Thank you 🙂


Read more