An update of what's happening with ImageOptim:

The existing project consists of multiple external executables (for various 3rd party tools), internal framework (forced by Apple's sandboxing requirements), and plug-in (for Apple Mail). This seems to be more than Xcode can handle, and it's causing a constant source of pain with broken Xcode builds, invalid Apple Code Signing signatures, inefficient and fragile archiving, etc. Apple's new Notarization requirements are even harder to satisfy and the errors it reports are Kafkaesque.

The net effect is that Xcode builds are broken more often than not. Making an ImageOptim release that takes hours of debugging, testing, and solving vague unhelpful errors reported by Apple's tooling and OS. This is not fun.

Second, ImageOptim's codebase is old. The project is 14 years old! When I started it multicore CPUs were a novelty, and many modern macOS APIs didn't exist yet. I've retrofitted what I could, but the architecture of the application is in some places messier than I'd like. AppKit/Cocoa is not thread-safe, and Objective-C is unhelpful for ensuring thread safety. In fact, small mistakes lead to very hard to track crashes. This is not fun either.

Third, being tied to Apple's proprietary technologies has been problematic. People keep asking for ImageOptim for Windows, or a CLI version that works on Linux servers, or something that will work on mobile. The current code can't do it. Being tied to the C language and the old AppKit is a problem. It's not even the best solution for macOS any more.

So my plan is:

• The current codebase is dead.
• I'm going to write a new core of ImageOptim using Rust. Rust is a native language with excellent support for reliable parallel code. It works on macOS, iOS, Windows, Linux, Android, and WASM. It doesn't need Xcode!
• There will be a native CLI version for all platforms that Rust supports.
• I'll give it a native UI for macOS using SwiftUI. But if Xcode and Code Signing keep being annoying as they were, you're getting an Electron app instead.
• I may make a Web version via WASM, and maybe GTK for Linux. We'll see.

There's no timeline for it. It's still a hobby project.