State of my Apps, hot summer 2023 edition

When it comes to the summer period that is coming to an end, the work I was able to put into my apps was much less than I would have hoped for after WWDC wrapped up. The experience Riccardo Mori eloquently described in the first part of a recent blog post reflects mine as was as painful to read as it was to live: it’s been so excruciatingly hot in Northern Italy that I have been able to tackle much less than I usually do during the summer, instead devoting most on my energy to long, fun and very instagrammable walks with Milla early in the morning, before the sun took away my drive to do stuff.

On a professional level, the limited progress I feel I made is kind of a bummer, with the feeling of having misused many potential hours of work. Taking stock of the progress of all my projects is something that therefore makes sense for me to do right now, to hopefully have a more productive sprint before Christmas, which if we’re honest is just around the corner. If you’re interested in any of my apps, or curious about the indie experience’s ups and downs (consider this a down), this post might be of some interest to you as well.

Version 4.1 of my IP camera viewer GlanceCam is coming along and will be ready for Sonoma on day one; what matters the most to me is that the most used app I work on is already 100% compatible and reliable on the upcoming version of macOS (I’ve been running the betas on my main machine all summer to be sure there were no hiccups), but the feature-set of the next update will not be vast: a few bug fixes, additional AppleScript commands, customisable double-click behavior for GlanceGrids (send the whole grid full-screen, or just the selected camera, or again spin up a separate window for the selection) and 90/180/270° rotation support.
My hope for August was to also make progress on ONVIF support, but I haven’t been able to touch this extensive and challenging protocol.
I also had a wild dream to devote the hot months to GlanceCam for visionOS and did submit a request for a developer kit, but I haven’t heard back and that’s a sign I’m willing to accept that my focus should be devoted to more commercially viable projects in the near future.

Link HUB, my URL dashboard with widgets app, is also in a reasonably good place: I’ve been testing the app, widgets, and lock-screen widgets on iOS 17, iPadOS 17 and Sonoma and everything looks good, without the need of a compatibility update: there are scenarios, like with the Desktop widgets on macOS, where the default contrast might not be perfect depending on the wallpaper, but all widgets already offer a High contrast option that is sufficient to address those scenarios.
I’ve also thought about interactive widgets – clearly, the new shiny things this autumn – but honestly Link HUB is first and foremost a launcher, so I don’t really see a use case for them. Yet.

Thorough iOS 17 and iPadOS 17 testing also confirmed that both PhotosUpload, my niche app for uploading photos to FTP servers, and my iPhone pedometer Walk More are working fine without needing specific updates for the new OSes.

MousHero, the Safari extension to trigger URLs from the browser that I shipped just a few months ago works well on Sonoma and isn’t demanding much attention right now (or ever again? It’s basically done, which is not something I’m used to with my other projects), but I still have a challenging bug to investigate as soon as I will find the time: sometimes the contextual menu item is not displayed until the MousHero icon in the Safari menu bar is activated once, which is something I’ve never seen Safari extensions require and that doesn’t really make sense to me, happening in such random fashion.

Before discussing what’s next for my other apps, I would like to address another major hindrance to my productivity (and spirit), and something I’ve meant to write about in the hope of providing some help to fellow developers googling for a similar obscure issue: in early August I started experiencing a code-signing issue when trying to submit a minor update to one of my Mac apps (TameTime), which quickly turned into a major roadblock to shipping updates for 3 of my desktop projects, including GlanceCam!
What happened: when submitting any update from Xcode (14.3.0…15b8), the binaries successfully uploaded, but a few minutes later I systematically received an ITMS-90238: Invalid Signature + ITMS-90296: App sandbox not enabled rejection email that explicitly referred to the embedded helper app I’ve been using for years to provide a Launch at login functionality, and that obviously has always been sandboxed and signed.
I am sure this rejection is caused by server-side changes on Apple’s analysis of the binaries after submission because reverting to previously approved versions of those apps and submitting them with older versions of Xcode (i.e. 14.3.0) is still to this day causing the same delayed rejection.
This issue has been pretty scary (again, I wasn’t able to submit any updates to my apps) and demotivating, but it was also too hot to fight against a black box, so I kept circling around it hoping for a breakthrough, mostly focusing on a blog post from John Brayton that referred to a strikingly similar situation (same ITMS error codes emailed after successful uploads), even though in the end it proved to be a different problem from his.
Luckily, in the last couple of days (thanks to lower temperatures and renewed energy) I have been able to work around that rejected binaries issue: I still don’t know what changed in Apple’s SPI review process, but I figured that taking out my embedded helper app from the binaries and replacing my (established and so far perfectly fine) manual approach with a well respected and widely used library from Sindre Sorhus could help, and as a matter of fact it does; clearly the LaunchAtLogin library handles the procedure better, in a more compliant way than my previously fine – but likely borderline – approach.

This lateral success finally unlocked a couple of small updates to my other Mac apps that I had put together during my August holiday and that have been successfully approved by Apple today:

• ClipBar 1.6 allows Users to manually reset the menu bar’s pasteboard preview (the utility’s purpose is to display what you last copied in the upper right corner of your screen, with some additional bells and whistles) by right-clicking on the app in the menu bar and selecting Clear ClipBar; this does not erase the content of your Mac’s pasteboard but removes the preview from the menu bar, which in some cases can be useful for privacy reasons. Special thanks to connectionfailure’s App Store review for suggesting the feature!

• TameTime 1.5 also includes two new features, both recommended by Kenneth, whom I thank for helping me improve my utility to fight RSI and remember to move around: it’s now possible to manually reset the timer by clicking on TameTime in the menu bar and selecting Reset timer; most importantly, Users can now set custom and independent flash-screen messages for the Minor and Major alerts, or omit them completely and only have the 3-seconds dark screen as visual clue to take a break.

It’s a secret I cannot mention in their release notes, but both these apps also work great on Sonoma.
Sadly, though, there’s also a catch to the updates above (and most likely it will be an annoying reality that will also apply to GlanceCam 4.1): due to the fact that I needed to replace the Launch at login mechanism, Users who previously set those apps to open automatically when their Mac started will need to manually re-enable that behavior. I don’t love this, and I mention it in their release notes in the hope of causing limited disruption, but at least I was able to move past that super-worrying submission block and now these apps are “in the right section” of macOS Settings, which is more professional and therefore a welcome bonus at the end of this ordeal.

Finally, there should be another project on this list: early this summer I started working on Quee, an app that has been on my mind for years and a possible playground for improving my SwiftUI experience and especially testing out SwiftData; the idea behind Quee remains interesting to me, especially with the upcoming Journaling APIs, but I must admit development quickly stalled (the fact that SwiftData surprisingly doesn’t support inheritance didn’t help) and I have so much going on already that’s impossible to also devote time to a new project in the immediate future. Maybe if it had not been so hot…