Call Recorder Succumbs to Apple Silicon
Call Recorder for Skype is not compatible with Apple’s M1 Macs. […] Call Recorder for Skype will not be updated for compatibility with M1 Macs.
Over the past year, nearly every Skype update has broken compatibility with Call Recorder, requiring Ecamm to issue repeated updates and even change how the app behaves so that it automatically reinstalls itself after Skype kicks it out.
With the exception of unusual episodes recorded with my guest(s) in person, I’ve recorded every episode of The Talk Show using Call Recorder. It does one thing and does it well, and I love the option to record all Skype calls automatically.
Call Recorder not surviving the Apple silicon transition is a real bummer, as it was the easiest way to record but local audio and audio from a Skype call, all automatically.
In fact, if I’m being honest, Call Recorder hasn’t been my primary audio-recording tool for years. That distinction goes to Audio Hijack, which works with any app (not just Skype). But I have kept Call Recorder running for every Skype call I make, sometimes as my primary recorder, more often as a backup.
There’s a broader issue here, though. We rely on tools, and we build whole workflows around those tools. Remove the core tool from the bricolage of software, hardware, and mental calculation that forms a computer workflow, and you might end up never noticing—or the whole thing might collapse like a wobbly Jenga tower.
I can’t recall Audio Hijack ever failing me. Nevertheless, I really felt good knowing I had that Skype Call Recorder backup. With its demise, I can make a backup of me alone using QuickTime, but it’s really not the same. I’m not capturing the entire call. I’ve been talking to other podcasters about this dilemma and the collective wisdom seems to be leaning toward moving the entire recording process over to Zoom.
I wish software were more durable over the long term, but that comes with its own baggage. That has long been the wrench in the spokes of Microsoft’s bicycle: some companies depend on software written when I was learning to walk.
On an individual level, we have to be okay with adaptation, but it is hard.
Previously:
3 Comments RSS · Twitter
Yeah, look, I'm getting just a little bit tired of this defeatist attitude to software breakage. Maybe we can agree that Win32 is a little bit hairy but come on, respect for compatibility is respect for your users! We aren't obliged to swallow every change--we should demand that unnecessary breakage is avoided. Apple are just ruthless, that's all. Together with a shift towards "subscriptions", it's a gravy train.
Still on Mojave, where 32-bit apps still work. (But as I don't have any I can live without, it's not a feature I'll miss on upgrading.)
@Sebby
I think the claim that Apple doesn't respect compatibility is just an old trope. Yes, sometimes Apple does get rid of frameworks or architectures that are at a dead end, but they often give developers plenty of time to move to (hopefully) better conceived frameworks and architectures that will last longer than the last. I certainly wouldn't want developers stuck using paradigms, frameworks that were only imagined 15-20 years ago. I've seen other companies hindered by the very thing.
> Apple are just ruthless, that's all.
In this case, it sounds like every time Skype was updated, even before M1 Macs were released, it broke Call Recorder. So I'm confused as to how this is Apple's fault. It just sounds like the developer was tired of chasing after Microsoft's Skype changes to maintain compatibility.
> Still on Mojave, where 32-bit apps still work.
Developers have been able to build 64-bit apps since Mac OS X Leopard, released in 2007. Apple basically gave developers 12 years to transition to 64-bit before dropping support. 12 years! If an app is still 32-bit, it either isn't being actively developed or is possibly stuck architecturally, which means not much else is likely to happen.
> Maybe we can agree that Win32 is a little bit hairy but come on, respect for compatibility is respect for your users!
It really isn't that simple. Microsoft still has a hard time getting developers (including their very own) to move to newer frameworks.
Compatibility is a double-edged sword.
> Yes, sometimes Apple does get rid of frameworks or architectures that are at a dead end
My impression is that they do this all the time, that the replacements are often incomplete and unpolished, that documentation is often severely lacking, etc. It's certainly possible to do far worse than Apple (hi, JS devs!), but they could, if they were willing to put their resources into it, do far better. Don't deprecate stuff until there are suitable replacements. Document those replacements. Gather input from developers as to whether the replacements cover real-world use cases. Etc.
Part of this is the secretive culture (you get a dump of new stuff at WWDC, then are largely left to handle it), but part of it is absolutely avoidable.
