{"id":47360,"date":"2025-04-09T15:57:01","date_gmt":"2025-04-09T19:57:01","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=47360"},"modified":"2025-04-09T16:02:10","modified_gmt":"2025-04-09T20:02:10","slug":"soured","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/04\/09\/soured\/","title":{"rendered":"Soured"},"content":{"rendered":"

Matthew Bickham<\/a> (Hacker News<\/a>):<\/p>\n

\n

Once upon a time, developing for Apple was an exciting, rewarding challenge. Apple built world-class hardware and software, and developers created incredible apps that made those devices indispensable. It was a win-win. But in 2025, that relationship has soured.<\/p>\n

[…]<\/p>\n

Sure, they’ll pay lip service to developers. But as in any relationship, don’t listen to the loving words of the perpetrator, instead observe their hurtful actions. Apple has continually created an environment and policies, along with nurturing a culture, that is detrimental and harmful to developers.<\/p>\n

[…]<\/p>\n

Developing for Apple isn’t just about writing great code — it’s about navigating a bureaucratic obstacle course filled with red tape, secret handshakes, and hidden pitfalls.<\/p>\n

[…]<\/p>\n

Now from experience, I know there is a limit on the number of rules that can be loaded. This isn’t documented anywhere. You are just meant to know the limit. […] Unfortunately – and what isn’t documented anywhere – is that although you can load that many rules, you are unlikely to actually be able to do so. There is also a hard, undocumented, memory limit on the extension process that loads the rules. A memory limit that kills the extension and means the app doesn’t work if it’s exceeded. A memory limit that isn’t documented, isn’t defined and isn’t known until you spend weeks trying to determine why your app is not working. An undocumented memory limit that is also different across iOS and macOS.<\/p>\n<\/blockquote>\n\n

He also talks about the annual release cycle and API churn. There are certainly other prioritization and management issues, e.g. with Radar, documentation, and the elevation of “security” over all else, but so many problems come down to the schedule. Apple is trying to do too much too quickly. Major changes are snuck in months after the beta cycle began. Remember when “beta” used to mean that it was feature-complete and had already been extensively tested internally? And, of course, they ship stuff that’s immature (doesn’t work, has bugs or obvious design flaws, isn’t documented, etc.).<\/p>\n\n

In theory, the release interval is arbitrary and not determinative: an annual schedule could be fine if the releases were smaller. But this is not what Apple has been doing. And, recently, they’ve made it worse by announcing stuff that they know<\/em> won’t ship in the 0.0 release. This is spun as clever planning to deliver new delights throughout the year. But it seems more like a cope for squeezing more into the major release than they should. And the reality is that it means introducing whole new APIs and breakage in the 0.4<\/a> release<\/a>. We no longer get a stable version before the next cycle begins.<\/p>\n\n

The outward manifestation of all this is reduced quality. What’s less seen is that this bad process ultimately wastes time for everyone involved. If Apple ships something with known issues or issues that could have been caught internally, that generates work for external developers. They have to test and file bugs and develop workarounds because there’s no longer an expectation that bugs will be fixed before release to customers. Apple then has to process these bug reports, which it clearly doesn’t have time to do before shipping. As a bug gets out to more people, customers encounter it, which wastes their time and generates more support load and bug reporting for developers and more bug reports and AppleCare calls for Apple. So much of this could have been eliminated by catching problems earlier in the process. But, hey, technically they did hit the schedule.<\/p>\n\n

Ironically, Apple does understand this at the micro level. They continue to make improvements to Xcode’s automated testing support. And Swift is all about catching problems early. Before you get to runtime<\/em> testing, let’s block you from even compiling<\/em> code with these potential errors. Let’s restrict what you can do in the interest of being able to prove<\/a> to the compiler that it’s correct. And if a bug does make it through testing and to a user’s device, fail<\/a> fast<\/a>. Yet at the macro level, Apple’s software strategy seems to be the opposite. Ship first, catch later, move fast and break things, just fix it in post<\/a> (or not<\/a>).<\/p>\n\n

Scott<\/a>:<\/p>\n

\n

Just had a thought: given rumored iPhone 17 designs which are—quite simply—not all that compelling, that the M4 has made it Mac-wide (excepting the Mac Pro), and the tariff situation, now would be a PERFECT TIME for Apple to announce a 1 year ‘pause’ (of sorts) on OSes, ‘SNOW’!<\/p>\n

[…]<\/p>\n

Could announce at WWDC that they’re extending development on i|PadOS 18 and macOS 15 another 12 months; squashing bugs, solidifying features, not dropping any additional Intel Macs or iPhones, and eventually, finally, really bringing promised Apple Intelligence\/Siri features.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n