Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Aging thread by now, but had to chime in with some clarifications as an indie dev dealing with similar issues, to respond to those saying stuff like 'you're a bad dev if your app isn't 64-bit by now'. I am a company of 1 humbly maintaining a cross platform app that's been around long enough to predate the 64-bit era. It's about 70%/30% Windows/Mac sales. When the majority of machines out there became 64-bit years ago, I happily optimized the components of my app that stood to benefit from 64-bit, such as intensive media processing tasks and other bottlenecks. But since a lot of computing tasks just don't need what 64-bit offers, parts of my app that were working well enough using 32-bit components stayed that way, and users never knew the difference or cared because over the years I strategically targeted the areas to rewrite as 64-bit without having to reinvent the wheel and devote resources to rewriting everything.

Since the 64-bit x86 instruction set was implemented to sit on top of the legacy 32-bit one, it is literally impossible for x86 hardware to cease supporting 32-bit into the future. So we have Apple here making the choice to cease software support of this backward compatibility feature already baked into the cpu, to save a few bucks or whatever. There is no performance benefit to abandoning 32-bit. Your Mac won't be faster on Catalina because 32-bit support is gone, despite what Apple is trying to imply in their marketing, because the cpus they use are still built from the ground up to support 32-bit. A negligible-by-today's-standards amount of RAM and disk space used by the system will be conserved, but that's really it. So Apple, the wealthiest software company ever, has decided to stop funding software support of a feature already present in the hardware they are selling you at ungodly markups, thus screwing over both customers out of legacy app support, and indie devs with costly extra refactoring work that in many cases offers no perceivable benefits to end users. This is why it is infuriating to be an indie dev supporting Mac right now.

As for my specific case, my software, under the hood a combination of several 32-bit and 64-bit processes, still runs happily on Windows, and most of my customers are on Windows, particularly large organizations that purchase site licenses and sponsor new features or customization projects. But in order for it to be 100% 64-bit, so much of it would have to change due to old dependencies as to require rewriting a huge chunk of it from scratch. This is my technical debt to bear. When it became apparent a few years ago that Mac would phase out 32-bit support, I began work on a full 64-bit rewrite, but I've been sidetracked as customization projects and consulting gigs from Windows-only customers continued to pour in and with limited resources as a small company I had to choose to prioritize those projects which added tangible features to my software right now at the expense of making progress on the 64-bit rewrite. I continue to work on the rewrite project so that I can continue to support the Mac platform, but it sure feels like a whole lot of work to port features to 64-bit that won't have any noticeable improvement to end users! In the mean time I feel terrible that Mac users who upgrade won't be able to use my software until I get around to completing the 64-bit version. But it just never made sense for a company of my scale to devote resources to racing to complete a 64-bit rewrite for the sake of those 30% of sales. These are the kinds of choices that a small business must make and thus is the position I find myself in as an indie Mac developer.

I hope this provides an understandable real world answer to the question of "how can any app under active development in 2019 still be relying on 32-bit?".



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: