Business

icon most likely not final

ScreenFloat 2 has officially entered “production”.
Apart from a bit of prototyping of various new features over the last couple of months and years, not a lot has happened in regards to ScreenFloat. But I feel now is the time to finally get it done.

ScreenFloat lets you keep visual references to anything you see on your screen floating above other windows using screenshots. It’s also a screenshot organizer.

Disclaimer: Estimated Time of Arrival, Pricing

I don’t do ETAs for my own products.
I’m a solo developer, I have multiple apps that need maintenance and updates, there are just too many moving parts for me to be able to estimate basically anything. And while that may be a serious lack of managerial skill: I accept that flaw and ignore it 🤷‍♂️.

Regarding pricing, I don’t know what ScreenFloat 2 will cost yet. But I am resolved on its upgrade path: existing customers of ScreenFloat 1 will receive ScreenFloat 2 for free.

About this Journal

I thought it would be fun to chronicle my progress, struggles, successes, failures, struggles, failures, break-throughs, failures, and random stuff while developing ScreenFloat 2. That’s all.

Fundamental Decisions

Before I can start coding, there are a few decisions I have to make in order to be clear on where I want to go and what I want to achieve.

Decision 1 – Build on ScreenFloat 1’s code base, or start from scratch?

I began work on ScreenFloat 1 on March 11th, 2010.
Memory is still managed manually (for you youngster coders out there: google retain / release to know what I’m talking about).
Objective-C’s @property wasn’t even available yet back then.
It’s ancient!
In addition, it was one of my first apps, so ScreenFloat 1’s code is all over the place. And while I don’t think code has to be “pretty”, I do think it has to be readable and understandable; ScreenFloat 1 is neither.
So yes, I’ll definitely be starting ScreenFloat 2 from scratch.
Which my next decision factored into…

Decision 2 – Objective-C, or Swift?

Swift, of course. I love Objective-C (it’s got me this far), but I think by now it’s clear that the future is written in Swift. That’s not to say that if there wasn’t Swift, I wouldn’t love to continue working in Objective-C. However, with more and more frameworks being Swift only (for example, Widgets), I need to move on as well.
While this decision is of no consequence to users of the final product – a feature in an app should work no matter what language was used to program it -, it is quite consequential to me.
I began learning Swift earlier this year – my freeware developer tool BackLog is a first result of that – and I’ll continue to learn. For me, the easiest way to do that is “on the job”: to actually work on something I’m going to ship. Two birds with one stone.
Will that increase development time? Possibly.
Is it worth it? I believe so.

Decision 3 – Keep old storage model, or migrate to Core Data?

ScreenFloat 1’s “storage model” was two plist files (one for the shots library and associated metadata, and one for categories the user created in the Shots Browser) and a folder full of image files.
It worked ok, but I’d like something more sophisticated, robust and scalable.
That sounds like Core Data to me.
It’s not a new framework to me (thankfully – it is a lot to learn). I’ve been using it for a couple of internal tools, and for apps I’m maintaining for third parties.

As a side note, I do want to keep the “folder full of image files”. It makes them accessible in Finder, instead of being stored somewhere on disk in an opaque Core Data storage file.

Decision 4 – Core Data with CloudKit, or Core Data with custom iCloud/CloudKit sync?

I recently took to twitter to see what other developers thought about Core Data with built-in iCloud sync. The consensus was pretty much to stay away: it can be slow, very opaque as to what it’s doing, and thus difficult to debug.

Synchronisation is difficult to debug as it is, so I don’t want to make it any harder than it has to be.
Over the years, I’ve gained quite a bit of experience when it comes to syncing with iCloud / CloudKit (I manually sync with iCloud using CloudKit in Yoink for iPad and iPhone and Transloader), so I’m confident I’ll be able to write my own custom CloudKit sync solution for ScreenFloat 2.

Decision 5 – macOS, sure, but what about iOS/iPadOS?

ScreenFloat 2 will be available for Mac, as well as iOS/iPadOS.
So some code (most notably storage and sync) has to be able to run on all those platforms – something to consider going forward.

As with all my other apps, ScreenFloat 2 for Mac and ScreenFloat 2 for iOS will be developed for and tailored to each respective platform mostly separately, and so they will also be sold separately.

That’s it for this time.
Thank you for joining me. Feedback, input and questions are welcome: mail me, tweet me.
Take care! 🤗

Read more

Yoink for Mac, the drag-and-drop improving utility, is now available in version 3.6.8.

What’s New?

There’s now a preference for having Yoink dynamically provide JPEG and/or PNG data for TIFF, HEIF and/or WebP image files you drag out of it.

I’ve also fixed a couple of bug fixes and made some quality-of-life improvements, like having a dedicated “Pinned Copies” sub-menu in Yoink’s contextual menu’s Clipboard History.

Where to get Yoink

Website (+ free, 30-day demo)
Mac App Store
Setapp

As always, it’s a free update for existing customers of the app.

It requires macOS Sierra 10.12 or newer and runs natively on Apple Silicon and Intel Macs.
Yoink is available in English, German, French, Italian, Simplified Chinese, Japanese, Korean and Portuguese.

Enjoy 🤗

Read more

With Yoink for Mac‘s clipboard history working again on macOS Big Sur and newer, I’ve seen, in forums and such, some questions about how the clipboard history operates and what it stores, in regards to privacy. I’ve answered those questions, but figured I’d let everyone know about it as well here on my blog, since this *should* be publicly available info:

General Notes about Yoink’s Clipboard History

  1. By default, the clipboard history feature is disabled.
    It has to be manually enabled by either clicking onto the widget in Notification Center, or in Yoink’s preferences, under Extensions.
  2. The clipboard history feature can be disabled at any time (and will clear any stored items at that point) in Yoink’s preferences, under Extensions.
  3. Individual items can be deleted in the Clipboard History browser, accessible by command-clicking onto an item in the widget, by selecting Clipboard History > Organize… in Yoink’s contextual menu, or by clicking Organize… in Yoink’s preferences under Extensions.

What the Clipboard History stores

By default, Yoink stores anything you copy or cut, be it some text from a document, an image on a website, or a file in Finder, for example. Please read “What the Clipboard History does not store” below for important exceptions to this.

The clipboard history can be configured by you to completely ignore copy/cut operations in certain apps. This can be done in Yoink’s preferences, under Extensions, by pressing “Ignored Applications: Edit…”

The clipboard history is stored locally on your Mac and does not leave your Mac, unless you do it manually.

What the Clipboard History does *not* store

Yoink completely ignores cut/copy operations from any app or process that has one of the following in its name:
Keychain, Enpass, 1Password, KeePass, LastPass, Password, Kaspersky, mSecure, AppLocker, Keeper Password, Passwort, oneSafe, Secrets, Strongbox, RememBear, Dashlane and Bitwarden.
Anything copied from an app whose name contains one of the above (case insensitive) does not get stored in Yoink’s clipboard history.

In addition to that, Yoink also ignores copied content from any app, if the resulting clipboard content contains any of the following data types (as suggested by developers, for developers, on nspasteboard.org):
com.agilebits.onepassword, org.nspasteboard.TransientType, org.nspasteboard.ConcealedType and org.nspasteboard.AutoGeneratedType.
If you copy something from an app, and that app writes, say, a string to the pasteboard, and also specifies one of the data types above, the clipboard history will not pick it up.

If you have any suggestions, possible additions, questions or feedback regarding this, please do mail me.

I’ve also updated my privacy policy to clarify all of this.

Long story short: I’m not interested in anybody’s data. I don’t do any tracking, no usage statistics, and, if my apps use your internet connection, it’s exclusively for a specific feature that it offers to you, the user.

Take care : )
– Matthias

Read more