Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I have personally never encountered any problems with the flex cables on my Duo. Plus, the Surface devices are extremely well-engineered, and they seem to be the standard-setters when it comes to anything related to hinges (or kickstands) on devices these days.
Nice. I guess it's time for me to hunt a nice used Surface Duo to import from eBay come next year.
 
No disagreement on the Google Fold, it's pretty hideous BUT it's only 4mm thicker than a 15 pro max, the OnePlus Open is only about 3mm thicker, both when closed. Then we have some Chinese models like the Magic V2 which is only about 1mm thicker. Again, this is an emerging market and these are improving generation over generation. But I won't deny your point, if an extra 1-4mm is a deal breaker for you, you are completely entitled to that opinion. The crease is a very personal thing, of course I notice it but it disappears once the screen is on and I never notice it, but I've tried to always say that it's more than acceptable to not like foldables because of this. But if you look at reviews I'd say they universally say the same thing, the crease effectively disappears when the screen is on and I highly suspect those who find the crease obvious are those who haven't owned one for any length of time.

Edit: Let's also not forget about that big "island" right in your line of view on iPhones, talking about massive UX fails this has to rank right up at the top IMO.

No I'm not wrong, but neither are you, we are just going back and forth on what is basically opinion and personal preference.
I said you're wrong about the assumption that I haven't used a foldable at all
island is no different than punch hole cameras and way better than useless big bezels.

wireless charging is important and something they removed to get thickness down. this is objectively a compromise they decided to do
 
I'm not asking about that. I'm asking why Apple has to pull engineers from project to project instead of having dedicated teams, properly staffed, to focus on all their product categories simultaneously.

Why, for example, did Apple wake up with ChatGPT and start pulling engineers to work on this? Why will matured products suffer from a lack of staffing instead of having a dedicated team of engineers who are available to move around in different teams where extra, temporary staffing is needed?

Well in that case, the answer is even easier.

Apple doesn’t need engineers all year round for all projects, and it also seems averse to laying off people during engineering lulls. After a new release, there’s a lull for that project, so instead of sacking the engineers, they shift them to another project where they can use their expertise with the same APIs.

It’s also worth pointing out that Apple employs thousands of software engineers, so recruiting such large numbers for each project could be difficult; even more so if you have a reputation for binning them between during the lulls.

The other thing to remember is that there is a cost to employing new engineering staff. They need time to become familiar with the company’s engineering/quality practices, APIs etc. So in many cases, it is best to use existing teams.

The upshot is that it’s often not simply a case of throwing money at the problem.
 
  • Like
Reactions: kc9hzn
Well in that case, the answer is even easier.

Apple doesn’t need engineers all year round for all projects, and it also seems averse to laying off people during engineering lulls. After a new release, there’s a lull for that project, so instead of sacking the engineers, they shift them to another project where they can use their expertise with the same APIs.

It’s also worth pointing out that Apple employs thousands of software engineers, so recruiting such large numbers for each project could be difficult; even more so if you have a reputation for binning them between during the lulls.

The other thing to remember is that there is a cost to employing new engineering staff. They need time to become familiar with the company’s engineering/quality practices, APIs etc. So in many cases, it is best to use existing teams.

The upshot is that it’s often not simply a case of throwing money at the problem.

Again, the issue isn’t with over staffing, but Apple’s seemingly inability to constantly update ALL its product categories at timely intervals.

Apple regularly puts product updates on hold to focus on other projects. When products are released, Apple has an obligation to the paying customer to maintain those products in a timely manner and Apple hasn’t been doing that.

iMac missed the entire M2 series
iPad is overdue for an update
iPhone regularly fluctuated with solid updates and…well…not so solid updates
Apple display lacking any update
Mac Mini overdue
FCP used to be a leader and has fallen behind Premier and Resolve
Aperture sunsetting
iMac 27” sunsetting
MacPro being years late for the move to AS
Bug infested releases of nearly all OSs in the past few years

My criticism isn’t on Apple choosing to shut down or kill a product category they don’t want to be in but in not maintaining the categories they are in. It seems there is a lack of engineers or a lack of management for the engineers.
 
Well in that case, the answer is even easier.

Apple doesn’t need engineers all year round for all projects, and it also seems averse to laying off people during engineering lulls. After a new release, there’s a lull for that project, so instead of sacking the engineers, they shift them to another project where they can use their expertise with the same APIs.

It’s also worth pointing out that Apple employs thousands of software engineers, so recruiting such large numbers for each project could be difficult; even more so if you have a reputation for binning them between during the lulls.

The other thing to remember is that there is a cost to employing new engineering staff. They need time to become familiar with the company’s engineering/quality practices, APIs etc. So in many cases, it is best to use existing teams.

The upshot is that it’s often not simply a case of throwing money at the problem.

And that’s true of software engineering in general, especially the last paragraph/sentence. That’s the single biggest lesson in software engineering from the past 50 or 60 years, one we’ve repeatedly learned (see The Mythical Man-Month). Those who forget history are doomed to repeat it. Also, having engineers move between projects during lulls is also a good way of preventing the company culture of fiefdoms that emerged in Apple during the late 80s to mid 90s. It’s that internal culture that strangled Apple’s efforts on a successor to Mac OS 7 and was a significant contributor to the company’s near bankruptcy.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.