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.
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 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.
> 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.
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.
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.
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.
The advent of sports betting has become so fatiguing. It's impossible to watch a football game without back to back to back betting commercials. Announcers pre-game talking about odds, over-unders, etc. I can't help but feel like the chickens are going to come home to roost.
I've had a bunch of friends that went from never gambling to spending a few hundred dollars per Sunday placing random bets. All destined to lose eventually due to the insane 10-15% vig (ie. a coin flip is priced at -110 or -115).
The few friends (sharps) that I had that were able to earn a profit over a large enough sample were all eventually backed off by the major sports betting sites. One site backed off a large long term winner in order to "protect the player against creating a compulsive habit or addiction". It's literally a racket. You can't win long term. You can only lose.
> The few friends (sharps) that I had that were able to earn a profit over a large enough sample were all eventually backed off by the major sports betting sites. One site backed off a large long term winner in order to "protect the player against creating a compulsive habit or addiction". It's literally a racket. You can't win long term. You can only lose.
That's incredible, so these sites track gamblers and figure out which ones actually know what they are doing and then refuse their bets?
I push telemetry to Amazon CloudWatch (my infrastructure is on AWS) and then setup alarms accordingly. If I'm concerned about a service failing or becoming unresponsive, it's easy to create an alarm based on the existence or non-existence of data.
Hard to really say without having more details about your app and its user base. Personally speaking, having my content interrupted by some sort of audio ad, even by the content creator, is 100x worse than ad banners or other visual ad content.
You can move a custom domain easily enough. I am about to do that to move away for the GSuite’s fees. Worst case, I’ll invest into running a service on my own. Best case, I’ll just use Proton or FastMail, etc.
I guess registrars can go down too but it seems less likely.
It increases cognitive load when writing the function call, since you now need to remember what kind of true to use. It also increases cognitive load for people who either do already understand the parameters or who are doing something for which the parameters are not relevant; it's harder to ignore a long thing than to ignore a plain "true".
> It increases cognitive load when writing the function call, since you now need to remember what kind of true to use.
There is no "kind of true".
> It also increases cognitive load for people who either do already understand the parameters
By letting them see what the parameter they remember is? There's no cognitive load to seeing what you expect.
> or who are doing something for which the parameters are not relevant;
If the language doesn't have optional parameters, all parameters are relevant. By making parameters named, you avoid having to count positional parameters as in MS APIs to ensure you didn't get one in the wrong slot.
> it's harder to ignore a long thing than to ignore a plain "true".
Which is very much valuable. It's much easier to notice mistakes than when you've got 11 positional parameters of which 2/3rds are usually set to 0/null.
As ridiculous as it sounds, have you considered adding report functionality to the other (non-UGC) content in the app? It seems like the review team isn't budging with your current argument so it may be worthwhile to add report functionality (even if the actual reporting is basically a no-op) just to appease them.
Heck, even feature flag it and disable it once the app gets in. Probably won't be flagged again in subsequent reviews.
Thanks for linking these. What a fun read. The first few years of the App Store always seemed like the golden age. Users had no idea what these devices could do and were so eager to download and try new things, which fuelled some awesome indie creations.
------------
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.