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! š¤
For Yoink ā your file shelf that simplifies and improves drag and drop on your Mac ā, all I had to do to make it fit nicely within Big Sur was to resolve some UI issues.
