Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why iOS 13 and Catalina Are So Buggy

tidbits.com

Post reply on HN
Print view View original

101–110 of 368 posts

Re: Why iOS 13 and Catalina Are So Buggy

#101

Post by hinkley »

alwillis wrote: post #36
threeseed wrote: post #19

Every .0 release for iOS and OSX has been buggy. Every single one. And then a few point releases later and it's all forgotten. And then the next .0 release arrives and the blog posts reappear.

Every .0 release for iOS and OSX has been buggy. Every single one. I've run and tested every release going back to 2001 and it's been a while since a macOS release has been this buggy and caused serious data loss in some cases. So even for .0 release, this has been pretty bad.

Have you forgotten about the release that melted hardware?

Melted.

Re: Why iOS 13 and Catalina Are So Buggy

#102

Post by babesh »

I have been told by multiple sources that Apple engineering salaries are not competitive with industry leaders and haven't been for a long time. I wonder if the dissolution of the Jobs anti compete agreements exacerbated the issue.

However Apple seems to be willing to pay for highly sought after skills.

I have also been told that they don't have company level hiring standards so you should expect uneven abilities across different teams.

I have also been told that things were being rewritten or rather that Apple likes to rewrite. Apple doesn't seem to be very good at limiting regressions caused by these rewrites.

That's why there are so many crashes across the board. The crashes are caused by bugs or changes in behavior in common frameworks. This seems to jive with the author saying that Apple doesn't do enough automated testing.

Re: Why iOS 13 and Catalina Are So Buggy

#104

Post by jwr »

I have a slightly different take on this. I think every company should dedicate a certain percentage of their revenue to handling bug reports from users. Yes, many bug reports will be bogus, but many will be pure gold (I speak from experience). Yes, it involves a lot of manual work. But it is so incredibly worth it — you get to catch the odd bugs that you will never catch with automated or in-house testing.

In contrast, big companies like Apple try very hard to avoid and ignore user bug reports. There is no way to easily E-mail them, "filing a radar" is hard, and even if you do they do their best to ignore your report.

When I wrote "percentage of revenue", I meant it. In my software business (https://partsbox.io/), I dedicate about 10% of my time to reading, analyzing, and responding to user bug reports. Carefully thinking about every report let me catch bugs and problems that I never would have found. I also learned that every user bug report carries some information: even if something isn't actually a bug, getting multiple reports about it might point to a usability or a documentation problem.

If Apple also spent 10% of its revenue on processing bug reports and fixing bugs, they would not have a quality problem like they do now.

Re: Why iOS 13 and Catalina Are So Buggy

#105

Post by bluejekyll »

babesh wrote: post #102

I have been told by multiple sources that Apple engineering salaries are not competitive with industry leaders and haven't been for a long time. I wonder if the dissolution of the Jobs anti compete agreements exacerbated the issue. However Apple seems to be willing to pay for highly sought after skills. I have also been told that they don't have company level hiring standards so you should expect uneven abilities acr…

I was just speaking with an acquaintance at Apple this weekend that works in a group in this area at Apple, and they pretty much said exactly what you just said.

Also, it doesn’t help that they can’t directly benefit from the general progress the industry is making in virtualization and container areas without rewriting for their own platform.

Re: Why iOS 13 and Catalina Are So Buggy

#106

Post by Someone »

dep_b wrote: post #96
chubs wrote: post #56

Earlier quoted context omitted.

Really? I read otherwise: https://blog.timac.org/2019/0926-state-of-swift-ios13/ It'd be hard to know unless you worked there. It's just a wild theory, I might be wrong :)

It makes very little sense for a resource constrained company to rewrite stuff that just works in Swift especially when it has a lot of low-level code. What they do sometimes is adding a Swift-friendly API layer around the Objective-C(++) code. Newer libraries that are not too low-level oriented might get written in Swift nowadays.

”It makes very little sense for a resource constrained company to rewrite stuff”

I don’t think ”for a resource constrained company” makes a difference there.

That’s good, because I have a hard time thinking of Apple as resource constrained.

Re: Why iOS 13 and Catalina Are So Buggy

#107

Post by [deleted] »

babesh wrote: post #102

I have been told by multiple sources that Apple engineering salaries are not competitive with industry leaders and haven't been for a long time. I wonder if the dissolution of the Jobs anti compete agreements exacerbated the issue. However Apple seems to be willing to pay for highly sought after skills. I have also been told that they don't have company level hiring standards so you should expect uneven abilities acr…

[deleted]

Re: Why iOS 13 and Catalina Are So Buggy

#108

Post by dang »

mattbillenstein wrote: post #10
nextstep wrote: post #6

Are they that buggy? They seem very stable to me and I’ve been running them since the betas.

Go refill your koolaid please.

Please follow the site guidelines when posting here, regardless of how wrong or annoying another comment is.

https://news.ycombinator.com/newsguidelines.html

Re: Why iOS 13 and Catalina Are So Buggy

#109

Post by mistahenry »

Svoka wrote: post #45
dplgk wrote: post #32

After doing some iOS/Mac development, I'd say some bugginiess is caused by changing APIs and behaviors inflicted by Apple, expected to be absorbed/dealt with by developers. They mercilessly do this with every release and no doubt that affects their internal projects. Also, xcode has gone the way of iTunes and ObjC was always a huge pain. It's a really hostile environment to develop in, where you're having to play cat…

Wow. My experience is opposite. Been in iOS development for over 10 years already, little less for Android. App made for iOS still works with very minor adjustments, while on Android it’s a mess. We was forced to change build system several times, breaking changes and just silly API renames, service depreciations, generations of push services, forcing firebase and AndroidX, change of permission model, of concurrency…

I support a MacOS app that connects to hardware devices via Bluetooth low energy and/or USB back to 10.7. First off, Apple makes it damn near impossible to test old versions, but we have every OS in a parallels VM and have copies. Every single release introduces breaking changes. We also bundle a version of our app on the hardware device and this is a big deal for us when an old version stops running on a new machine/OS. The way they’ve changed ATS over the years has broken across major versions.

They’ve changed Bluetooth chipsets a number of times over the years and each one has its own behaviors which makes writing one single BLE communication library that works for all versions very difficult. For instance, in the latest chipset, if you try to increase throughput by using a mixture of ble characteristic writes with and without response, you can very easily end up in a deadlock situation. It appears the hardware buffer just drops ble packets including those with response if full (which appears to hold 5 packets in the latest 2019 MacBook Pro). Dropping without response packets is fine since they’re expected to be unreliable (and you can build a reliable protocol on top) but they drop the write with response packet which the firmware blocks forever on (you can see this pretty clearly when using a ble packet logger). There’s no timeout and all subsequent packets are queued and never sent. Reliable writes should never be dropped!

Every new MacOS/iOS release is a worrying event. Testing the betas which are super unstable increases the tension because you never know if they’ll fix certain breaking changes. Up until the latest beta, our app did not work on iOS or MacOS until they rolled back some ATS hardening because they didn’t like the certificate pinning style we did of manually evaluating trust (which worked countless versions back).

Re: Why iOS 13 and Catalina Are So Buggy

#110

Post by emsy »

steve19 wrote: post #85
ChrisCinelli wrote: post #67

I did not work for Apple but this article describes exactly what I was thinking. Apple has very waterfall cycle. Everything is planned year after year to be released for the September event. When the deadline approach teams realized that are behind and they need to overwork. And when people get tired and under pressure, they usually introduce even more bugs. The article also nails the solution: a more Agile workflow.…

They could simply decouple the apps from the OS, like Android. Safari and Mail.app do not need to be tied to OS releases. Android OS releases do not get nearly as much fanfare because a lot of core functionality is decoupled from the OS: app store(s), mail clients, browsers, todo lists, even the text messaging apps and some security frameworks. Which of course is exactly why Apple keeps everything in one big release.…

I think you're right about the decoupling. But I don't think they do it this way for press reasons to be honest. Apple is all about integration, And it makes sense that this applies to Apps/OS as it does to OS/Hardware. Also, most buzz is generated by OS level changes (Dark mode etc.).
Post reply on HN