If you're building macOS apps, it's common to want to test them on all system versions you support. Especially so considering Apple's attitude towards backwards compatibility.
Virtualizing an older ARM version of macOS was never going to be sufficient to QA x86 applications running on older Intel Macs. For that, you'll always want real x86 hardware.
EOL or no, there are many people who still use older OSes because they own older computers, can't afford an upgrade or don't want one (it works just fine!), and can't be bothered with figuring out running a newer OS on officially unsupported hardware.
Case in point: I built a macOS app that implements Google's Nearby/Quick Share (an AirDrop-style file sharing thing on Android). Multiple people tried running it on Catalina and were disappointed that it wanted a newer OS. So I did end up backporting it to Catalina.
CI is the big one, or similar testing against older versions for backwards compatibility. Usually good enough to just compile for it on MacOS, but sometimes we get a surprise in a third party library or something that only shows up on an older release.
I've first tried recompiling the Keychain app, but it had too many dependencies that were not trivial to build, so, using an older Mac, in that case, was the easiest way to get the private key from my own keychain.
You don't need a Hackintosh to virtualize a Mac - you can actually download the MacOS image directly from Apple and boot it right into QEMU with the proper configuration. I've used a few scripts over the years that could have an OSX image running on Linux in less than 15 minutes.
I was thinking the same. My (admittedly old-ish) 2070 Super runs at 25-30% just looking at the landing page. Seems a bit crazy for a basic web page. I'm guessing it's the background animation.
I find it amusing how you answer your own "question" before asking it. Why would they target the marketing material at people who already know they aren't going to need to upgrade?
Roopepal did someone piss in your coffee this morning?
I had no questions. I’m merely saying that it’s funny they’re comparing to old technology instead of last year’s.
It’s a valid criticism.
Take a breath.
SwiftUI does not replace storyboards. It replaces UIKit(/AppKit).
You can build UIs without storyboards/Interface Builder in UIKit just fine. And writing your UI in code indeed easily solves the whole versioning conflicts issue that storyboards have.
So no, not a big argument for SwiftUI, but instead for writing UIs in code.
SwiftUI vs. UIKit and IB vs. code are two entirely separate discussions.
But yes, I totally agree, if you must use storyboards, keep them as small as possible.
> SwiftUI does not replace storyboards. It replaces UIKit(/AppKit).
Unless I've missed something, by doing the latter it automatically also does the former?
> You can build UIs without storyboards/Interface Builder in UIKit just fine.
Eh, perhaps the examples I've worked with of that were especially egregious (it's certainly possible given some of the other things very very wrong with that code), but my experience of such a codebase was very much not fine.
I have worked with lots of codebases using UIKit constraints in code. These were non-trivial apps (200k lines of code). You can create wrappers of your own to simplify things or use libraries like Snapkit. It works and there's no need to use Storyboards.
The bad codebase I'm thinking of was 120 kloc. But I'll take your word for it being possible to do better than that example, one example is merely an anecdote.
I think they want to make the distinction that SwiftUI is not necessarily to replace Storyboards, although it will replace them.
UIKit works okay in code. But unless you have experienced people actively laying groundwork, it's IMO more likely to be a mess than SwiftUI. Even the explicitly declarative part, Autolayout, will only be understood by like 10% of the team and the rest are kinda winging it. Using Autolayout outside of Storyboards makes it less declarative, so it is then more conducive to programmer error (like non-idempotent updates).
According to the first 10 sources I see for a "define passenger" Google search, the pilot is not a passenger. One of those sources is even for legal purposes. I have also never heard anyone refer to the driver/pilot/crew as passengers. What am I missing here, is this some lingo specific to this context, or?
> I hate how the window management works. I hate how annoying it is to get two windows to show side by side.
Plenty of window management apps and tools available. Rectangle, for example.
> I hate how there end up so many icons in the menu bar which are entirely unhelpful.
The only ones I cannot seem to be able to remove trivially are the clock and the Control Center. Solved in mere seconds by typing "menu bar" into the System Settings search. You could literally even just hold cmd and drag almost any icon out of the bar. Not to mention any of the more involved menu bar customization apps and tools.
Why does it seem like such "macOS bad Linux good" comments always compare the default macOS experience to a personalized Linux environment?
Why does an out-of-the-box Mac have to fulfill the same requirements we spent hours configuring for on a Linux machine?
Where does the capability or mindset to install a tool disappear when we move from Linux to macOS?
Why does an out-of-the-box Mac have to fulfill the same requirements we spent hours configuring for on a Linux machine?
I think part of the problem is due to Mac and Apple have traditionally sold itself as intuitive and easy-to-use out of the box. People buy a Mac because they've been told that they don't have to spend hours configuring it. Hell Apple built a whole ad campaign around how the Mac is so much easier and more intuitive to use than Windows computers. However truth is that if you're coming from Linux or Windows, a lot of MacOS is incredibly unintuitive and weird out of the box.
Yes, I do in general agree with that. I suppose my confusion really only applies in this particular context of , e.g., HN; I would expect software engineers to look at these issues differently than your average home or office user. It seems to me that this "easy to use out of the box" marketing is aimed at a different sector of users, and I would expect software engineers be able to look through this. Perhaps my expectations and assumptions are wrong.
I am just curious where all the willingness to tinker and solve problems appears to disappear when we move to macOS.
Windows spying on you? Oh, let's install this tool X and change a whole bunch of registry settings to prevent that.
App windows behaving annoyingly on Linux? Oh, let's just switch to a completely different desktop environment/window manager or what have you.
Too many icons in the menu bar on macOS? Yeah, I'm returning this machine. :)
> Why does it seem like such "macOS bad Linux good" comments always compare the default macOS experience to a personalized Linux environment?
>
> Why does an out-of-the-box Mac have to fulfill the same requirements we spent hours configuring for on a Linux machine?
Pretty much all of their complaints are addressed out of the box by most of the major desktop environments. Install whatever popular distro of your choice and you can trivially put two windows side-by-side like you can on Windows.
13.4 was released on May 18, 2023. That's actually not very far into the past.
Anyway, what would be the most common use cases for this? And how common are those?