Hacker News new | past | comments | ask | show | jobs | submit login

So do like Microsoft does for 16bit/DOS support in the most recent 32bit windows, and let NTVDM be an optional download that is triggered on first use. Do the same for armv6/armv7 dyld files. Maybe they could even just freeze the armv6/armv7 libs on the iOS10 API level, since old apps won't be requiring new APIs. There are important apps out there that people paid for (for both the app or the hardware), and I think those users are more interested in having a working app that uses some memory, than a blocked app but lots of free memory.



The reason that Windows sucks are often linked to it's long backwards compatibility. Remember when the first Surface came out and they couldn't sell an entry level version with 16 gigs storage because the OS took 13 gigs?


At the same time this reliable backwards compatibility is what keeps Windows in the market position it has, in particular in the corporate world.

Something a number of FOSS projects should take to heart when they fret about "year of the desktop".


Even if the compatibility layer is optional, Apple still has to maintain it and port it to new OS versions.


> Apple still has to maintain it and port it to new OS versions.

Apple decided that they don't want to open-source it. That is the reason why Apple would have to maintain it.


Ok, I love open source but let's not pretend it's that easy... "Just open source it" is something I hear from people that have never open sourced a large code base developed internally only. Look at RethinkDB, I never used it but I had wanted to on multiple occasions and it looks really awesome. They were open source from the start and yet the future of it now that the company is gone is uncertain at this time. All of this ignores the fact that the compatibility layer is much more than just 1 application and an integral part of the OS. I seriously doubt Apple plans to release tools to make development of said layer easy for for whoever can clone the project off github.


With something like RethinkDB though, you're relying on it in production.

With a compatibility layer or a game, you're just toying around, trying to make it run something. If it works - awesome, if it doesn't, you're not losing money over it.

I think there's a substantial difference here.


Apple shouldn't have to open-source anything they don't see fit to open-source for their own benefit.


With the resources that Apple has, it would be silly to throw out so much backwards compatibility just because "uh, effort".


I don't think size and resources can effectively combat this sort of accrued technical debt. Once you have to maintain so much cruft it becomes emotionally difficult to write good software (at least, I experience this).

I have a few personal projects that I have maintained for years, but the motivation required to refactor, clean and maintain the code gets bigger every year.

You have to be passionate about the software you write. And unless you can find a team that is passionate about maintaining a 32 bit compatibility layer for old App Store apps, I think it would be a permanent burden on Apple.


This is the reasoning that made Windows so crappy for so many years.


It's also the reasoning that has left Windows so dominant for so many years. There are businesses that would go bankrupt overnight if Windows broke compatibility with 32-bit VB6 applications built at least a decade and a half ago.




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

Search: