2025.01.07.

Retiring Script Debugger

I ran into this post the other day about Script Debugger getting retired.

January 2025 marks Script Debugger’s 30th anniversary. It’s been a very long run for a two-person effort. Script Debugger began as a Classic MacOS product, survived Apple’s near-death experience, transitioned to macOS X and migrated across 4 CPU processor types. We are so grateful for the support we’ve received over these years. This support allowed us to keep working on Script Debugger much longer than we ever imagined.

Shane and I are retiring and the effort and costs associated with continuing Script Debugger’s development are too great for us to bear any longer.

I bought this app about 2-3 years ago because I was getting serious about learning AppleScript, and in a short amount of time, it became an important part of my workflow. As I mentioned, I learned AppleScript with the help of Script Debugger’s awesome live inspection feature.

Since then, I have used this app to build many scripts that I use in my everyday workflow.

I don’t know the current state of AppleScript inside Apple, but I know that the difference between Script Debugger and Script Editor is night and day. Script Debugger should be part of the system, which is why I feel sad that another great Mac app, especially one with such a long history, is getting retired.

In June 2025, Script Debugger will no longer be offered for sale and all support and maintenance will cease.

At this time, Script Debugger will become a free download. Links to all versions of Script Debugger back to 5.0 will be posted, along with registration numbers that can be used to activate the software. These free versions of Script Debugger will be provided as-is and without any maintenance or support.

Currently, the developers plan to leave it as is. The problem with this approach is that any future macOS update could break Script Debugger. It’s not like 1Password 7, which, after years, I still keep around because I’m not going to migrate to their stupid Electron app. Script Debugger is a complex beast, so any new Windows Vista-style “security” dialog could kill it in an upcoming version. And boy, Apple has been really into “Cancel or Allow” lately.

Will Script Debugger become an open-source project? No. Unfortunately, there are portions of the Script Debugger source code we do not have the right to release.

I’m not sure how the app could be saved. I created a topic on MPU to let people know about it. Open-sourcing will not work since there are licensing issues, so the last resort is for someone to buy it. Or maybe some people in the Macscripter.net community could take care of it as Late Night Software “contractors.”

I don’t know yet, but it’ll be pretty sad the day when Script Debugger stops working.

Just an aside: it makes me wonder why we have Emacs and Vim still around alive and well…

2024.04.12.

2023.12.19.

It is more than funny (and sad) that Electron apps are so bloated now that they can’t even offer a proper universal binary. You have to pick the CPU family on download.

2023.12.06.

Read “Web Apps Are Better Than No Apps”

Since web apps can’t just use the components provided by the operating system, they have to recreate everything from scratch. And this creates a lot of burden for developers and, I think, lowers the quality floor. Creating beautiful, compelling apps is possible, but it requires so much work. People building native apps get it all “for free”. In fact, this could be one of the reasons Apple still has such a vibrant ecosystem of great artisanal apps since developers can build most things out of nice ready-made components.

Well, yeah!

2023.03.18.

2021.08.14.

Where to go after 1Password 8?

After this week’s news on 1Password forcing users to the crappy experience of being an Electron app, I started to look for alternatives. I haven’t decided yet, but I’m considering the following options.

  1. Elpass: subscription-based, native iOS and macOS apps, looks good.
  2. Secrets: one-time payment, native iOS, and macOS apps, also look good.
  3. iCloud Keychain: free, built-in to iOS and macOS; also, it will have a couple of new features this autumn, like two-factor authentication.
  4. Update on 2021-08-14: Minimalist: I got this recommended in the comments, looks pretty cool as well.

I’m leaning toward iCloud Keychain because, nowadays, I like to use the built-in tools of the Apple ecosystem.

The only question I have with iCloud Keychain is where to store passwords of my servers and a couple of app licenses? I think the built-in Keychain app on macOS will be OK for this. It can store arbitrary username/password pairs (great for servers), and it has secure notes which can hold the small number of serial numbers I have.

Right now, the next step is to clean out my old passwords from my 1Password and iCloud Keychain databases before starting the migration process.

2021.02.25.

Remote work is not local work at a distance

Jason Fried wrote a post about doing remote work, with the expectations of local employment. This post resonated with me very well since I had a couple of weird interviews lately. Just a side note: yes, I quit my current job as a Ruby backend developer at TerraCycle about three weeks ago, and I’ll start working as a frontend developer/product designer at Nearcut on March 10th.

There are still companies that refuse to accept that remote work is a viable alternative. They want you to be in the office because “this is what we did before the pandemic, and everything should be back to normal soon.” No, nothing will be like before, and companies should embrace that, not deny it.

Not everyone’s like that. Even big ones consider remote work a viable alternative but don’t have the hiring process and experience to work like that, so they’re relying on old habits.

The enlightened companies coming out of this pandemic will be the ones that figured out the right way to work remotely. They’ll have stopped trying to make remote look like local. They’ll have discovered that remote work means more autonomy, more trust, more uninterrupted stretches of time, smaller teams, more independent, concurrent work (and less dependent, sequenced work).

I’m interested in what COVID-19 will do to remote work because, seriously considering remote work is one of the positive changes of the pandemic that happened in many workplaces. People were forced to work from home. Many companies figured out how to do this successfully, and they don’t want to throw out this knowledge because “everything will be back to normal.”

Jason also writes about native platforms:

Porting things between platforms is common, especially when the new thing is truly brand new (or trying to gain traction). As the Mac gained steam in the late 80s and early 90s, and Windows 3 came out in 1990, a large numbers of Windows/PC developers began to port their software to the Mac. They didn’t write Mac software, they ported Windows software. And you could tell – it was pretty shit. It was nice to have at a time when the Mac wasn’t widely developed, but, it was clearly ported.

When something’s ported, it’s obvious. Obviously not right.

Stuff that’s ported lacks the native sensibilities of the receiving platform. It doesn’t celebrate the advantages, it only meets the lowest possible bar. Everyone knows it. Sometimes we’re simply glad to have it because it’s either that or nothing, but there’s rarely a ringing endorsement of something that’s so obviously moved from A to B without consideration for what makes B, B.

Maybe Basecamp should create a Catalyst version of HEY for Mac from their iOS app, which is quite nice, instead of having a cross-platform Electron thing on the desktop called a “native Mac app.”

2020.09.10.