I feel like that's true for most of the relatively low-level disk and partition management tooling. As unpopular an opinion as it may lately be around here, I'm enough of a pedagogical traditionalist to remain convinced that introductory logical volume management is best left at least till kindergarten.
Despite knowing this is the correct interpretation, I still consistently make the same incorrect interpretation as the parent comment. It would be nice if they made this more intuitive. Glad I’m not the only one that’s made that mistake.
Swift 6 is not the problem. It's backward compatible.
The problem is SwiftUI. It's very new, still barely usable on the Mac, but they are adding lots of new features every macOS release.
If you want to support older versions of macOS you can't use the nice stuff they just released. Eg. pointerStyle() is a brand new macOS 15 API that is very useful.
It's not bad, just limited. I think it's getting usable, but just barely so.
They are working on it, and making it better every year. I've started using it for small projects and it's pretty neat how fast you can work with it -- but not everything can be done yet.
Since they are still adding pretty basic stuff every year, it really hurts if you target older versions. AppKit is so mature that for most people it doesn't matter if you can't use new features introduced in the last 3 years. For SwiftUI it still makes a big difference.
Came here to post the same thing. Would love to try the application, but I guess not if the developer is deliberately excluding my device (which cannot run the bleeding edge OS).
In fairness, I don't think you can describe it as bleeding edge when we're 5 months into the annual 12 month upgrade cycle. It's recent, but not exactly an early adapter version at this point.
Expensive. Keeping us on the expensive hardware treadmill. My guess is that it cannot be listed in the Apple store unless its only for Macs released in the last 11 months.
This isn’t true you can set the target multiple versions back. The main problem right now is a huge amount of churn in the language, APIs and multiple UI frameworks means everything is a moving target. SwiftUI has only really become useable in the last coupe of versions.
Every time Xcode updates, it seems a few more older macOS and iOS versions are removed from the list of "Minimum Deployment Versions". My current Xcode lets me target macOS back to 10.13 (High Sierra, 7 years old) and iOS 12.0 (6 years old). This seems... rather limiting. Like, I'd be leaving a lot of users out in the cold if I were actually releasing apps anymore. And this is Xcode 15.2, on a dev host Mac forever stuck on macOS 13.7. I'm sure newer Mac/Xcode combinations are even more limiting.
I used to be a hardcore Apple/Mac guy, but I'm kind of giving up on the ecosystem. Even the dev tools are keeping everyone on the treadmill.
You can keep using an older version of Xcode if you like. I mean, every other tool chain that I can think of does more or less the same thing. There are plenty of reasons to criticise Apple's developer tooling and relations, but I don't see this as being especially different to other platforms
Imagine having no canonical word for 'tap' (to tap something on a touchscreen) and needing to come to a consensus on what that should be, where a number of speakers aren't digital natives.
Imagine doing any form of research/preservation/data collection involving audio, and having no practical ability to do this anonymously, because voices are recognisable.
Imagine holding back recordings and writings because your great grandmother may have said something unusual, and not wanting to bring shame on the family/her memory.
Imagine discovering that your language has translations of the N-word, and needing to decide whether to reintroduce this to the language.
Imagine taking on the responsibility of releasing a dictionary, and drastically changing the usage of the language.
> Amazon's devices don't support the Google Play store...
FireOS devices aren't certified by Google and so, they do not come with "Gapps" (including the Play Store) preinstalled. Even if they were, Amazon might have some reservations about preinstalling Gapps (which run with higher than normal privileges), effectively letting Google get hands on its user's purchasing habits.
All that to say, this is a business limitation not a technical one.
It might not be "supported", but I thought you could easily sideload play store and play services? You don't even need to muck around with rooting or even adb.
It's literally downloading a few apks and installing them. You don't even need to use adb. You can do it all within the preloaded browser that's on the tablet.
I don’t remember it being that easy when I did it 3-4 years ago. I was also a bit uncomfortable downloading the google support libraries from APKmirror, as my life is on my google account. IIRC the APKs were unsigned.
I have two Kindle Fire tablets (they're low-quality as general purpose tablets, but cheap and good for reading comics or books) and both have Google Play on them.
I did that too but it turned out to be just too much trouble. Play store kept trying to update the handful of apps that exist in both Amazon's and Google's ecosystems, and it completely them.
https://en.wikipedia.org/wiki/Format_shifting
https://www.gov.uk/government/news/quashing-of-private-copyi...
Probably due to the following, but can't find it from a quick Google:
R (British Academy of Songwriters, Composers and Authors and others) v Secretary of State for Business, Innovation and Skills [2015] EWHC 1723