Hammerspoon: macOS 11 Big Sur support

[cmsj]

So the good news is that Hammerspoon appears to work pretty much without any modification, on Big Sur (x86), at least for the APIs that I typically use.

Building it in the new Xcode seems to also mostly be ok, although bumping the target deployment from 10.12 to 10.13 introduces some new deprecations we'll need to take care of. Some of our Cocoapods are complaining about having deployment target versions that are too old, but they still seem to build ok.

Which brings me to the same question that I like to ask every year... do we have to keep supporting old releases? :) (I continue to not be a fan of supporting old releases, I would much rather do things like support the new Big Sur UI style now, than in 3 years time)

[dasmurphy]

Just 2 cents from me. It would be awesome to get at least one release which works on 10.14. This is my current system due to 32bit support for some Apps. Currently i cannot upgrade, but i know that i will in future.

I don't know if anything would be possible to create with 10.14+ with Big Sur Style support. Any way this would be awesome.

What do you think you can do?

Just a comment: I hope i can publish my repo in future to github when i got some time to rework some small stuff. I got some nice things done like a multidomain static webserve, screenshot upload tool with drag and drop to the menu bar and a radio stream playing interface.

@cmsj Do you have access to the beta?

[cmsj]

All of our releases since 10.14 was released, should work on 10.14. Right now the minimum supported release of macOS is 10.12 in Hammerspoon 0.9.78. We probably don't have 32bit support in the most recent releases though, since my machine will have been on 10.15 since it released and Xcode dropped 32bit support - is that what you meant?

[latenitefilms]

Great news!

We’re still on Mojave on all our machines for the time being, as Catalina has so many bugs and issues in Film & TV land.

Based on initial reports, it sounds like Big Sur is a big step up from Catalina, and already more stable, so I can imagine we’ll probably skip Catalina and eventually go straight to Big Sur.

I’d like to keep supporting Mojave for the time being, until Big Sur’s been proven to be reliable after a few point updates.

[dasmurphy]

We probably don't have 32bit support in the most recent releases though, since my machine will have been on 10.15 since it released and Xcode dropped 32bit support - is that what you meant?

No, i'm using the current version, but i need 10.14 for some old 32bit Apps i need for work. That's why i'm currently waiting with the upgrade.

[asmagill]

(thought I posted this already, but it's not showing up in the thread... assuming it was me forgetting to post it after previewing it, and not a github glitch, I'll do so again... if this or something similar appears twice, I appologize!)

---

All this is before I've watched any of Apple's WWDC videos or read anything about the upcoming additions/changes, so I reserve the right to change my opinion as it becomes clearer exactly what will be involved, but my current thoughts on the matter follow:

I don't think that the issue for 10.14 will be Hammerspoon being built as a 64bit app (it has been for quite some time now) and 10.14 fully supports 32bit & 64bit apps; the issue will be if we link against frameworks or libraries not present in 10.14 and use functionality that isn't guarded with checks and fallbacks.

Personally, I have been trying to adhere to our habit (I won't call it a policy or rule since it's not that well enforced) of supporting the last three macOS releases -- 10.13, 10.14, & 10.15. Big Sur will just drop 10.13... assuming we maintain this habit, as to whether we drop 10.14 next year, I think that's a discussion for then once we see:

1. how many of our users really are holding back out of a need for at least one 32bit app in their lives, and
2. just how hard it is to write code which takes advantage of Big Sur's additions/changes when possible, but can fallback to something else when it's not... are we going to have to weak link frameworks to the main app? Or will simply checking for method existence in classes or if a function's reference is NULL be sufficient?
3. how many of our new modules (ones we may not even be imagining yet) require 10.16 and simply can't be made to work with earlier macOS versions (as I recall, hs.webview initially had to prevent itself from loading for some because the WKWebView class didn't exist in a macOS version we still wanted to support at the time)

At any rate, those are my thoughts at the moment, at least until I get a chance to review the upcoming changes myself or hear convincing arguments otherwise.

[cmsj]

Sidestepping the OS version support, I've also just gotten the first successful build of Hammerspoon for ARM. Obviously I can't test it yet, but the changes were very minimal - mainly fixing one preprocessor macro bug in the Sentry crash reporter, and then dodging a new compiler error that complains about the many places where we cast lua_toboolean() (which returns an int) to BOOL.

[latenitefilms]

Awesome!

Did you request an Apple Silicon Developer Device?

[dasmurphy]

@latenitefilms Nope, sorry. Would like to, but it is too expensive for private fun since at work we don't need it.

[cmsj]

@latenitefilms I did. Not heard anything back so far, and honestly I suspect they would want to focus their resources on bigger fish than us :)

[cmsj]

For when one of us, or someone we know, gets an Apple DTK, here is an ARM build: ARM-Hammerspoon.app.zip

[saagarjha]

Runs fine, although some small things are buggy. Would you happen to have an Intel build compiled with the Big Sur SDK so I can compare?

[rsefer]

Just installed the public beta (v2) for the first time. Seems to struggle with hs.window for every application except for the Hammerspoon app itself and related windows. This makes me think there might be a permission issue?

Hammerspoon functions a lot better when it's given Accessibility permission - shoulda known 🤪! FWIW I don't think I was prompted to give Accessibility permission in Big Sur like older OS versions.

[saagarjha]

Wait, where's the public beta?

[rsefer]

@saagarjha To be clear, I was referring to the macOS Big Sur Public Beta

[saagarjha]

Oh, I see. Basic hs.window usage seems to work for me, is there anything in particular that didn't for you?

[rsefer]

@saagarjha I hadn't enabled Accessibility. Once I did that, things mostly worked as expected!

[cmsj]

I've just released 0.9.82 which is a Universal build, and has bumped the minimum supported OS to 10.13. Enjoy!

[latenitefilms]

@cmsj - Does this mean that to build Hammerspoon, you now require Catalina or Big Sur?

[cmsj]

@latenitefilms I think it should still build on older OSes - mostly what I was actually doing in the 0.9.82 commit was putting things like SDKs/Architectures back to the defaults, but I'm not sure (I don't have any pre-Catalina machines to check with)

[asmagill]

I'm actually considering a new laptop at the start of the new year, so it's good news that we've moved to a universal build! And I'll forgive you for not giving me time to merge a few of the outstanding pulls that really are ready (was planning to do so over the next couple of days)

@cmsj, I've been considering the number of releases we support recently (your original question from Jun 23).

Here are my thoughts...

We've unofficially maintained an "at least 3 versions" pattern so far... I think it would be reasonable to iron out a list of things we want to include in Hammerspoon with the current compatibilities and target say January or February. At that point, we start the 2.0 branch.

2.0 should start Big Sur only. I do think that the 2.x branch should probably maintain a "+1 version" pattern after Big Sur, because not everyone will update at the same time, but we make it known early that 2.x moves more rapidly. It will also give us a chance to clean up and standardize some things that are currently wonky between our modules (e.g. hs.window has separate methods setFrame and frame while hs.canvas has just frame which does both, depending upon how many arguments are passed in; remove a lot of the cruft for maintaining versions that we really don't support any more; formally remove modules that are really just wrappers these days like hs.drawing, etc.)

If someone does decide to take over maintaining the < 2.0 branch for backwards compatibility with more macOS versions, I don't mind making a good faith effort for a time to make updates and new modules that I personally work on mergeable with both (I did the same for a while with Mjolnir before it became clear that it really was being abandoned in favor of Hammerspoon), but that will be my personal choice, not the project's goal.

[cmsj]

@asmagill I did think about trying to collect up some PRs, but I thought since this would involved some big ugly diffs to xcode and cocoapods files, it might be best to try and keep that isolated. We can do another release at any time when some PRs are merged :)

I like the idea of a bit of a reset for 2.0 and a smaller support window, particularly since basically all new Macs will be incapable of running anything earlier than Big Sur.

[dasmurphy]

@cmsj & @asmagill Please consider 10.14/10.15 support for at least some time, since there are many Macs who cannot upgrade to Big Sur. Mac Mini's and iMac's older than 2014. I am also currently stuck on 10.14 for now, since i need some 32 bit support for legacy apps and Steam Games.

I don't know how much hassle is the support for the Macs with older systems, but it may be implemented after the cleanup for Big Sur. So you have a clean base and the support can be added later in. I don't know how much this is possible at all, but i'm all in for cleaning up the API's and removing old stuff that isn't needed any more.

Currently i cannot help to maintain compatibility, due to not enough knowing on Objective C, but that can change with some time.

[cmsj]

@dasmurphy The big issue for me is that I don't have any Macs that run older versions of macOS, so I can't test if a new release even still works on older releases (and if I'm honest, I don't really want to do that). However, it's also very much the case that we (especially me) are going pretty slowly at the moment, so I wouldn't expect 2.0 to happen any time particularly soon.

[asmagill]

As I see it, the switch isn't likely to occur until sometime in (hopefully early) 2021, and it will likely be a while after that before an actual release is made because there is a lot of code to go through and decisions to be made on how to clean things up. It's probable that concurrent development, especially in terms of bug fixes, will occur in both for some time, even once we do start to work on 2.x versions (which, to be honest, we've talked about before but have failed to make much progress with).

I also have an iMac (it's not my primary machine, but I do use it occasionally) that I'm not ready to get rid of yet that can't run Big Sur (by just one season!) so I'll be testing things in Catalina at least for a while even if I end up having to create a hybrid fork once 2.x does actually get rolling.

But I also agree with @cmsj that we need to clean out cruft that is no longer necessary (I came across comments about work arounds for 10.8 the other day in one of the modules!) that just takes up space, makes code more unwieldy to read and understand, wastes resources, or limits what a given module supports; and I too would like to take advantage of some of the new APIs without having to worry about whether it will compile or even run on an older machine.

With Apple's move to M1 it seems an ideal time to draw a line and as I mentioned earlier, if there is enough interest in maintaining the older version, I don't mind continuing to contribute to it as well.

[carlyounger]

I appreciate it's slightly off topic, but this seemed like the right thread generally...

Application icons on Big Sur all place their logo inside a rectangle with rounded corners. The icons are very consistent now; all the rectangles are the same size. The Hammerspoon icon is larger and tilted, so looks awkward when its the only icon like that.