{"id":34862,"date":"2022-01-31T16:06:05","date_gmt":"2022-01-31T21:06:05","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=34862"},"modified":"2022-04-05T14:50:40","modified_gmt":"2022-04-05T18:50:40","slug":"getting-feedback-to-apple","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/01\/31\/getting-feedback-to-apple\/","title":{"rendered":"Getting Feedback to Apple"},"content":{"rendered":"

Becky Hansmeyer<\/a>:<\/p>\n

\n

Reflecting on the whole iCloud kerfuffle, I think one major issue is that none of us know how to escalate a critical problem to the right person. Support folks usually lack an understanding of the context, the dev forums aren’t monitored, and radars are likely backlogged.<\/p>\n

There’s a reason so many developers on Twitter include feedback\/radar numbers in their tweets: they are more likely to reach the correct person\/team here on Twitter. So, we find that problems tend to start on Stack Overflow\/dev forums, then bubble up through Twitter —> media.<\/p>\n

What’s the solution to this? Apple has already created successful Q&A environments where participants are heard, understood, and given feedback: the Swift evolution forums, and the WWDC Digital Lounges.<\/p>\n

I realize it’s hard to scale that to a system that is: open year-round, and includes narrow access to someone from every single framework team. But something or someone has to act as a better switchboard: a “sure, let me transfer you to the SwiftUI department.”<\/p>\n

As of right now, it is an absolute fact that Twitter is a developer’s best avenue for getting a bug fixed: IF they can get their tweet in front of an Apple engineer, either by having a large following or being retweeted by someone with a large following.<\/p>\n<\/blockquote>\n\n

Alex Rosenberg<\/a>:<\/p>\n

\n

Iff you had actual Radar access and iff you knew the component that they use to actually track operational issues with iCloud, then it would be 💯% effective. However, the culture is broken by secrecy and nobody outside that org would know or be able to see the correct component.<\/p>\n<\/blockquote>\n\n

Matthew Cassinelli<\/a>:<\/p>\n

\n

Yes. I know every specific bug for Shortcuts but to communicate them to my old team feels like harassing them and not actually being a friend.<\/p>\n

It’d also take me 8 hours straight of filing radars for free for things that have been clearly broken for years<\/p>\n<\/blockquote>\n\n

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

\n

What does seem to work in situations like these IS to run to the press. I’ve seen issues from before I started seeing it reported on various sites. And when it cropped up on one tech site, all of a sudden it’s everywhere. Boom. Problem fixed in like a week?<\/p>\n<\/blockquote>\n\n

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

\n

I’ve currently used a Code Level Incident to get some extra eyes on FileProvider-integration, because the documentation is from 2017 (WWDC video + slides and not complete) and it’s buggy on a few sides.<\/p>\n<\/blockquote>\n\n

My experience is that you can pay DTS to confirm that a bug is in Apple’s code rather than yours. Sometimes they will have a workaround to offer you. You can give them a bug number to associate with your case, but I can’t say that this seems to escalate the bug and lead to it being fixed any faster.<\/p>\n\n

Dave B<\/a>:<\/p>\n

\n

Tim Cook isn’t a product guy like Steve was. He doesn’t have hands-on knowledge or insight into the products. He’s an incredible businessman but not a product guy.<\/p>\n

That’s why when there’s a problem with a product, people have to let him know so that he passes it down the chain to fix it.<\/p>\n

[…]<\/p>\n

The best way to call attention to these kinds of issues is to bring them to popular figures in the Apple community.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n