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

The last statement reminds me of Linus saying

we do not break user space

If an application is utilizing a bug, it is not a bug but a feature



Apple's general approach is "if it isn't documented, we can break it", a bit different to Linux.


I think, Apple's general approach is:"We can break it." Documented or not.

Seems like they change stuff all the time. Especially on iOS.


Can you provide examples of non deprecated API that Apple broke?


The recent Swift 1.2 release brought a whole load of code breaking changes. None of Swift 1.0 was explicitly deprecated.


That's a bit different, they explicitly said Swift is a work in progress and code compatibility is not guaranteed between versions...


After 1.0 API changes really should increment the major version.


Unless you say "We're probably going to break things." when you announce it, which they did.


Perhaps they should have chosen a more appropriate version number then.


Apple doesn't claim to do semver


Regardless, that is what developers have come to expect. Not that semver is adopted wholesale, but at least don't break the API without incrementing the major version.


I agree. I think there was never a major iOS release that didn't break things in my app. Really basic stuff like a text input for example.


I actually think it's much the same, judging from the quote from linus in the parent.


Yeah I was kind of wondering what his take on something like this would be.

On the one hand you're changing an API, which is a promise to userspace. On the other hand, no one was using it right leading to most networking apps being vulnerable to a DOS.

Given the proven risk and how little the feature is used, changing the API to match what people THINK it does seems sane.

I have a vague memory or Linus making a similar 'change it' decision once.


Also according to this article it was either undocumented or extremely poorly documented depending on which doc's you look at. So maybe they're removing a feature a lot of developers either didn't know about or didn't know they COULD utilise.


If no examples could be found of someone relying on the behavior, then a change would be okay. Otherwise the solution would be to implement a modified API.

Alternatively glibc could change it, as glibc almost seems to want to break existing programs.


There was an issue when people were using memcpy with overlapping addresses (ahem Flash), but I guess that was on stdlibc

https://bugzilla.redhat.com/show_bug.cgi?id=638477


I think this attitude is perfect for Linux, where many developers will not expend effort to maintain their software.

On the other hand, developers for OS X and iOS are often willing to expend enormous amounts of effort to keep their apps working.


Interesting but raising my eyebrowns a bit because sounds a bit too black and white. Do you have time to explain more or do you have some data to back up such a claim?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: