Apple developer boycott of Feedback Assistant | Hacker News Reader

Apple developer boycott of Feedback Assistant

lapcatsoftware.com

325 pointsfrizlab128 comments

I estimate that around 10% of my Feedback Assistant reports ever receive a reply or acknowledgement.

These are for reproducible bugs in iOS, for which I've provided an isolated sample project with a 100% reproduction rate. It takes time to create a thoughtful and detailed bug report and the lack of replies are beyond frustrating. I'm glad to see this post and couldn't agree more.

Fully agree. I work in security and sent Apple a bypass for child restriction policies on iOS, they told me to send it to feedback.

Testing, reproducing, writing it up all takes time and effort. I didn’t want anything from them other than for it to be fixed, I have kids with iPhones.

It’s no different than other companies though, I sent a remote code execution to Cisco and they just replied that they already knew about it but the product was approaching end of life so they wouldn’t fix it.

I’ve stumbled across so many vulnerabilities over the years and I tend to just ignore them unless I’m being paid to find them. It’s not worth the frustration.

To be fair, remote code execution and "I got around the child lock on this device" are somewhat different in severity.

> remote code execution and "I got around the child lock on this device" are somewhat different in severity

You’ll notice that the recipients of both reports responded similarly, with apathy. Perhaps that was the point of juxtaposing them?

> It’s no different than other companies though, I sent a remote code execution to Cisco and they just replied that they already knew about it but the product was approaching end of life so they wouldn’t fix it.

Huh? That sounds very different from Apple. In that instance, the communication is professional, mature, and respectful of your time and effort.

Same here. TBH I’m starting to get fed up by a lot of Apple things lately

Respectfully, why file them at all if that's the case? The cynic in me can't help but see that as free high-quality engineering labor for what's already the world's most valuable company. They don't need more help :)

I see a similar response rate as the poster you’re replying to, but I am going to keep filing bugs. If Apple fixes a bug I file, that’s not just to Apple’s benefit, it’s to my benefit and to the benefit of people who use my software as well. Even if they only fix 10% of what I file, it’s a better outcome than if I didn’t file any bugs at all.

I also notice that response and fix rates have large variance across components / teams within Apple. Some of them are quite responsive and others are just /dev/null. I do tend to focus my energy on those components where I’ve had success in the past.

This is also the stance I take on customer support of Apple products. It got hyped so much about "just working" that I take it as a bit of an insult that they want me to stand in for their CS team. I do make exceptions for close family.

You prefer fixing Windows computers?

No, you just train them to walk to the Apple shop instead of asking you. If you sell products at a premium with the promise of an excellent user experience, then you should also budget for the costs of actually providing that user experience.

Oh so it’s just the old ‘hurr durr Apple bad’ mantra with no alternative.

Wow, I'm impressed by your numbers. Because mine is 0%… :(

It's really disheartening when you try to file proper bug reports, with proper reproduction steps, my own investigative work and more details of it, etc. Then… silent. As if the app just outputs the bug to /dev/null or something.

Boycotts/strikes* only work if most or nearly all people participate, because you'll only participate if you're pretty sure nearly everyone else is too. While if this blogpost merely gets 0.1% of developers to strike... Apple couldn't care less.

I think this developer strike is a great idea, but launching it as a single person's call to action (Jeff Johnson's) is not generally going to be effective in changing behavior.

What an organizer needs to do is to first personally contact somewhere between 50-200 other major, known, respected developers and get them to co-sign a joint letter which then gets published, so everyone can see this is a serious strike by people who know what they're doing -- not just one person's wish. It needs to get covered in all the major tech publications, so both Apple and all developers see it as well.

And then the letter needes to not lay out a list of all of the complaints, but rather the specific, verifiable actions Apple needs to take in order to end the strike, so this isn't some open-ended thing. And they need to be realistic actions as well, not wishful thinking -- signs of progress with dates and milestones, not fix-all-the-things-immediately.

If you're going to do a strike, you need to actually organize it. Writing a blog post that merely "encourage[s] all Apple developers to join me" is not the same as organizing. And generally speaking, writing a blog post claiming that you're striking isn't going to get anybody else to magically organize it for you.

* As the author indicates lower in the article, it's more of a strike than a boycott since it's stopping providing free labor rather than stopping purchases, so I'll refer to it as a strike

Fundamentally, such a strike assumes Apple cares about the free reports they get from their developers. I'm not sure that's true. And even if it is, it's not like they don't have enough other reports or features to work on, so the loss of all outside bug reporting probably wouldn't affect them at all.

There might even be a middle manager that gets to say "external bug reports are 30% down YoY, our quality efforts worked out."

I'm already fairly well-known in the Apple developer community and received a lot of positive feedback on social media before posting the announcement, but I do think you're overestimating the amount of effort that I and other developers are willing to put into getting Feedback Assistant improved. This is not a fight for higher income or something of that obvious importance. The beauty of the strike is that steps 1-3 at the beginning are low effort from everyone, which allows everyone to easily join if they choose. As I said at the end of the article, one of the goals of the strike is to prove to ourselves that we don't really need Feedback Assistant, we've got little to lose, it's not essential to us that we participate in the bug reporting system, and we can just walk away. The strike is not a win-at-all-costs, fight-to-the-death scenario. Feedback Assistant, no matter how unrelentingly terrible and annoying, is or at least should be rather low on our list of professional priorities.

I think this attitude gives us leverage over Apple. We're only volunteers walking away from a crappy volunteering "opportunity", whereas Apple relies on our free labor for its commercial products and would have to actually hire additional staff and pay them in order to replace our QA work.

Might be worth having a public list of people who've "signed" your boycott, though.

I've considered that, but I have some concerns about the idea.

I'm worried about personally getting overwhelmed by emails and messages on social media. The more successful the boycott, the more I become swamped. :-)

Also, I think many developers have a fear of reprisal, whether that's empirically justified or not. My understanding is that there's now actually some degree of anonymity in Feedback Assistant, after changes were made in recent years for GDPR compliance? In any case, putting your name in public is a bigger step than simply boycotting, and I'm aiming for maximum participation. I've put my own name on this, and some cranks have even speculated that I might get kicked out of the developer program for it, which I doubt, because it would make me a martyr and kill my popular software — not to mention that dropping several 0days on Apple didn't get me kicked out — but I suppose that's always a possibility.

In general, I don't think that petitions are particularly useful. I'm more in favor of action (though in this specific case, the boycott is technically inaction).

If this gets you kicked out of the developer program, I think everyone would be quite upset, yes.

I think Apple will individually reply to the feedbacks with a PR message like "we take your concerns seriously, we have a plan to improve our feedback interaction." Because the replies are individual and posted on a private channel, people who joined the boycott will not have any wider visibility, and think "Oh maybe it's okay now" and go back to using it.

It might be worth establishing an official public dialog forum and discouraging people from individually communicating until a resolution is confirmed there in public. Right now it's on individuals to confirm that Apple improved things, which can only reasonbly be done by submitting more feedback (i.e. breaking the boycott).

I've personally stopped providing feedback via forms on cloud providers' websites due to similar unacknowledgement and general disinterest in improving developer experience, but haven't tried to organize anything about it.

> because you'll only participate if you're pretty sure nearly everyone else is too.

Definitely true for traditional paid labor, but this isn’t that.

Nobody is leaving their paycheck behind if they stop using Feedback Assistant. Since the costs to participating in this strike are very low (for most people, participating in the strike is probably a lower cost than not participating in it), I could see a path to building up to an impactful strike over time, in a way that’s not possible in a traditional labor dispute.

Sure Apple could be indifferent to a small percentage of people boycotting their process, but the Public Relations (PR) and Comms group is extremely averse to negative commentary. I'd imagine there are some emails flying around right now...

I hope something changes with the way apple manages bugs. It’s incredibly demoralizing to spend my time reproducing a bug, writing up the bug report I’d want to receive (including a minimal test case), and hearing nothing for years until it’s either closed or receiving a message asking me to do more work to determine if it’s still an issue.

Are there companies that do this well, at a scale approaching Apple’s?

I can think of lots of reasons why this is a “hard problem”, and how it’d be hard to staff. I also think they’re getting paid to solve this problem, and aren’t.

There's a fundamental problem that the first step is you doing all that work. That means there's no way to tell you the work is wasted; you already did it.

I generally think people should do /less/ work when reporting bugs because of this, but you should be careful and clear about what you do put in there.

Some of that work does benefit me: better understanding of the bug, verification that it’s not something I’m doing wrong, maybe some ideas of a workaround.

I’ve stopped doing the second phase: packaging it up and submitting it to apple, because that’s shown itself to be an entirely negative experience.

If apple’s not going to spend the $$ on internal QA, and they’re not going to spend the $$ on developer relations, I’m not especially interested in donating my time to help them. I know I’ve seen a similar sentiment from other developers for years.

I think low quality / low content bug reports are usually worse than none, because they decrease the signal to noise ratio of bugs. Maybe if there was a better channel of communication, and I knew it’d be more interactive it’d be different.

I got so fed up of all the Apple bugs I sold all my Apple stuff and bought a PC. At least I'm greeted with new and interesting bugs no one is going to close.

I sympathize: even filing radars internally at Apple gets much of the same treatment, albeit with the ability to see the state of the radar.

Yeah he's lamenting how poorly the external developers are being treated but seems like they are largely being treated the same as Apple treats its own employees

I found it sometimes frustrating as well. But my experience was that it depended on the engineer/team/screener the Radar went to. Obviously if it was a bug I found, I much preferred to talk to the engineer in person who maintained the code in question.

There were plenty of teams that were very good about jumping on bug reports and getting right back to me. In fact, a decade or so ago at Apple this was more or less the rule.

My sense though is that engineering became overwhelmed with bugs especially as Apple itself became as successful as it has become.

"In the old days" a smaller team would have one of the engineers on the team screen Radars — maybe rotating to a new engineer every week or so. Engineers could quickly mark a bug as a duplicate of another (recognizing a familiar backtrace or symptoms) or might be able to guess at a diagnosis and send it straight to the engineer in charge of the (likely) relevant code.

A few teams I worked on were very good about daily "BRB"s (bug review board meetings). With a number of engineers in attendance, again, bugs were quickly dispatched to the right component, assigned to right engineer.

Again though, as Apple grew, I saw bug screeners on many teams more or less automatically flipping Radars back to the Originator if there was not a litany of documentation attached to the Radar. What build of the OS, what hardware, a full sample, system diagnosis.... It was frustrating when it was an obvious bug — maybe even a UI bug — that would take someone all of 30 seconds to repro. I somewhat sympathize though as traffic no doubt began to become a firehose of bug reports.

It seemed backwards to me though to put such a burden on the person who is simply trying to report the bug, trying to help you improve the software. Often in screening Radars the description alone was enough for me to know exactly where in the code the problem was. I didn't mind my time being spent at least scanning the Radar title and description. If it was not clear to me at that point, sure, flip it back for more info. The seeming rise of "auto-reject" is what began to irk me.

What would the ideal structure look like in your opinion?

Ideally, daily BRBs (kept to an hour) with engineers attending.

If it turns out there are too many Radars to keep the BRBs to an hour then there are issues elsewhere.

At the same time, I didn't mention it above, engineers need to be allowed time in the product schedule to fix these bugs. As probably everyone knows, when a bug is kicked down the road once (because of scheduling constraints: hey, we gotta ship the software at some point!) it becomes easier still to kick it down the road when the next release dat rolls around (we lived with the bug this long...).

I think engineers and users alike would love to see more bug--only releases of MacOS and iOS. People still talk about how wonderful SnowLeopard was simply because it was a bug-fix only (mostly?) release.

Incentivize screening Radars (and fixing them). There's no engineering glory in keeping your unscreened count at zero... nobody gets promoted for it.

Good point.

Not everybody wants to get promoted

  I think engineers and users alike would love to see more bug--only
  releases of MacOS and iOS. People still talk about how wonderful Snow
  Leopard was simply because it was a bug-fix only (mostly?) release.

Apple's dot zero OSX releases have always been pretty bad, so yes Snow Leopard and the last iteration of Tiger look great by comparison. As an outsider I don't have fond memories of filing bugs with Apple in that era. The general opacity combined with corporate disinterest discouraged me to the point where it's been years since I've even thought about filing a bug.

I dread new iOS releases. Sure there are usually unwanted changes (e.g. text selection in iOS 13), but the bugs... iOS 16 completely trashed whatever database Siri uses to map text to speech, so using Siri to play a song is usually a miss. Most recently it's decided the name Ben is really the name "Mouse Face". That's left a fair bit of egg on my face as I interact with those two people in two very different contexts. Sure, I could file a bug, but it's just easier to stop using Siri (which was never great in the first place).

With Tiger I was trying to integrate LDAP (AD masquerading as OpenDirectory), and it turned out that OSX would just assign GID 0 to any LDAP backed user. To me that seems pretty fucking straightforward, obviously pretty severe. That bug report went nowhere (not even an acknowledgement) and if memory serves Leopard went out with the same issue.

I also had a polycarbonate MacBook for personal use around the same time. I ended up filling out the RAM slots and discovered that after a certain amount of uptime that playing DVDs would eventually cause a kernel panic. That bug report actually did get a response, but only one. I think the computer itself died before that got fixed.

As someone who went on to dick around with CalDAV and CardDAV, there were plenty of issues to be filed but it was never really worth the effort. But as with everything else, as bad as Apple is they're usually better than the competition. That's how I ended up replacing my recently deceased Intel MBP with a new ARM one.

So long as market share holds I don't think Apple's got much incentive to reform. Although given that Tim Apple seems hell bent on pulling a Gil Amelio (my new MacBook SuperproairMax 15.323456" with the all new M-Centris really truly pro max upper bound superlative CPU sure looks great on the shelf) who knows how much longer that'll hold.

I was on the team that owned CalDAV and CardDAV in approximately that era, as a bug screener and with zero decision making power.

The attitude was basically, if it doesn't affect us personally working inside Apple, we don't care. If our personal workflow and servers doesn't use those features (which I guess is the case for GID), it doesn't matter.

We don't know what Exchange is or why anyone would use a Microsoft product. What are they, idiots? We don't really care about Gmail. Why is their server not responding according to RFC Whatever? Google must be idiots.

Etc.

There were a very few number of developers, most were wasting their time making fake leather stitching for the UI because Jobs demanded it. Unit testing was quite poor. Code review was nonexistent.

I should probably clarify: the DVD bug was related to playing DVDs on a Mac with Intel graphics and 4 GB of RAM. Certainly it's an odd edge case but it spoke volumes about the quality control with the drivers. Maxing out the RAM on one of those can't have been such a rare thing. Certainly I can wrap my head around why calendaring and enterprise features didn't get much love, but video drivers on the mass market product? Jesus.

With the calendaring stuff: I wrote a CardDAV server that's probably still lurking around on Github somewhere. The workarounds I had to implement for MacOS and iOS clients were beyond pale. For instance stuff would just get cached indefinitely and trailing slashes caused OSX to have a conniption fit. If you told me that the client implementations just hardcoded a bunch of stuff so it worked for Steve Jobs (and that nobody else used it) I'd believe you.

Eventually I did a brief stint at a consultant that was brought on to do some infra stuff for Apple, and that didn't do much to improve my impression. We got a bunch of servers from the basement with expired iLO licenses, and boy were we lucky to get that much.

  The attitude was basically, if it doesn't affect us personally working inside Apple,
  we don't care. If our personal workflow and servers doesn't use those features (which
  I guess is the case for GID), it doesn't matter.

Honestly I'm not sure how to respond to this. If memory serves there was no way to uncouple group mapping, so this was part and parcel of Apple's push into the enterprise space (and in this case AD was behaving as an OpenDirectory server would've). Which is to say, their failure in that space was entirely a self-fulfilling prophecy. The more frustrating part was that an obvious security flaw was treated with such disdain, which encouraged me to stop caring about filing bug report with Apple (and it's lead me to keep the bluetooth modem off almost exclusively on my iPhone).

That gig was actually mostly staffed with Apple alumni so there were 1st gen iPhones all around. Even the less esoteric stuff was simply not good. Obviously voice quality was shit (at least in San Francisco) compared to the CDMA feature phones of the day. One of the coworkers there worked on the mobile Mail.app before bailing for startup life. Autocomplete was a mess. Honestly, I rather enjoyed rubbing some salt into that wound.

What amazes me is that fifteen years on and Microsoft is still somehow worse (what with Windows being adware and all).

When I was there on the BRBs I often dreamed of actually commissioning a neon *NMOS* sign that I would flash by pressing a button for nearly every bug that came up for discussion.

>People still talk about how wonderful SnowLeopard was simply because it was a bug-fix only (mostly?) release.

I think that was part marketing, snow leopard brought pretty sweeping architectural/internal changes: ARC, GCD, 64-bit kernel, so it definitely wasn't a pure bugfix release.

Don’t they autonomously analyze a crash report’s stack trace and group them together?

As for feedback.. if someone had a dev account or is linked to it, they should be flagged as more detailed/investigated

Yes, if there's a stack trace attached. That is kind of cool though — they also bucket them by OS release so you can see quickly when a bug first appeared (or, well, a similar stack trace appeared anyway). Also they rank them on frequency so it is easy to find your component's "Top Crasher".

Then I have no idea why my consistent kernel panics are not addressed since the last few releases (major and minor).

Sad but probably true. I imagine Apple can afford to do better and it would pay off both internally and externally.

Which basically mean they’re understaffed with people who enjoy fixing bugs. Fixing bugs, fine tuning, just gardening the code base

Or it's too annoying to triage, find (If app store search is anything to judge by) and replicate bugs because the tooling is too annoying or not collecting the right information if people submit bugs. If that's the case then even if you would in theory have the resources to work on bugs it will not be very efficient.

I think a lot of Apple engineers would love to have more time to be able to fix bugs but for the most part they're all stretched pretty thin.

Prioritizing fixing old bugs over developing new features isn't a call an IC can really make so I'd kinda argue that the issue is either "overstaffed with designers+execs who spend engineer time on UI changes" or "understaffed with engineers in general" and not an issue with the mindset of the current engineers.

Actions speak louder than words - Apple is letting it's developers know what it thinks of them. You're going to have to raise quite the ruckus to get them to change their behavior. There's really no impetus for them to change when they're sitting on a mountain of cash.

I never thought I'd wistfully look back on Steve Ballmer yelling DEVELOPERS! DEVELOPERS! DEVELOPERS!!!

Apple seem to view external developers as a kind of infestation. The systems and processes they subject them to seem designed to actively discourage them.

Stockholm syndrome with a hint of masochism. App developers seem to stick with apple regardless of what they are being subjected to.

When the bank robbers share their loot with the hostages, Stockholm Syndrome can't be too surprising.

> App developers seem to stick with apple regardless of what they are being subjected to.

Because the alternatives aren’t preferable. The indies who have been exclusively using and developing for Apple platforms for years know that Windows and Linux aren’t better¹, just a different set of annoying trade offs. Apple platforms aren’t perfect, but they are the least bad option in that context. They also used to be better in many regards, which makes the situation frustrating due to the wasted potential.

¹ At a personal preference level. There’s no judgement either way, you do you and use whatever you like best.

For my money, the thing that stops me from dailying a Mac again is the amount of trust Apple demands from you nowadays. Older Macs are really cozy, even up through Yosemite in my opinion. After a certain point though, you could feel the focus shift from onboard utility to metered service. iTunes became Apple Music, the black "AppleTV" logo popped up on my dock, and iCloud pitched a tent in my Settings menu to beg for change. None of this really appeals to me; it's engineered to make the common user happy for a nominal fee, but to everyone else it's just annoying. Little UX warts like that popped up all over MacOS, and it really started to evoke those "Windows 8 Armageddon" vibes I felt a while back.

For Apple to correct course, they should ditch the ads and focus on superpowering MacOS and iOS. Right now it's hard for me to trust that Apple is giving me the best of all worlds.

It's the same with users as well, the keyboard of my iPhone's wife is freezing randomly during 3s but she still puts up with it and will not say a word against it.

I gave up on mine personally after the app installs were impossible due to some modal error in loops.

I'm not sure how they managed to do it but they are very strong on the marketing side, I'll admit that.

To be fair, the app store is already infested with apps and ad networks that push deceptive alerts that attempt to mislead users into installing unwanted/unneeded apps.

I always find it funny to see Apple pushing for tech education when it's well known that Apple despises developers. Please teach your kids computer science so we can treat them like shit and/or exploit them!

They used to (or still do?) have coding courses for kids at Apple stores, they have free learn to code resources (https://developer.apple.com/learn/), probably some more programs I'm not familiar with.

I never understood why Ballmer took so much flack for that. Which platform would you rather write code for, the one one with a sweaty representative going on about how much the company loves the people who write code for their platform, or the one that doesn't even try to conceal its contempt for you, the developer?

Dear Board,

I don’t want to belong to any club that would have me as a member.

Sincerely yours, Groucho Marx.

Previously: https://news.ycombinator.com/item?id=3947903

(I feel incredibly old right now.)

Edited to add: Finally found the full form letter [1]. (I filed a copy back then and it still shows up languishing in Feedback Assistant even now!)

[1]: https://gist.github.com/mysteriouspants/1989061

Reporting bugs via feedback assistant is sometimes required when you've successfully found a developer inside Apple who has agreed to fix your bug and they just need the feedback number for internal work reporting purposes. Submitting unsolicited bug reports are just a pointless waste of time. I wouldn't say I'm specifically "boycotting" Feedback Assistant; I just stopped using it because it wasn't doing anything useful.

How are you supposed to find a developer inside Apple to fix your issue?

Maybe HN or LinkedIn, lol

As with all modern tech support: complain loudly on Twitter/X and hope the issue gets enough traction that somebody notices.

It is possible to backchannel to them like any other company. It's just much less... publicly evident, if that makes sense?

Also (IIRC) if you post on their dev forums and deal with e.g Quinn, they might ask you to file and provide a radar - but it's been a minute since I've interacted over there.

That guy Quinn "The Eskimo" seems to have been almost singlehandedly manning the developer forums at Apple for over a decade. I hope Apple recognises how valuable he is.

Yeah, he kind of seems like the only guy who cares as someone looking from the outside. There are a lot of technology details where you need to dig up some random Apple Developer forum post from him just because Apple sucks at documenting some of their technology.

A few are active on Mastodon actually

Before that it would be you'd ambush them at WWDC with your list of bugs

As a developer, I flatly refuse to engage with Apple in any way because of their $100 annual fee.

I feel especially vindicated when stuff like this surfaces.

Imagine being the richest company in the world and having the audacity to charge people for the privilege of being able to contribute to your platform.

It is absolutely insane, and nothing will convince me otherwise.

while i agree with your sentiment, i think Apple would probably argue that they're actually charging for access to their distribution network.

They are charging for the access to their "walled city/garden", they are promoting digital feudalism and the worst part is that other companies see them as exemplary for these terrible practices.

Yes and no. If you are making a macOS app and want to distribute your own binary (meaning not via the App Store), you are basically doing everything yourself and not using Apple's network. You still have to get a developer account because that's how you 1) get a valid developer signature, and 2) get access to app notarization service. Both 1 and 2 are now mandatory unless you force your users to jump through a lot of security hoops to open your app.

I maintain an open source macOS software and begrudgingly signed up for a developer account since I didn't want my users to have to suffer through the security settings screen. At least I got a donation program up a few years later so at least I'm not paying out of pocket anymore. Some of my peers/competitors (open source text editors) are still not signing their app (since they didn't feel like getting this sorted out) forcing users to have to go through the security settings which I think is a crappy situation.

One reason they are charging is to weed out bad actors or people not serious enough about publishing apps on their stores. That said they could do this as a one off like Google, and make it cheaper too.

Wait, you can’t file feedback from the web anymore? That’s incredibly stupid. Their feedback app itself breaks half the time, so I guess they wouldn’t be getting my reports then even if they wanted them.

https://www.apple.com/feedback/

If reporting feedback using Feedback Assistant is akin to shouting into the void, using that site is like doing that but in the vacuum of space.

I can't speak for its efficacy, just it's existence.

I'm not sure what that is about, https://feedbackassistant.apple.com

I previously blogged about how Apple treat web developers with negligence when it comes to Safari [1]. This makes it looks like Apple treat other developers with negligence as well, which is unsurprising, frankly.

[1] https://www.construct.net/en/blogs/ashleys-blog-2/safari-rel...

I solved this by basically treating the browser as legacy and "best effort", similarly as IE11 in its days.

They have a very large number of basic features broken regularly, it's not only about cutting edge stuff. I suspect their testing practices are less than stellar.

Yep, we've ended up on the same idea - we make a best effort to keep it working and if we can't we advise to switch to another browser. But tough luck on iOS, as other browser engines are banned...

It's going to be controversial but iPhone users are going to have an inferior web experience no matter what, at some point we have to say it even if it's not popular. The core business of Apple is in the apps.

I stopped filing Apple bugs ("rdar") ten years ago.

It was pitching a lot of work into a hole: totally opaque.

The recent macOS dialog "Allow app to access folder [OK] [Cancel]" supports button cycling by Shift+Tab (previous), but not Tab (next). The Wi-Fi signal strength indication changes when clicking it. So yeah, at least they need to admit things are very bad over there.

Whenever I see or hear about keyboard shortcuts being weird or not working, for some reason I can only think of Catalyst or Electron, both bringing frustratingly poor user experiences. Apple’s own Catalyst based apps (Reminders, as an example) have been terrible over the last few years. I can’t imagine a macOS dialog being either one of these abominations though, which makes me wonder how the issue you describe was introduced.

They still seem to have issues from the Carbon to Cocoa transition 20 years ago, like my favourite: apps don't remember their keyboard language.

Apple's solution for missing Catalyst functionality has been to create analogous features or port existing API to iPad.

That said - the long-term strategy doesn't appear to be Catalyst, but Swift UI.

these arent the heavy HN apple blinders these threads usually get!

but yea its pretty bad. i cant go 1 day without a blatant ui bug lightly using apple products at work

I'm in. Apple Feedback Assistant is absolutely useless.

[pirate voice] all right, all right, you talkd me into it (parrot squawk)

Someone please set up a website that can compose an email to Craig Federighi with these issues and let developers email him directly. Apple may not act on or respond to this collective Feedback Assistant feedbacks, since the system may probably be broken to the extent that Apple’s teams don’t even see or get these feedback reports.

> Someone please set up a website that can compose an email to […]

We do not need a website for that.

Simply send an email to Craig Federighi or even Tim Cook.

You can find their email addresses here → https://news.ycombinator.com/item?id=27320383

Federighi replied with a suggestion to fix my issue. It didn't work, but it was cool anyway.

My experience talking to brick walls has been more productive.

What would happen if some Apple developers moved their collective feedback to a Github repo where their bug reports were licensed as CC-BY-4.0, i.e. a license that would allow Apple to migrate content from the public repo to their internal radar? This would allow developers to have a public database of de-duped and triaged bugs, and it would allow Apple to either respond publicly (same as Webkit?) or maintain status quo.

Nothing would happen. Websites and GitHub repos for posting Apple bug reports publicly have existed for over a decade.

https://openradar.appspot.com/

I'm aware of an open collection of Apple Feedback Assistant reports on GitHub - https://github.com/feedback-assistant/reports/issues

> Apple Feedback Assistant reports are not public. To help other developers discover existing reports, copy-paste your submitted Feedback Assistant report into a new issue. Make sure you include everything.

> This is similar to Open Radar, but it's easier to fill out the report and GitHub has better search. Also, Open Radar doesn't yet support Feedback Assistant.

> Instead of voting on issues opened here (which Apple won't see anyway), file a new Feedback Assistant report and copy-paste the contents of the report you found here and link to the original report. Apple encourages duplicates.

> have existed for over a decade

   Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!

Those look like a public mirror of some Radars filed at Apple, i.e. Apple already has that information. If enough developers stop submitting feedback (topic of this HN thread) and start posting bugs into a public repo FIRST, with a CC-BY-4.0 license allowing Apple to mirror the public bugs, then a boycott would have the positive side effect of showing-by-example how the feedback process could be improved.

> nothing would happen

As a counterpoint, there is a public Bugzilla for Webkit bugs, where the keyword "InRadar" indicates whether the bug has been mirrored to Apple's internal bug reporting system. If enough developers boycott Apple Feedback, could they use a Bugzilla instance for iOS and macOS bug reporting? If enough Apple users start referencing Bugzilla URLs for iOS/macOS production issues and purchasing decisions, could that influence Apple?

https://bugs.webkit.org/buglist.cgi?bug_status=__open__&cont...

You mean something like this https://github.com/feedback-assistant/reports ?

That is yet another public mirror of private Apple feedback reports. The suggestion is a public Bugzilla of iOS/macOS bug reports, similar to Webkit, that could be selectively mirrored by Apple to private radars, https://news.ycombinator.com/item?id=38166908

Apple’s customer support as a whole is atrocious. Here in the uk their milton keynes apple store is essentially a cesspit of cockiness and upselling rudeness. Filed a complaint against an employee and have yet to receive any feedback two months later. The only apple product in my life is now an iphone, but that will be phased out too. Good riddance. Open source all the way.

I'm not sure I understand this. Wouldn't developers who need code-level assistance (i.e. have more than simple "feedback") submit a Technical Support Incident (https://developer.apple.com/support/technical/)?

Developers use feedback to file bugs. Why would they spend money to get help from Apple on how to do that?

"developers are a profit center" is your answer

> Developers use feedback to file bugs.

Yes, and they're specifically instructed to file TSIs if they need a workaround in the meantime. https://developer.apple.com/bug-reporting/

Should developers not have to do both? Sure. Should they ignore Apple's instructions and still expect to get help? Not sure.

From experience, I have used a TSI when I need help with a bug in Apple's products. Every single time (about 5x) they "refunded" the TSI because it was an Apple bug. I have never had to pay for extra TSIs -- I use the ones that come with my developer account and (so far) they are always refunded. I don't know why people hoard them -- they are use it or lose it every year.

I have also gone to a virtual dev lab during WWDC which was awesome. Lots of "free" help from an Apple engineer (basically 30 minute speed run of lot of questions about Apple Watch workout app development).

I have mixed experience with Feedbacks. I have filed dozens that I actually care about and maybe 10% were a decent experience. The rest were essentially ignored.

I filed a TSI earlier this year. It look them six months to reply, and even then it was to ask for information that had already been given in the original report. By then I had already figured out what was causing my problem and found a workaround. Still, I thanked the developer for their time, described my approach and asked if there were a less hacky way to do it. I never got a reply.

Read the post - it's about bug reporting, not assistance with code or simple feedback.

The feedback assistant is primarily for reporting bugs. Bugs that impact developers.

Reading the post is how I learned the developer didn't file Technical Support Incidents (TSIs).

Almost every time, developer technical support will look at the internal bug and if there is no known workaround will say “sorry that’s our bug and engineering is investigating, we don’t have anything to tell you, please keep an eye on the feedback and we will update you if anything changes - in the meantime here’s your TSI refunded”.

Ooof. That’s a terrible experience, thank you for sharing.

In that process though, you’ve had someone at Apple verify that your issue is legitimate, and that issue has probably shown up in a place they care about (DTS metrics)

Two things that simply filing a feedback issue doesn’t seem to reliably do.

I’m suspect a concerted effort to get developers using their TSIs for bug reporting would backfire (stop refunding them? remove the program?), but I think it’s an interesting idea given how cheap the TSIs are for developers.

Sure and I don’t mean to minimise the value/effort - I’m sure the “look at” may involve actually investigating the issue themselves by looking at the implementation, speaking with the responsible engineers, etc. I am also sure it is a hard problem to solve - while Apple is massive and well resourced these days their developer community is also humongous and I am sure there is a tremendous amount of noise. But my point is merely - TSIs are not a panacea

Here's an excerpt from the reply that I get from filing a TSI for functionality that is ultimately a bug with iOS.

------------

Hello,

Thank you for contacting Apple Developer Technical Support (DTS).

We believe this issue is a bug. Please file a bug report via Feedback Assistant (https://feedbackassistant.apple.com). For more information on Feedback Assistant, visit https://developer.apple.com/bug-reporting.

------------

From here, typically the Feedback Assistant bug report will remain open. For years. With no acknowledgement.

I would happily pay Apple a developer rate to fix these bugs. Some of them are massive showstoppers in a large scale production application.

> I would happily pay Apple a developer rate to fix these bugs. Some of them are massive showstoppers in a large scale production application.

Wow that's pretty intense. Any examples of such show-stopping bugs?

Here's a few recent ones:

1. Xcode 15's "Replace Container" feature replaces the app container with incorrect permissions that results in the app not being able to write to its container (ex. the documents directory). This is an important feature for debugging and flat out doesn't work.

2. Apple's AVPlayer has an API called MTAudioProcessingTap which allows you to get access to low level audio data. Since iOS 17.1, it is not possible to have more than one MTAudioProcessingTap running at the same time.

3. AVPlayer's `addPeriodicTimeObserverForInterval` function will randomly stop calling back to its observer, and never recover, when connected to an Apple TV via AirPlay on iOS 17.

Issue 1 makes debugging more arduous. Issue 2 stops my app from being able to crossfade audio together or play more than one audio stream at once. Issue 3 requires me to build my own time observer which is further technical debt, versus being able to rely on Apple's API.

I've spent hours debugging each of these and trying to find a workaround before resigning myself that it's a platform issue and relegating myself to abandoning that specific API or feature.

> Issue 3 requires me to build my own time observer which is further technical debt, versus being able to rely on Apple's API.

IMHO, it's the same amount of technical debt, regardless of who built it. In this case, the overall situation is worse: because you didn't build it, you can't fix it. If you have a dependency built by a benevolent provider, that may mean less work for you in the future, but it's still technical debt.

I think it's safe to say that Apple doesn't care about any individual developer unless they are large enough (i.e. Adobe) to move the needle. If developers really wanted to get Apple's attention, they wouldn't boycott Feedback Assistant, they'd boycott the App Stores. If enough developers pull their apps off the market it would move the needle and Apple would have to pay attention.

Also their feedback assistant is buggy as hell.

If you managed to create draft in old version (before random code change).

But it does not match with new version your feedback assistant crashes to blank screen. (JSON parse syntax error)

That means it is impossible to file new bugs...

1 second web page works but after that it is blank screen and nothing to do.

I am sick of everybody asking for feedback everywhere, and nobody wants to spend any human effort looking at the feedback.

And the worst of it is the "Do you love our app?" dark pattern.

I've run into many of the problems mentioned with Apple Feedback and gave up on using them many years ago. It's pretty disheartening when you spend a bunch of time getting an OS crashing bug to reproduce in a small amount of code to submit in a bug report for them to neither confirm that they can repeat it, or consider it worth fixing.

Some minor product manager in Cupertino, two quarters from now: "As we can see in this graph, thanks to the improvements to Feedback Assistant over the past couple years, we've reduced our products' bug rate to nearly zero percent!"

I like when HN holds the fire to these kinds of issues/companies. Its almost like us nerds have some kind of fancy communication system/technology or something [dunno shrug]

Let’s see if there will be Bug as a Service. Pay for bug fix in addition of $99/year

IMO it's optimistic to assume Apple can fix this

I suppose Feedback Assistant is like Windows' Feedback Hub. Users fill it to the top with shit making it impossible for Apple or Microsoft to do anything useful with the feedback.

Do users even use Feedback Assistant? I have yet to hear of anyone in my circle (friends, family, coworkers) submit a Feedback. None of them are developers or us the developer beta of iOS, so I have always surmised that to be why.

The app is installed but hidden by default unless you’re running a beta (and in my experience I’ve never gotten a reply to a report unless it’s on a beta). You can use the website or launch the native app with its URI scheme but approximately nobody does that unless they’re really frustrated with a bug and know Feedback Assistant exists.

It's not clear from reading this if "Apple developers" are developers who work for Apple, or developers who write software for Apple systems.

Reply on news.ycombinator.com