Vent About Apple's Cruddy Recent Treatment of Developers

Latte
1

Warning: this post may (will) contain whinging.

I am genuinely seething right now over the way Apple treats developers who spend hours and hours of their time conscientiously reporting bugs.

Whenever I encounter a bug in macOS or iOS while coding, or whenever a bug reported by a user turns out to be down to Apple code, I file a bug report with Apple via their Feedback Assistant app/online bug reporting service. It’s not enough just to file a report telling Apple the issue, even if it is easily reproducible. Apple will always ask for a sample project (code) if you don’t provide one. So, I always put together a sample project in Xcode (Apple’s app for developing apps). This can take time - ten minutes in the simplest of cases, an hour or two for more complicated bugs.

Along with the sample project, you have to describe the bug and list all the steps Apple’s engineers need to take to see the bug in the project - more time. All of which is worth it if you’re helping to make the OS more stable and helping Apple fix the bugs affecting your apps. If.

Bug reporting has always been a bit of an issue with Apple. For a large number of bugs you’ll never hear back. They might be fixed without you being notified, or they might just never get fixed. (I have bug reports submitted back as far as 2005 that are still open with no reply.) Others will be closed as duplicates because someone else has reported them, after which you have no way of tracking them.

I can live with all of that - after all, Apple must receive thousands of bug reports every single day. What I can’t live with is Apple’s latest wheeze for dealing with so many reports.

macOS and iOS 26 - being such major changes - are the buggiest releases I’ve seen for years. I have reported more than sixty macOS/iOS 26 bugs to Apple since the first betas in June. Add up the amount of time those reports took me and it must be in the region of days. I don’t expect fast replies or resolutions to these problems - but I do expect Apple to at least leave the bugs open until a human can look at them and test them. For the time I put in, all I expect is the courtesy that an Apple engineer will one day look at what I’ve submitted.

These days, however, a few weeks after filing a bug report, after a couple of minor macOS or iOS updates, I frequently receive a reply that goes something like this: “Is this still an issue for you in a recent build? If so, please attach fresh sysdiagnose logs and any other relevant information, or documents that might prove useful in reproducing this issue. If not, please close this feedback report.” (That vague “a recent build” should be a red flag.)

I’ve fallen for this ruse a few times now, booting into my beta-testing partition and running through all of the steps in the sample project I provided them to test what’s changed - only to find that the bug hasn’t been fixed or even touched at all. What’s happening, it seems, is that Apple is now sending out automated responses to developers, even when no Apple engineer has looked at the report, putting the onus on developers to keep checking their sample code to see if a bug happens to have been fixed by something else that has been changed in the OS (presumably).

Oh, and if you don’t reply, a few days later you get another automated response telling you that the bug report will be closed within two weeks if you don’t respond. (Even though it might have taken Apple many months to have sent you their - automated - reply.) And of course their system allows for no way of reopening a bug report - if your report is closed, you have to submit a new one.

All in all it gives the impression that Apple is more concerned about closing bug reports than actually fixing bugs. And I find it hugely insulting that Apple seems to have absolutely no respect for the time developers put into reporting issues to them - time that we’re not paid for.

For now, my new tactic is to reply asking if a human engineer has checked the project and steps I provided before I do any further testing myself, but the system is so frustrating that it makes me question whether it’s a good use of my time reporting bugs to Apple at all. Sigh.

Okay, that’s my developer whinge over - I’ll get back to coding (and working around bugs) now. :slight_smile:

16 Likes
2

I feel the pain, Keith, I really do.

My Safari bug reports go into a black hole. I never hear anything, so there is that.

5 Likes
3

I have just used Feedback Assistant to file some feedback on Feedback Assistant, bemoaning the automated replies - if I receive an automated reply to my complaint about automated replies, I shall either laugh at the wag who sends it or despair.

10 Likes
4

It just irks.‎​​​​​​

3 Likes
5

This sounds exactly like someone that has hit their glass ceiling in management is trying to cook their numbers to break through the barrier their incompetence makes for them. That error loop just sounds suspiously like the reason why “I need you to do x” that would break the connection/call with tech support instructions that became annoying in the 1990’s. Because if they can close things out quicky, and you are too annoyed to jump through all the hoops again, thier numbers improve, they can count it as an issue corrected, and they look good.

Pity there isn’t a really good way to reach out to someone in the C-suite with these sorts of issues.

2 Likes
6

Time for an email to Tim Cook?

DM me if you haven’t guessed the address.

It might not get any resolution, but at least it sends a cascading ‘please explain’ down the chain and a requirement for detailed response within a tight timeframe. (you should see the panic it causes)

Can’t say more than that publicly because of enduring NDA.

:grinning_face:

7 Likes
7

I did ponder it - I know plenty of people do that, and that it can get a response - but I don’t want to be a bothersome developer. In the classic British manner, I’d rather have a bit of a moan than cause a fuss. :slight_smile:

4 Likes
8

I swing wildly between being that quiet roll with the punches Brit and being a brash ‘stir sh.t’ Aussie. :rofl:

5 Likes
9

Time to channel your inner Yankee: “I demand to speak to a manager!”

Or task one of your staff to draft the note for you. I’d love to unleash my poison pen in Mr. Cook’s direction. It can be fun to kick into high dudgeon/diva mode…

7 Likes
10

Hello KB,

If I’m not mistaken, you are the owner and main developer of Literature & Latte. In advance, I want to thank you for your work in creating Scrivener, an application that has been essential for me over the years.

This post is a relief from the reality facing the IT sector. Although I am simply a junior developer and my experience is very limited, I think I understand your criticism perfectly. In fact, I suppose that this phenomenon (the bureaucratization of communication between a company and its partners) is related to Apple’s dominant position in the market, especially in the USA. Apple not only will receive thousands of error reports, but, as a Big Four with reputable engineers, many of these employees will not be willing to recognize such existing bugs in the system.

For example, in the field of free software, the attitude of GNOME developers is known for their condescension and denial of the existence of problems. When somebody points out that something does not work well or that an aesthetic change only breaks things without providing added value, the response of such developers is: “you are not using our system/application well” and they close even elaborate pull requests that solve problems.

As I was saying, I’m pretty sure that many Apple engineers have a very personal view of the system and won’t be willing to have other “second-level engineers” point out bugs in their code. That is, apart from the saturation of messages or the lack of staff, my hypothesis focuses on condescension.

From my deepest humility, I would suggest maintaining a code base that is as independent of a specific system or technology as possible. Although having a native program for Apple improves integration with the system, the same thing happens in computing as in nature: an excess of specialization leads to the extinction of the species. In nature, generalist animals usually survive, so, using this metaphor, betting on a multi-system strategy (including Linux) could be essential in the long term.

Regards.

2 Likes
11

All good in theory, however, extremely specialised animals continue to survive and prosper.

The reality of code that is platform independent is that it tends to the mediocre. The inbuilt Apple development apps enable a far superior customer experience that using any 3rd party option (IMHO). You can look to the Win version of Scrivener and the development challenges that occurred using the ‘platform independent’ QT for confirmation of that.

1 Like
12

Scrivener OS 1.0, coded in ScrivenerScript with a LiquidWords UI.

<sorry it has been a long day fighting Safari … features … >

3 Likes
13

@RuthS: “I demand to speak to a manager if one is available and they have the time to speak to me and it’s not too much of an inconvenience thank you very much!”

@Adrlopgal: I am indeed the lead developer (and majority owner) of L&L. Thanks for your kind words about Scrivener. (I have noticed your helpful contributions in the [redacted] beta testing forum, so thanks for those!) In all fairness Apple does have a lot of very helpful and conscientious developers, including some who are active on the developer forums. I certainly hold no ill will towards the developers. When I do receive a reply from real-life-human engineers, they are usually keen to fix the bug and look into the issue.

The problems lie with the system that has been put in place, the way that system has got worse, and whoever thought it was a good idea to start sending out automated responses. I saw another developer hypothesise that bug fixes at Apple get submitted with keywords related to the fix, and that those keywords are then used to find vaguely related bug reports and send out automated responses. That sounds like what’s happening. Anyway…

As for maintaining a code base that is independent, Apple users tend to be quite opinionated about that, and much prefer apps that are native. Electron apps, for instance, get a lot of abuse. And besides, as lead designer, I write in Swift and Objective-C using the Apple frameworks. :slight_smile:

6 Likes
14

This is why we love you, Keith. Decorous and classy, always.

5 Likes
15

My wife is a Brit. She only got mad at me – really and truly mad – twice in several decades of marriage. Each was a near-death experience, and I never saw it coming. So tell me, Keith. Are you anywhere near the limit? Because, to we Yanks it’s impossible to tell. If so, I’ll gladly hold your pint while you take care of business.

8 Likes
16

@SCN,

You’ll know when Keith is getting near the limit when he says that something is ‘getting a bit much’. The limit has been passed when it’s ‘really not on’.

‘Really not on’ is roughly equivalent to DEFCON 0.5.

7 Likes
17

You mean it’s not like this?

6 Likes
18

Is this the new Apple Intelligence in action?!

@KB and the whole L&L team – We appreciate you! Thanks for your hard work and dedication and perseverance.

8 Likes
19

It reminds me of a New Yorker cartoon from decades ago. A senior manager type is sitting behind a big desk saying into the telephone, “You can rest assured that your problem is being ignored at the highest level.”

We’re all behind you, Keith.

:slight_smile:
Mark

5 Likes
20

Either I just missed the joke or the Google Censorship AI got cranky.

Screenshot 2025-11-11 at 15.52.26
Screenshot 2025-11-11 at 15.52.261586×1394 165 KB