My experience with Technical Support - Total Disappointment

Recently, our team bumped into a crash that we cannot resolve. We looked for help everywhere. I asked people here on forums, team asked about 10 fellow developers and the question on SO was created. Nobody knows the reason for the crash, nobody can find a workaround. So, as the last resort, I called for Apple Technical Support (aka code-level support). I assumed that people there understand how things work under the hood. Considering that this service is limited (2 TSI per year, otherwise paid), I expected the quality to be high. In fact, it didn't help us to resolve the problem, and I was disappointed how irrelevant the provided support could be. TLDR: The dev didn't even open the test project!

I described the memory crash with WidgetKit-based complication. I spend my time capturing video, finding watch logs on my iPhone and creating a sample project. I attached console output, stack traces and a couple of screenshots. I even provided a .watchface file, so they can reproduce the configuration. This together took about 6-8 hours of work. I explained what happens in detail: steps to reproduce, what I've tried. I asked the support to recommend me way to present only the specified complications.

Then I submitted the issue and started to wait. It took them 1 week to responsd. I pointed my sight on the email with excitement, expecting to finally get the resolution. But what I found there was disappointing. The software engineer, Rico, quoted only a couple of sentences from my list. His letter contained only 4 lines of text (not including greetings and cheers).

  1. In the first line he recommended to use preprocessor macro to enable only necessary complications, which is nonsense. Of course we need to change complications dynamically, when the user selects them.
  2. I two next lines he recommends to use if statement in WidgetBundle to dynamically unlock the complications. I already knew that it isn't possible. Because, quote: "if statements in a WidgetBundleBuilder can only be used with #available clauses"
@available(*, unavailable, message: "if statements in a WidgetBundleBuilder can only be used with #available clauses")
    public static func buildOptional<W>(_ widget: W?) where W : Widget
  1. The last line cancelled everything before, Rico said that this can't be done at runtime. Probably, he added that after reading the documentation, but forgot to edit his previous statements.

I didn't give up completely. I decided to skip the design discussions and get the info that Rico could probably have, due to his access to the software. Why the extension using so much memory? I also asked him, if he was able to build the project and reproduce the bug.

Another week passed. I'm sending a follow-up message. That worked, after another 3 days I got the response:

  1. Finally some useful information! Timeline and views are being archived to disk (all simultaneously), that's why the memory usage is so high. Basically, a widget design issue. But anyway, we have what we have.
  2. Then next line, he has written this: "Complications are deprecated". What? But wait, he thinks that we use ClockKit, and recommends migrating to WidgetKit. So Rico completely forgot that we discussed WidgetBundle and SwiftUI before 🤡
  3. He honestly tells me that he didn't open the project. Why? Because "Complications are unlikely to be supported", he says. So he "forgot" WidgetKit on intention, this gave him an excuse to ignore the sample project. My time was invested for nothing!

I believe there's no need in further conversation with Rico. I will provide the detailed feedback to the Apple. And I'm posting it publicly to make sure that Rico gets the attention he deserves.

If you want to know more technical details about the issue, you can check the following links:

https://stackoverflow.com/q/77855303/1746142

https://developer.apple.com/forums/thread/744726

Post not yet marked as solved Up vote post of kelin Down vote post of kelin
319 views

Replies

I've found this type of thing to be the norm with filing Feedbacks as well. IF (and that's a freaking huge if), you get any kind of response at all, it quickly becomes clear that whoever is looking at the issue never bothered to try the sample project and half the time seems like they are responding to a completely different problem. And that's if you don't end up with the generic response that tells you to re-verify if the bug still exists and attach a SysDiagnose. That last one manages to combine being impersonal, dismissive, and lazy all rolled up into one. It's kind of impressive in a weird way. Infuriating and unhelpful, but impressive nonetheless.

In this past major OS release cycle, after weeks of hearing nothing on several reported bugs that are critical to our product, we opened a developer technical support instance in hopes of raising the visibility or at least coming up with a decent workaround. Literally a month went by with no response. In years prior, we'd hear back in a day or two on DTS requests. When I tried to follow up, they just said they were busy. Long story short, the bugs still exist (we've still heard nothing on the Feedbacks – no surprise) and we had to spend a considerable amount of time and effort on workarounds.

Frustratingly enough, this is happening again with Catalyst in the betas of macOS 14.4. Apple can say they care about bugs all they want. Their actions and the entire Feedback systems says otherwise.