|
Apple, like all software companies, ships bugs. People who write software for their platforms also ship bugs, but sometimes they have to deal with the bugs that are in the OS and system frameworks. Sometimes these get fixed in future updates, but sometimes they don't, and in any case until then something needs to get done for software to work correctly, not crash, etc. Apple, like most companies, does not provide official mechanisms to patch bugs out of their software. They also keep most of their system frameworks closed-source. However, it just so happened that they write most of their software in programming languages are are highly dynamic and easy to reverse engineer, allowing third parties to dig into implementation details when they need to, understand how things work, and most importantly, change things as needed. It's risky and dangerous work, but every major app you've ever used on an Apple device ships with several fixes like these at any given time. The Apple of today has very different goals from their frameworks. Shipping symbols that help people understand how the system frameworks function is "needless bloat" that "exposes implementation details". Indirection and patching functionality is seen as overhead that can be removed for improved performance. App review does not like it when people ship self-modifying code, and as a result patching system frameworks is also not permitted due to codesigning. Swift in particular removes a lot of dynamic dispatch functionality, gets stripped far more aggressively, and compiles to code that is far less readable that what we had before. What this really means is that we are moving closer to a system where what Apple ships is what you get. Being able to make tradeoffs in this area is necessary, but the ones Apple have chosen mean that they have to be very confident that they don't ship bugs. If they aren't capable of doing this, well, it's not a good tradeoff. |