| ▲ | lukemercado 14 hours ago |
| The incredible engineering in the hardware is prized above software quality. For most companies I'd say this is a natural tradeoff, but Apple has so much money that they can actually afford to be world class in both. Or at least, you'd expect they could. Maybe being world class in software would require delays to the hardware side of the business? Regardless, it's definitely a weakness of the culture and I'd venture that weakness is why Apple has essentially failed at AI. |
|
| ▲ | Barbing 12 hours ago | parent | next [-] |
| > Apple has so much money that they can actually afford to be world class in both This is what gets me. Think about only bugs, not a single wishlist feature, just bugs. Limit to obvious-to-normies defects: so, UI bugs (ultra-low contrast oddity with certain backgrounds while scrolling lock screen notification center) or popular-feature bugs (AirDrop demands “everyone“ to receive from people in contacts, apparently in at least a couple cases). At least in the case of UI bugs, no secret sauce seems to be required to resolve them. No particularly special feats of engineering. It seems simply dollars can fix them: QA & engineering. When I discover these obvious defects, update iOS multiple times over the course of months, and continue to experience them, I can only assume Apple prioritized having cash on hand over investing in my (our) experience. |
| |
| ▲ | bisby 10 hours ago | parent | next [-] | | My macbook updated to Golden Gate, and upon reboot, a bunch of stuff was mysteriously not working. Couldn't access my NAS. couldn't reach my home assistant dashboard... I could still SSH into the devices, just couldn't reach them via firefox, or chrome, or a few other apps. So it wasn't my networking being out... Turns out "forgot to ask for local network access and since the prompt was never allowed, default to denied" is a known bug, and since it never asked, there is no way to toggle either. It was just a bullet point in the reddit thread of networking things that broke in macos 27. It had a solution. Somehow my terminal had known to ask for permission, so it got it, but all my UI apps didn't. I had to sudo a change to remove my local network from the local network list, and then it worked. I would think that "suddenly all my local services stopped working" is a noticeable to normies bug. Most normies won't have a ton of local services, but normies that live with techies probably will have a few. | | |
| ▲ | msdz 9 hours ago | parent [-] | | > normies The tinfoil hat explanation for
this is that everyone at Apple is using iCloud for everything, and thus would never encounter a bug with locally-hosted services. |
| |
| ▲ | rootusrootus 11 hours ago | parent | prev | next [-] | | The number of incredibly obvious bugs in Screen Time that make it frequently useless just boggles my mind. It has never worked for us at anything like 100%, it is hit or miss and frequently just does randomly stupid things. Settings reverting on their own, new app categories appearing out of thin air, etc. Just one more thing that sours me on their stuff when I'm otherwise inclined to like it. | | |
| ▲ | sen 10 hours ago | parent | next [-] | | You can’t even block YouTube on your kids devices because Screen Time doesn’t see that YT is installed. A known bug for years now. Then good luck getting the time limits to work. It’ll tell the kids “5 minutes left!” then just let them keep going. | | |
| ▲ | hdgvhicv 8 hours ago | parent [-] | | That’s odd as I do that quite successfully with my kids. Parental controls are far superior to Microsoft and epic. |
| |
| ▲ | Kimitri 10 hours ago | parent | prev | next [-] | | Our family has struggled with Screen Time a lot. I have come to the conclusion that it's actually beneficial for Apple to keep Screen Time as crappy as it is. That allows kids to use their iPhones more. That's good viral marketing in a very lucrative demographic and it drives up AppStore sales, micro transactions and engagement rate. | |
| ▲ | nik282000 10 hours ago | parent | prev [-] | | I've used 3 Apple products for more than chance interactions. A MacSE for 5 years in school, a 2015 Mac desktop for 6 months in a printshop, and an iPad for the past 2 years at work. The SE and desktop felt like modern machines, clicks and key presses had predictable results, applications did what you told them too. On par with the Win95 and Win 7/8 I was used to at the time. Jesus Christ, that iPad on the other hand, feels like janky Windows Vista tech rammed together by an intern. Weird UI artifacts, making the same gesture can have unpredictable results, the only function that everyone in the shop found without failure was 'undo' because it is triggered by violent shaking. Even simple tasks like sharing a photo saved from a website is bizarrely broken. Depending on whether you saved it as a file or 'to your photos' dictates which applications can then open/share the image. And I know Android is full of it's own foibles but they took a few months to internalize. I'm going on 2 years of 'features' breaking workflow, and pixel perfect taps to activate input elements that are 5% of the screen width. /rant | | |
| ▲ | iSnow 2 hours ago | parent [-] | | Maybe you are right, but Apple is selling hundreds of millions of iPads per year, so just maybe most people are content with the hard- and software and will just adapt to some quirks. I am personally not always happy with the gestures, but some can be disabled. I don't have much use for my iPad apart from watching some videos, for everything that requires concentration, I will fallback to my laptop. I still think it is a marvelous machine how the hardware and iPadOS play together. |
|
| |
| ▲ | gigatexal 8 hours ago | parent | prev | next [-] | | > Apple has so much money that they can actually afford to be world class in both
> This is what gets me. Think about only bugs, not a single wishlist feature, just bugs. Limit to obvious-to-normies defects: so, UI bugs (ultra-low contrast oddity with certain backgrounds while scrolling lock screen notification center) or popular-feature bugs (AirDrop demands “everyone“ to receive from people in contacts, apparently in at least a couple cases). I’m hopeful Ternus can turn this around. They can be top notch in both being all vertically integrated and demanding the best in both. Let’s see. | |
| ▲ | jimbokun 12 hours ago | parent | prev | next [-] | | And now they only need to take their backlog tickets and throw tokens at them. | |
| ▲ | Ouman 8 hours ago | parent | prev [-] | | [dead] |
|
|
| ▲ | appplication 14 hours ago | parent | prev | next [-] |
| Having recently worked at Apple on the software side, my general experience was that it was fiefdom driven, there is no internal standardization on quality or process. Low level teams compete on ideas and careful politicking usually wins over quality or merit. For AI, there were top down directives to find new ways to experiment with and incorporate into core products and processes, but as you went down the management chain, management became more conservative. First and second line managers were strongly incentivized to keep their products, roadmaps, and interfaces stable and predictable by similarly conservative stakeholders. And as such, they were generally unwilling to officially dedicate much effort to AI other than the minimum “look at how much we’re using Claude”. In particular due to the lack of central tooling, any team trying to do much with AI essentially had to reinvent much of the stack themselves. So even small projects were largely untenable due to inevitable required scope creep. |
|
| ▲ | jandrewrogers 12 hours ago | parent | prev | next [-] |
| Minimizing shipped defects is qualitatively simpler in physical engineering because the set of possible defects you have to account for is astronomically smaller. I am a physical engineer by background but have also spent much of my career in high-reliability software systems. The problems of reliability in software systems make physical systems look like child’s play. The levels of effort are on different scales. An important difference is that software correctness is mostly binary. In physical engineering you can usually spend a bit more money to over-engineer a component if you have any doubts or are lazy, and that works. Effort does not scale nearly as well when it comes to reliable software. |
| |
| ▲ | rickdeckard 5 hours ago | parent | next [-] | | There is also a much closer defined "completion" state in hardware, with responsibility also more distributed across suppliers. You have a committed spec of one component, connected to the committed spec of another component, with committed maximum deviations. All that is fixed, so you engineer for possible permutations and mass-production. (it's still a massive feat, I'm not downplaying it. But it has a defined completed controlled state) In software this is much more fluent. You may have a spec of a library and the APIs you use, and your app might otherwise be static. But you're handing alot of what you do to an OS, which juggles everything and continues to change over time. That API you're calling may not even have full control over the modules its interacting with. | |
| ▲ | vlovich123 10 hours ago | parent | prev [-] | | And there’s an enormous amount of good engineering effort Apple does put into both quality and crazy cool shit that gets done. People just don’t appreciate it because it’s invisible when it works and it’s not as cool as “ran a graphite heat pipe through the fold” which is probably one of the easier things they did for the fold. |
|
|
| ▲ | brookst 11 hours ago | parent | prev | next [-] |
| Ask any giant company that's been disrupted by a startup: money does not buy taste, or quality, or core competence. It can help, if leaders understand those things. Apple is ultimately a hardware company that's so good they can monetize software and services. But they are not really a software company, or a services company. I think Ternus' promotion recognizes that: software and services are worth a lot of money, but they're value adds to hardware. |
|
| ▲ | prpl 14 hours ago | parent | prev | next [-] |
| Big E Engineering vs little e engineering. IMO the barriers to entry are just much different, and it’s reflecting in the workforce. There’s cultural differences too, but I think the education differences is the biggest cause. |
| |
| ▲ | buzzerbetrayed 13 hours ago | parent [-] | | Nah. That’s not it. Software is just legitimately harder than most physical engineering (notice I didn’t say all). How often do skyscrapers fall over, or bridges collapse, or your CPUs fail unexpectedly, or submarines implode. Rarely. In fact, I bet most people reading this thought of the same few examples. Then look at software. When is the last time you encountered a bug? Have you ever heard of bug free software? Even at the elite, smartest, most educated levels of software, there are still bugs everywhere. Humans are essentially incapable of writing bug free software. And it isn’t because a bunch of uneducated dummies that didn’t get degrees are the ones writing it (as you arrogantly implied). It’s because it’s way fucking harder to do perfectly or near perfectly. That doesn’t mean there isn’t incredibly hard physical engineering. Obviously there is insanely difficult engineering in nearly any variety. But if you ask a civil engineer to design you a perfect bridge, they probably will. Ask a software engineer with all the experience and education in the world to build you a perfect podcasting app, it simply isn’t happening. | | |
| ▲ | williamdclt 5 hours ago | parent | next [-] | | You're literally the first person I've ever seen suggesting this, I actually thought you were being sarcastic! My POV (and most people's, I think) is that software is buggier because software people are wildly unserious compared to hardware people (and other engineering disciplines like civil engineering). Which is an alright trade-off in the very large majority of cases, as software is rarely very important and is easy to update, whereas hardware and bridges are very high-stake and extremely costly to update. > if you ask a civil engineer to design you a perfect bridge, they probably will. Ask a software engineer with all the experience and education in the world to build you a perfect podcasting app, it simply isn’t happening The civil engineer gets to rely on extremely high-quality very-serious civil engineering work, built over millenia. The software engineer relies on shaky (ie buggy) work from past nowhere-as-serious software engineering work, built over ~70y. The fact that the software engineer can do anything at all on such small and buggy past work shows how easy it is compared to civil engineering. In my mind, saying "software engineering is shown to be harder by the presence of bugs" is akin to saying "LEGO building is harder, people build stuff that collapses all the time" | |
| ▲ | tarsierscripter 12 hours ago | parent | prev | next [-] | | How often do skyscrapers fall over, or bridges collapse When skyscrapers fall or bridges collapse, the negligent engineers who knowingly signed off on them go to jail. When was the last time a software developer or manager went to jail over a known bug? | | |
| ▲ | vlovich123 10 hours ago | parent [-] | | People going to jail for such failures are actually quite rarer than you imply. And generally software bugs rarely cause similar damage either in lives or money lost. | | |
| ▲ | NamTaf 10 hours ago | parent | next [-] | | A better comparison to software bugs is, say, early fatigue cracking in a structure that requires retrofits to fix. Regardless, the simple fact is that software just matters less in almost every case, so no one gets held accountable. It lets the culture of unaccountability breed within IT / software eng, and here we are. | |
| ▲ | tarsierscripter 10 hours ago | parent | prev [-] | | None of that invalidates my point. Civil Engineers (the ones building bridges and skyscrapers) have a culture of institutional accountability. They are certified members of a professional organization and when they sign off on a project, they do so by affixing their personal seal to it. This is their binding endorsement of the soundness of the architectural drawings. The presence of that seal can be used as evidence in court against them (criminal or civil). It’s also possible for engineers to be stripped of their seal by the organization for failures far less severe than a bridge collapsing, such as conflicts of interest. There isn’t anything like that in software, even though the stakes are much lower. Far more common is a total disclaimer of warranty whatsoever. |
|
| |
| ▲ | matwood 2 hours ago | parent | prev | next [-] | | I don't think it's whether one is harder than the other, it's about constraints or in software, lack of. Hardware is constrained by the physical world while software has much fewer constraints leading to a huge number of permutations. | |
| ▲ | applfanboysbgon 8 hours ago | parent | prev | next [-] | | lol no. This is just a sort of learned helplessness that is endemic in the industry. A way to protect your ego: nobody could have avoided shipping that critical bug to production, so it's not your incompetence that led you to do it! You want a podcast app, I will give you a formally verified podcasting app with zero bugs. I will engineer the shit out of it. Just give me a year and $500,000. Oh, you don't want to? And that right there is why we have bugs. Not because it is hard, but because nobody gives a shit. Even though companies lose way, way more than what it would cost to prevent severe bugs from happening, some things you literally cannot prevent without government regulation, as engineering itself went through after a period of nobody giving a shit and a lot of people dying as a result. | | |
| ▲ | sehansen an hour ago | parent [-] | | The reason is people don't want to specify the full set of requirements to that podcast app ahead of time. You can spend your year and $500,000 and then the users will play around with it for ten minutes and then tell you it needs to do this and that as well. And one of those features requires you to go back and make fundamental changes to your architecture making you redo a lot of your subsequent work, including a lot of the formal verification. So it is harder because there is so much freedom in terms of what features a program can have and what the set of requirements can be. And that's just for getting to version 1.0. Software is expected to change much more than hardware is and if the requirements for version 1.7 can only be met by a severe change to the architecture or an ugly hack, the ugly hack will look very tempting. Having said all that, I'm not sure I disagree all that much with you. A lot of this could be improved with more big E Engineering in the software world. One way could be with some kind of professional engineer certification. It should be reasonably easy to get the first time by passing a test on some hard and concrete software engineering principles. But if you are ever found to break them, you lose the license and will have to go through a lot to get it back. That of course only works if companies care about people having this certification. Which leads (as you mention) to government regulation. As someone who works with medical device software I can see that it actually works. The regulations succeed in forcing us to figure out a reasonably complete set of requirements early, but it is an ordeal. For a recent project we had working prototypes for basically all functionality and still we spent four calendar months doing nothing but requirements before we started developing the actual product. And yet medical devices still have software bugs. There are 24 software related recalls in the FDA medical device recall database just this year so far: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRes/res... |
| |
| ▲ | sgarland 19 minutes ago | parent | prev [-] | | > submarines implode Fantastic analogy, and I assume you already know where I'm going with this. The Titan submersible [0] implosion was by all accounts due to studiously ignoring best practices and test results. They shipped fast. In contrast, James Cameron's Deepsea Challenger [1] was a slow and methodical build, and has heavily redundant backup systems for everything. For example, the ballast release system operates by demagnetizing coils that hold the ballast; that way if they have a system failure or power loss, it fails open, and they ascent. If that somehow fails, the supports for the ballast will corrode from sea water before the oxygen runs out, so in the worst case, it's sitting in the dark for a few hours before heading back up. Or, let's look at the U.S. Navy submarine program. I was a propulsion plant operator (reactor operator + throttleman) on a Virginia-class sub. Though I can't go into specifics, "redundant" doesn't begin to describe it. FFS, the San Francisco (688-class sub) ran into an underwater mountain at flank [2] and survived. The SUBSAFE program [3] was a direct result of the loss of the Thresher [4], and to date, no SUBSAFE-certified submarine has been lost. > Then look at software. When is the last time you encountered a bug? Have you ever heard of bug free software? You're conflating "free of defects" with "capable of gracefully handling defects." NASA writes as close to bug-free as I think you'll find, but even theirs isn't perfect [5]. The difference is the ability for the software to work through or around those problems. Submarine / submersible design and construction is the same. Are the engineers, welders, machinists, electricians, etc. attempting to do perfect work? Of course. They also are aware that perfection is impossible, and so the design accounts for that. 0: https://en.wikipedia.org/wiki/Titan_(submersible) 1: https://en.wikipedia.org/wiki/Deepsea_Challenger 2: https://en.wikipedia.org/wiki/USS_San_Francisco_(SSN-711)#Gr... 3: https://en.wikipedia.org/wiki/SUBSAFE 4: https://en.wikipedia.org/wiki/USS_Thresher_(SSN-593)#Disaste... 5: https://space.stackexchange.com/a/37694 |
|
|
|
| ▲ | jmspring 10 hours ago | parent | prev | next [-] |
| The Face ID bug that caused a reboot on iPhone 18 pros was a clear example that they put little quality control into software. |
|
| ▲ | Danox 10 hours ago | parent | prev | next [-] |
| World class in comparison to their present competition in hardware and software? Google, Microsoft, Qualcomm, Meta, Intel, AMD, Nvidia... |
|
| ▲ | wickedsight 9 hours ago | parent | prev | next [-] |
| I feel like this might be inherent to software and hardware development. With hardware you pretty much get to restart on every product you make. Sure, you have many of the same (types) of components, but with every iteration, you move them around and pretty much have to rethink how every part fits together and interacts. And it has to work when devices get to consumers, because you can't visit everyone to solder on a wire you forgot. (You can always tell people they're holding the phone wrong though.) With software you have this continuous blob that you keep adding features to. You never really get to rethink how it all goes together from the ground up when the design changes, you just slap a transparent UI on top of you existing code and call it a day. If it turns out there are bugs, not a problem, you just push an update and hope that fixes more than it breaks. |
|
| ▲ | Ouman 8 hours ago | parent | prev | next [-] |
| [flagged] |
|
| ▲ | functionmouse 12 hours ago | parent | prev [-] |
| > The incredible engineering in the hardware is prized above software quality. then let me root and customize the software to my liking |
