I've been on the beta for a while. I'm sort of surprised that they actually released with the state it is currently in. Most things work, but my CPU still spikes for no reason running some OS process or another.
Also, clicking on a dropdown box in a web browser (Safari, Chrome, or Firefox) after the computer has been asleep for a while freezes the whole computer for about 10 seconds.
Maybe it's just me, but that feels like a showstopper.
The whole 32/64 bit thing doesn't seem too bad, although I've had to use Pages instead of Word and can't use Adobe products anymore and have had to switch to open source alternatives, but I don't use those products very much so it wasn't a huge deal for me.
I've just checked which 32-bit apps I have (system information/software/applications if you wonder) and turns out if I upgrade I lose:
- My scanner support (they have new version, which is insanely buggy and can't even detect my scanner properly)
- All my games (literally every single one of them turns out to be 32-bit) - I don't play that much but still, would be a shame to lose all of them
- Postal label printing app (no idea if they have an update, need to check)
- App supporting my stand-alone disk array (not using it too much though)
- My niche learning apps (pretty old, from small providers, not sure if they'd ever be updated)
Much more than I expected, given that I don't have any exotic stuff like music instruments, specialized equipment, etc. So I personally probably would hold off upgrading as long as I can.
Apple's backward compatibility is poor, and particularly bad for games. The 32-bit apocalypse kills off a large subset of the Mac's already less-than-stellar game library; and on iOS it already broke many apps that I used, many of which will not be updated. To me it seems like Apple is going in the wrong direction - really I want them to add an x32 ABI to save pointer space for apps that don't need more than 4GB!
Stick with Windows/Steam/Consoles/etc. if you don't want a bunch of your games that you purchased to become unplayable every year (unless you add multi-boot to run the old, compatible OS, or run them in a VM, which usually works poorly.)
As I have mentioned before, it's a very annoying example of Apple shifting technical debt and maintenance work away from themselves and onto developers, and the overall maintenance burden is greatly increased.
I like how the platform moves forward, but I really wish that there were a way of getting desirable security patches and feature improvements in the OS without breaking all of my apps.
Dropping 32bit support is game-over for gaming on macOS. The numbers already didn't add up for indie developers [1]. Even AAA game developers often ignore macOS because the ROI is just too low. And from the $5/month subscription how much will end up to the developers [2]?
Essentially what Apple Arcade will end-up hosting is ports of run-of-the-mill mobile games. And I'd bet the advertised number of developers will diminish as soon as the agreements they secured for the launch expire. But if this is the kind of gaming you're interested into, you already have your iPhone/iPad.
> Dropping 32bit support is game-over for gaming on macOS.
No, it isn't. There were never any 32-bit x86 Macs with decent GPUs. Dropping 32-bit support only affects games that were already old enough to be commercially irrelevant or games that rely on unmaintained third-party middleware that never got a 64-bit port. Those don't add up to enough to be a major impact on the Mac gaming market. There are plenty of other factors that are much more important, such as Apple's abandonment of OpenGL and preference for Metal over Vulkan.
A huge amount of Indie games do not require a powerful (or even decent cpu). Many of them have Linux and Mac ports. Those are the same kind of games whose developers do not have a lot of spare resources to stay on the endless treadmill of deprecation.
It also kills any hope of wine powered support for proton in steam as many many windows games will be still 32 bit for a very long time (mind you, metal already had put a big dent in that).
Interestingly Linux users are indirectly getting affected by this: for many developers supporting Linux was just a byproduct of supporting macOS. As the latter is being dropped, support for the former is getting harder to justify. Luckily Proton seem to be a very viable alternative to native games.
Those are old games for the most part. The newest thing on that list appears to be from 2015, and it's a remastered version of games released in 1999 and 2003.
They certainly weren't making much money off these particular games even before Apple announced the deadline for going 64-bit. It's unfortunate and disappointing for customers who had already bought those games, but this deprecation didn't shut Aspyr out of much in the way of future sales.
But that's not what drives the market for Mac gaming. What matters is what kind of return on investment developers expect to get out of porting to macOS. They don't particularly care whether the port keeps working for four years or forty, because they'll make basically all the revenue in the first several months.
Now, if users become reluctant to buy Mac games for fear that they'll stop working unacceptably soon, that could have a meaningful impact on demand for Mac games. But even if Apple made it official policy that they would break games after four or five years, that wouldn't completely kill the market for Mac games. If Apple made it cost-prohibitive to get a game ported to their platform in the first place, that would pretty much be "game-over for gaming on macOS".
Commercially irrelevant for the game maybe, but not for the platform. If i can't play my old favorite games i am less inclined to buy a new platform. Or might move to a platform which supports those games.
Well, let's see. My main 3 purchase locations are Steam, Humble Bundle and GOG.com. I'd guess this is fairly typical, but anyone using other platforms feel free to add yours.
Steam: The Steam client is still stuck on 32bits. I'd bet it will soon be updated to 64bit, but it just goes to show that macOS is pretty low in the priorities of Valve. And if a company with the resources of Valve doesn't care, I can't see much motivation for the individual developers either.
Humble Bundle: I've went through the current and following Humble Bundle Monthly games. Windows Only: Call of Duty WWII, Crash Bandicoot Remastered, Spyro Remastered, Sonic Mania, Planet Alpha, Override-Mech City Brawl. Windows+macOS: Battletech, The Spiral Scouts.
GOG.com: There's already a 64bit DOSBox port—DOS–era games will eventually be supported. Windows–era games are gone—Catalina breaks Wine emulation and no announcement has been made for 64bit support by the Wine Team. For newer games, GOG.com will need new builds from the developers—doubtful if we ever get to see those, especially for indie games where developers don't have the resources to go back and port their released games. Newly released games are often Windows-only.
I don't know how you see this picture, but it looks pretty bleak to me.
The Steam client has been updated to 64 bit quite a long while before. But the in built updater seems to only fetch the 32 bit version. If you uninstall Steam and do a clean reinstall from Steam website, you will get the 64 bit client.
Most indie games in the past 5+ years are made with a few middleware engines like unity or gamemaker and AFAIK it's a rebuild option to release a 64bit version.
This is true, but unfortunately, a lot of games are almost completely unmaintained, especially on macOS. Many of the smallest indie game developers don't even own Macs—they either borrow their friends' machines to do one-off builds, or they use cross-compilers and rely on fans for testing.
Even just recompiling the game might be a challenge for a lot of developers in the "long tail" of the Mac game library.
This is my sentiment as well. A twitter summed it up nicely:
> the notion that every developer of every app is part of the constant, incessant update loop that Apple encourages is fundamental to the problem. Someone's super personal narrative unity game from 2013 is not getting updated!
Unity 5 came out in 2017 and it's not supported on Catalina.[1]
So devs of two year old games will need an old macOS install that can export their game to 64-bit, but also a new enough macOS install that can notarize their app (maybe these can both be Mojave -- but many indies don't own their own macs).
Also, Unity 5 is no longer available for purchase. If they're already using their license on another machine, they'll have to migrate it to these macOS installs.
Devs could upgrade to a more recent Unity and fix all the bugs, but to what benefit and at what cost?
It would be interesting to see a report from Steam on how many 32bit only OSX games are in the store. According to the stream hardware survey [1], OSX represents 3% of their install base.
... I mean sure, I love the idea of paying $60 for a game that throws away 15-20% of the performance by targeting an architecture that hasn't been supported by MacOS for more than a decade, rather than supporting an architecture that has been around for something like 15 years.
But yes, apple is in the wrong here, and should continue to support hardware that they haven't shipped in 10+ years.
I assume you're in the group that believes MS should be required to support XP forever.
As far as iOS is concerned, Apple got rid of 32 bit support in the processor itself allowing it to improve the processor.
Keeping around old code increases the security vulnerability surface. For instance, there are at least a half dozen ways of representing a string in Windows. One of the earliest widespread vulnerabilities in Windows was caused by improper handling of string encoding where anyone could run DOS commands on a web server running IIS just by encoding the commands in the browser.
> As far as iOS is concerned, Apple got rid of 32 bit support in the processor itself allowing it to improve the processor.
That is slightly different because Apple is designing their own mobile CPU's. And indeed by dropping 32-bit ARM support they can simplify and improve their CPU designs.
OTOH, Intel isn't gonna drop 32-bit x86 support from their chips just because Apple isn't making use of it.
Yeah but maybe dropping 32-bit support is a necessary step before dropping Intel chips...
They will face some* backslash now, but if/when they switch Mac to their own arm chips they might achieve a painless transition.
*They announced 32-bit deprecation like a decade ago, will legacy users be pissed of? yes! Is it a excuse for developers that still relied on 32-bit support over the last decade? NO!
That’s kind of the point - it’s gotten worse since then. Windows has become more bloated as they’ve added on more layers and refuse to drop backwards compatibility.
Presumably Apple is dropping x86-32 because they don't want to spend resources maintaining 32-bit support libraries, doubling their testing matrix etc. And now you want them to add a third ABI?
(Even in the Linux world, which prides itself in supporting crap used by a handful of people globally, X32 is dead, to the extent it was ever alive.)
X32 is dead exactly because, where 64bit is not needed, x86-32 is perfectly fine. I.e. the only practical reason not to go 64 is backward compatibility.
- Never needs more than 4 GB RAM (because it's not worth the usability downsides from having two binaries and letting the user choose which to use, just for a small performance boost)
- Is performance critical
- Performance is bound by memory and/or cache bandwidth
- A large share of the program memory usage is due to pointers
The intersection of all the above is just vanishingly small in reality. X32 was never more than a gimmick to score a few extra points in SPECcpu. And thus people rightfully ignored it.
Regarding games, Apple Arcade seems to be just what the Mac needed.
I haven't evaluated the quality of available offerings yet, but they look good in the App Store previews, and I think they're all native Mac apps (not lazy ports), using Metal and everything.
Although yeah, you can't really own any of those games and will always need a subscription, and some may be removed in the future.
I play games on my Mac when I can play them on my PC (travelling is one reason for this). I try buy my games DRM free on GOG, and play them either on Mac or through Steam streaming (yes you can load non steam games). My Mac game library is essentially wiped out by this.
And yes, there's this Arcade, but I have no interest in playing for something which is locked down to one platform.
* 64bit processes usually can't load 32bit modules, only a 64bit OS can (true for Linux and Windows, I'm not sure if it's true for x86 overall). There's a pretty good chance that only a 32bit CrossOver could load 32bit modules.
* Has 32bit support been stripped from the kernel, or has it only been stripped from the installed dynamic libraries? I'd wager that it's stripped from, or partially stripped from, the kernel. Even if Catalina allows 64bit processes to load 32bit modules, the kernel would have to support it.
There's a one in four chance your scenario is supported. CrossOver definitely couldn't magically voodoo a 32bit module into a 64bit one, as it's impossible to determine if a register/address is a 32bit integer or pointer; if it doesn't work today, it will probably never work.
I'm not sure if macOS supports IOMMU, but an external GPU with a VM might be your saving grace here.
Wow, VueScan! A blast from the past. I used it 15 years ago. Glad to see it's still around, maintained by the one guy (and now him and his son according to the website). I'm definitely going to buy a license now ($99) and ditch the 32-bit manufacturer's software.
Software like VueScan and USB Overdrive (just bought a license for that too $20) deserve to be in some sort of Apple Hall of Fame.
Careful now. Scanner manufacturers would have you believe that's nearly impossible unless you remember to make the appropriate sacrifices under a full moon on a marble altar.
And how much they tolerate it, as it's so embedded in their engineering culture and I imagine "backwards compatibility" is drilled into your face when you start working on Windows at MS.
It's not easy to get into the mindset of fixing every problem a 3rd party app creates.
Some will say Apple is offloading tech-debt onto client apps, but Microsoft is allowing client appts to offload tech-debt onto itself, and it's big enough to take that burden on so its users can still use the stuff they bought.
I dunno, sometimes I hate having to do it but it's all about user/dev experience and if you're optimising for your own employees you're making it worse for everyone else who makes your OS/machinery worth buying. There's got to be some compromise, coz it sounds like if you buy into Apple then you're SOL if they can't be bothered supporting your hardware.
Which, additionally, must contradict their environmental aims. It's not good for the environment if upgrading an OS means you throw away your printers and scanners and buy compatible ones.
As a developer who strongly advocates for and strives to maintain backwards compatibility whenever possible (and even when it isn't so easy...), I can say that it's unfortunately something the vast majority of (younger) developers today don't even think about, much less care for. Perhaps they just haven't experienced stability nor noticed it enough in their daily lives, because all they seem to care about is "new and shiny" and rewriting things constantly.
I have written various (Windows) utilities over the years, and some are over 20 years old now and I use them every day. They worked on Win95, they still work through to Win10. They're all tiny single binaries that require no installation, start immediately, and are extremely responsive and low on memory usage. Ironically, it's almost impossible to do that with a "modern" toolchain now, and I'm not even sure if something like that would've ever been possible with the Mac. To me, the idea that backwards compatibility is a "burden" is absurd. Constant churn is a burden. If I had to go and "fix" all my utilities every few years because a new OS broke something that was working before, I would have less time for actual new developments. Instead I can continue to use them and write other things as the needs arise, instead of wasting the effort redoing things that should've still been working. Just "leaving well enough alone" is a big part of it.
The kind of simple utilities you are talking about would have also been pretty easy to maintain/port from OPENSTEP in 1996 through to current MacOS. Apple's offered pretty good source-level compatibility for the basic stuff, and an easy migration path for tooling. Recompiling something every few years isn't a "constant churn" sort of burden.
> There's a lot of stuff out there that's not maintained, but is still useful.
I can't see how this is Apple's problem. Holding up development of a platform and technical progression generally for unmaintaned software is not a good working model for anyone, no matter how useful it is.
> So "recompiling every few years" is a pretty big burden.
As is "supporting everything ever implemented in perpituity"...
is not a good working model for anyone, no matter how useful it is
WTF!? You've just perfectly illustrated the attitude that's making technology worse for everyone.
What are computers for? "To control and force users to consume mindlessly" might be an accurate depiction of reality today, but that's not what they were originally invented for. Computers were intended to assist people. As the early (1930s-40s) promotional material would say, "to come to the aid of mankind". The whole point of a computer is to be useful to its users, so arguing against that is just nonsense. This discussion item is full of other comments stating exactly what sort of work they use a computer for, and how they are being affected by useless changes.
Most people take it for granted just how stable a lot of other things --- also invented to help them --- they use on a daily basis are. Imagine if every few years, your toilet, sink, bathtub, light switches, power sockets, door and window handles/locks, lightbulb sockets, and home appliance controls changed in such a way that you had to completely relearn how to use them and without some functionality they had before, and all for totally BS reasons like "development of a platform and technical progression".
As is "supporting everything ever implemented in perpituity"...
>What are computers for? "To control and force users to consume mindlessly"
Nonsense. I never suggested that. What I am suggesting is that whining about progress (especially when it has been known to have been deprecated for at least the last 10 years!) and layering technical debt on top of technical debt is stupid. I do agree that somethings don’t need to change, but are absurd, not to mention inaccurate. The many types of different light fittings for example are evolving. Somewhat more slowly than computing, I grant you. The same is true for locks and light switches are being developed too. Your comment about home appliances is By far the most ludicrous. I do take issue with your notion that things in Catalina have changed to the extent that they need to be relearned. Bullshit.
> If I had to go and "fix" all my utilities every few years* because a new OS broke something that was working before, I would have less time for actual new developments.
>There's got to be some compromise, coz it sounds like if you buy into Apple then you're SOL if they can't be bothered supporting your hardware.
I think part of the idea is (and how they see it), if you buy into Apple, you should have enough spare money to upgrade your hardware as needed. This sucks for us which are not exactly affluent, but that's part of the thing. Apple never tried to maximize affordability or expenses.
(Though in some cases, they have been the more affordable of the bunch, e.g. when the iPad was announced, it took about 2 years for competitive machines to reach price parity. Or now, e.g. the newly announced MS earbuds are more expensive than airpods).
It's not a platform for long term support and maximum bang for the buck, it's a platform for user convenience ("it just works, mostly"), inter-operation ("things -phone, earbuds, speaker, watch, etc- just work together, mostly"), and cohesiveness ("things have a unified vision, mostly"), plus polish (thinking some things more through in their design -- not always though, e.g. BS MBPr keyboard).
I use "mostly" above in the sense that it's not obviously perfect (and some areas far from it). But the tradeoff is in the areas mentioned above.
fwiw, upgrading to x64 windows killed 16-bit support, I think? But as far as I know that was due to architectural limitations as much as it was an intentional choice. It's still impressive that 16-bit stuff kept working on x86 windows basically forever.
Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16. That's just a limitation of the cpu architecture that's just not something you can work around. Dosbox and virtualization however do allow that to still be run if you provide the OS bits (install windows 95 or 3.1 in them), so there's still paths forward that will usually work. If they need to talk to esoteric hardware then you might be out of luck still but it might not be impossible to get that to pass through depending on what it is.
> Yea it's not possible (in a way that works without breaking stuff) to drop from 64bit to 16bit the way you can with 32 to 16.
Yes, it is. It’s almost exactly the same. What you can’t do is run v8086 code on a 64-bit kernel without using a VM, most of the code people care about is 16-bit protected mode code.
I maintain the messy but small amount of Linux kernel code that makes this work. It is, indeed, gross, because the x86 architecture is awful. But it works fine in practice and there is quite a good test suite these days to exercise the ugly bits in the kernel tree.
As with a lot of other things, the truth is a bit more subtle than "it's impossible" and closer to "we didn't care enough to try hard enough to make it work":
If that v86_64 thing works the way I think it does, it is not really an acceptable way to do this. If you drop the CPU down from long mode to legacy mode and get an NMI, either you are toast or you have some extremely complicated awful code to handle it. Not to mention that the CPU can’t even address all of physical memory when you do this.
Just don’t go there. Use an emulator for DOS code and use the normal kernel support (modify_ldt()) for 16-bit protected mode.
Honestly kind of surprised they didn't just build a subtle Windows 3.1 wrapper that would launch to run 16-bit apps, combining the view-of-the-system virtualization approach of WOW64 with ABI translation ala Rosetta.
Windows NT setup programs were traditionally 16-bit because every version of NT could run 16-bit x86. The non-x86 variants (alpha, mips, etc.) had built in emulation.
So Microsoft has already got the ability to run 16-bit Windows apps in emulation. It's a shame they didn't enable this on x86-64.
Maybe not much help to you, but my Rollo Thermal Label Printer works fine on Catalina. Didn't need to update any drivers, it just works as it did before the update.
VueScan works, but it is stupidly bloated compared to the macos native scan tool.
I remember how it was so easy to scan directly to multi-page PDF with my Brother portable scanner. The Apple build in capture software was just so easy and clean to use. Then Apple removed TWAIN support in snow leopard, and suddenly my 2 month old 400 euro scanner was no longer usable. :(
As a long-time macOS user, I don't upgrade to a new version until x.y.5. I've just had too many issues over the years, with stability and application compatibility. Of course, for development, I install it into a VM right after release.
As a long time macOS user[1], I've always installed on public release and I've only ever experienced issues maybe once or twice. Rare enough that I can't think of any specific issues.
[1]didn't really pay attention to version numbers before 7.6, but I guess "install on public release" didn't begin until OS X...
I'm not a macOS user, but if the situation is anything like on Windows, then luck has nothing to do with it. The updates by and large work just fine for almost everyone, but with such a widely deployed product you inevitably will still see hundreds or thousands of people that experience issues.
It looks like waiting is not going to help in this case. It’s not like 32 bit apps were accidentally broken. When Apple kicks something to the curb they do it forever. I’m probably stuck on Mojave for good.
Logic and Numerology. More so for Numerology, if I'm being honest. I could probably get along with any DAW after the initial learning curve. Plus, I make heavy use of IAC Buses. But, I believe there's a Windows version that people use.
This year all their OSes seem to be riddled with issues at release.
- iOS 13.0 was so bad they released 13.1 in less than 5 days, but even now many things are still hit and miss (with 13.2 in beta)
- watchOS 6.0 is also still pretty bad and not yet fixed (with 6.1 in beta)
- macOS 10.15 GM seems pretty buggy
- Well, I think tvOS 13 is ok?
While the situation might be better for people who use the latest betas, it is still a horrible current user experience for all normal users just updating their devices.
Lots of cross-platform features introduced across these updates (like the new iCloud features and new Reminder apps, etc.) are also in a horrible state.
I'm not sure what their QA team is doing this year but it seems almost everything planned for this Fall would have been better off if pushed back a couple of months. Well, if it weren't for device compatibilities... (the iPhone 11/Watch 5 seemed to be more important than stable software across all their platforms and other devices)
The question is what is Apple doing in their software development? From the outside, it looks like there are glaring issues within their engineering teams.
iOS 11 was a complete disaster and it took an entire OS upgrade cycle (iOS 12) to control the most pressing issues. Apple is constantly releasing wild bugs and after getting burned multiple times now, they still don't seem to tackle this internal problem.
The theory about the iOS 13.0 is that Apple was forced to updated to this buggy iOS version because of Apple Watch release. Watch was shipped with watchOS 6.0 already installed and it requires iOS 13. iOS 13.1 was still not finished and to prevent situation where new watch customers couln'd use it after the purchase - they needed to update as it is.
That I was hinting at in the last sentence. Apple Watch 5 and iPhone 11 came out on the same day and needed watchOS 6 and iOS 13 respectively, so basically, those hardware releases forced the buggy *OS to be released across all platforms and devices.
Comparing iOS 10~13 with macOS 10.12~15 release dates, macOS seems to always come out 7 days after iOS.
This year it has been 12 days after iOS 13.0, instead. Wouldn't really call that much of a push back. It's less than one week behind the usual schedule..
Thanks for sharing. I would have upgraded for the sidecar capability, but if things are still dicey I’ll wait it out. And like you, I also have a super old version of Word, so will have to switch to Pages. I wonder if this OS update will result in a spike of Word upgrade purchases.
Keynote is amazing, in my experience. I mostly present from my computer, so I don't need to worry about PPT compatibility. I find PPT to be unusable/prehistoric by comparison (when I try to help my wife with it on her computer, which is running a current version).
Glad to know that Pages does a good job as a Word replacement. I do track changes pretty frequently and have wondered how solid the support/translation is for that feature.
The origin of Keynote is supposedly the requirement to create Apple-keynote-ready presentation software that would pass the extremely specific and persnickety Jobsian requirements for aesthetics and attention to detail in an age of Powerpoint dominance. Updates notwithstanding, Keynote shows its age — but all these years on, it still produces great-looking presentations.
Some great applications. I would love to have a direct port of all of them today. Of course I also want the shelf back and I want my menus on the side like NeXT. Oh well.
Keynote was created so Steve could have something that worked and looked the same as Concurrence. He would use his old NeXT to create presentation until Keynote.
Try opening presentation you made a couple of years ago. Might not work. A colleague of mine ran into this, he couldn't open files created with Keynote a couple of years back.
I do recall a changeover around 2009 — was this a presentation more recent than that? I’ve had no problem with this and have used Keynote since it came out (and was a paid application, not free!)
I believe iWork '09 was the final lineup of the original Mac codebase. After that, they basically back-ported the iOS versions to the Mac and from then on had a shared codebase, file format, and feature updates were pretty much in lockstep across Mac and iOS.
My favorite feature of Keynote / Pages is that the equation editor is simply a native LaTeX editor. You have to wonder why Word didn't simply do this in the first place
Pages is the only word processor I know of that refuses to open documents that it created just a couple years prior (version 5 would refuse to open documents created by version 3, for example).
If Pages works for you, great: but save a copy in a different format if you want to be able to edit it in a couple years.
This is exactly the mentality this entire thread is about! Here we see it clearly demonstrated in another product. Apple says "update, upgrade or you are dead to me."
I have been stuck multiple times with users upgrading Pages two versions later on a desktop and then unable to read on their laptop or vice versa. Inexcusable!
Numbers is actually the best spreadsheet for stuff where presentation matters. For example, me and my friends use it for our D&D (and invisible sun) character sheets - the formula language is powerful enough to do what we need, and its ability to manage multiple tables per sheet is uniquely powerful.
And the icloud version of Numbers is pretty handy when you don't have a Mac around (but the collaboration capabilities suck compared to Sheets).
Excel does support multiple tables per sheet through the format as table (?!) feature. But yeah, still hard to make those multiple Excel tables look good with sheet-wide column and row sizes.
I believe the Office-idiomatic approach there would be to create one Excel file containing multiple sheets, and then OLE-embed a view of each sheet into a Word (or Publisher) doc. Lets each tool do what it's good at.
I think for the way most people use excel it’s adequate and in some ways superior (e.g. I made a cute weekly chores-tracking sheet with photos on it for the fridge), and presume that’s why Apple appears to have stopped work going on it.
If you’re even a halfway serious user of Excel than indeed, Numbers is a complete joke. But if google sheets would work for you numbers probably would too.
Sheets is actually pretty powerful. I can do 99% of what I used to do with Excel. Numbers is way under-featured in comparison. I would categorize Numbers as “family-friendly” and Excel and Sheets as “business-friendly”. Only Excel gets “finance-friendly” and I’m not sure about that anymore. My finance partners now deliver all my budget read outs via Sheets.
I think Numbers is a great spreadsheet application. It just doesn't even try to be the kind of spreadsheet application that can be abused as a poor man's DBMS.
For simpler tasks where a spreadsheet program is obviously the right tool for the job, Numbers tends to be plenty capable and give a nicer user experience than Excel and clones. For example, a few weeks ago I discovered that Numbers is vastly better at doing time-related calculations than Excel.
Numbers fails completely when you start moving into the problem domains where a SQL database and/or scripting language are good tools to consider.
I ran into serious problems with Numbers (it just wasn't good with them, and broke some of my existing spreadsheets...), and I didn't like Pages because it makes it a serious pain to work with or save into MS .docx or rtf, or anything other than pages format. I found Libre Office to be waaaay closer to the office suite of tools I was looking for on my MBP. (and less buggy, believe it or not).
> I wonder if this OS update will result in a spike of Word upgrade purchases.
Unless you use some of the very special features of Word, or you're in a profession that requires Word docs specifically, Pages is a very good substitute. It can even open old Word docs (and new ones too).
I haven't tried Sidecar yet because the iPad is on my wife's iCloud account since she's the primary user and I'm not sure how to make it work across iCloud accounts, or if you even can. She uses it so much I can't get my hands on it!
> Why is removing a feature better than letting run a bit slow?
If a restaurant runs out of food, there are gonna be some customers who would eat a turd sandwich, as long as they could eat something, but most customers would flip out and demand to know who would think shipping that out of the kitchen was okay.
Now the analogy isn't perfect, but I imagine there's a host of reasons around expectations of support and experience that Apple has no plans on addressing for those cases, and rather than having a lot of time wasted clogging support with something that will just frustrate the average customer regardless, better to leave the few complaints about why they can't have it, since after all, your complaint doesn't cost them a dime in potential support calls. Just a vague feeling like you're not getting everything you want for the price you're paying.
If you've ever been to Disneyland, you can see historically, the park is jam packed with people who have that same frustration, each a paying customer.
If my assumptions on their product calculus is correct, I know which of those options I'd choose, from a business perspective.
If your mac is older than 2016, forget about sidecar. They deactivated it for every device fabricated before 2016.
For the 2 first catalina beta, you could still activate it with 2 command line in the Terminal, but these mother* removed the ability to do so in the third beta.
That's how I know Apple don't give a shit about me and my 2015 macbook Pro unless I pay 2000€+ every 3 years.
That’s such a bummer. I’m still using my 2014 MacBook pro because of all the keyboard nonsense, but was actually excited for this feature. Is there a technical reason or just typical Apple BS?
dude, Libre Office wipes the floor with Pages, Numbers, etc. If you haven't tried open source office programs in the last decade, they've come a long way. And I find they work better cross platform (ie they save in MS office format much more seamlessly and less buggy)
I use Media Rage to tag my mp3 since ever, and there is no hope that it will be updated. The application does just what I need.
I am also about to buy RockSmith on Steam, but it's 32 bits at the moment. I currently used it on my PlayStation but want to have it on macOS to access more songs.
It looks like you find many games on steam that are 32 bits only.
On our side when OS X was introduced we trusted Steve when he said Carbon is there to stay and will be 64 bits. We took a few years a few years ago to do the switch...
After the upgrade every time after sleep, a window pop ups saying "Verifying Dropbox" and it takes 30-50 minutes before it completes verifying. I don't get it. Why does it has re-verify the same binary over and over again. I'm really disappointed in this release over all. Also, ejecting a application freezes and ask to force eject.
I'm on Word/Excel/Powerpoint 2016, which isn't even the latest version, and it's 64 bit. So, you might be due for an update. I've noticed complex excel spreadsheets are much faster on 2016 vs my previous version so it might be worthwhile anyhow (or run it in VM if you want to keep using it).
I had the same CPU issues. It turned out to be some bug with the iCloud sync. Constant updates also ate up my phone’s battery and storage.
Turning off iCloud capability stoped the insanity.
Have been using Apple’s betas for years now. This season was the first time I regretted it. But I like telling myself that dark mode and iPad OS multitasking made it worth it.
Some UX improvements across the board are very neat though.
I'm pretty much stuck a couple versions back now (last rmbp with NVidia graphics, mid-2014). Really wish they'd let NVidia release drivers for the last two versions again.
In the end, new desktop runs Linux, and aside from a few issues for brand new hardware, it's been a nice change of pace.
It doesn't work correctly, no. Apple stopped allowing signed Nvidia drivers starting with Mohave and the drivers from Apple for the device are buggy and cause issues.
Maybe the driver issues you experience are resolved in more recent macOS versions. I run macOS 10.14.6 on a Mid 2014 MacBook Pro with GeForce GT 750M. No issues here.
possibly... I don't actually use my laptop, and when I did my hardware refresh a couple months ago, I went linux from my older hackintosh (nvidia gtx 1080)
Current versions are. But, if you bought CS6 outright when Adobe switched to a cloud subscription model then CS6 is not going to work any longer (it's 32 bit).
That's the boat I am in. I can afford their cloud subscription but out of principle I will try their main competitor first (Affinity: $50 one time purchase). I will try running it in a VM second. Only if neither of those solutions are satisfactory will I pay a monthly fee for software that I use very little.
> I've had to use Pages instead of Word and can't use Adobe products anymore
And this "doesn't seem too bad"? These are the industry standards for productivity. Pages on the other hand is only good for throw-away projects. Last time I checked, importing and exporting to Microsoft Office sucked. So, Catalina pretty much turns your professional machine into an overpriced netbook.
Microsoft/Adobe will of course eventually release 64bit versions of their software. But these will cost extra $$$ on top of the premium you have already paid for Apple hardware. A lot of money with doubtful productivity gains. This won't make any professional happy.
I was pretty sure I got 64bit warnings for both of them fairly recently. But looking at the binaries now, they're both 64bit indeed.
Still, I'm running both using a site license from my work. The upgrade cost per user in site licensing is pretty low. If I had to pay myself for a single license, I'd bet I wouldn't have upgraded for eight years either. And the Office/Adobe CC subscription costs may not be insignificant either, depending on where you live.
With good reason, too. A good portion of the Native Instrument software packages won't install because the installers themselves rely on 32-bit helpers. A savvy technical user can work around it by unpacking and excising the problematic portions from the installer scripts.
On the plus side, I've been running Kontakt 5 along with lots of other audio software since 10.15 beta 3 every day and most everything is working alright.
Some other observations:
• Pro Tools' QuickTime video plug-in prevents it from launching because it's a 32-bit only subprocess meant to interact with the now-defunct QuickTime framework. You can delete the plug-in from the application bundle and it will proceed and seems to be working normally.
• EastWest has a nasty crash in PLAY 6 that can be worked around temporarily by removing their internal word builder plug-in.
• Pretty much every iZotope plug-in as of September had a 32-bit non-pkg installer. The software works fine if you copy all the relevant parts from an install on another computer.
• MOTU hardware drivers for anything but the latest Pro Audio line won't work as the drivers are 32-bit at the moment (MIDI interfaces, CueMix-based audio interfaces).
Waves sent one out last month as well. Par for the course really. Audio pros are some of the most distrustful users w.r.t updates because they've been burned so many times.
As a former developer of pro audio apps at Native Instruments, sometimes it's just that the first version of macOS updates has bugs that suddenly causes crashes in your lower level OS calls or unexplained latency. If something like this happens, users mostly blame the audio devs and not Apple. So, if you don't want to ruin your reputation, you better warn, test, wait, hope and fix (maybe not in that order).
I think that's unfair to audio developers. You're asking for a real-time scenario from an obvious not real-time OS. Dropping audio is a lot more obvious than dropping video frames. Audio also deals with /a lot/ of plugins both hardware and software--many paid (years ago and now abandoned). Most people I know with an audio setup are very sensitive to physical changes due to subtle problems.
I also think it's unrealistic for large applications to be 100% ready on day one. It's not like Apple has a GM ready weeks ago. Betas are known to change and nobody really knew when Catalina would ship (many people are surprised they're shipping what they have).
Audio software is very hard to get right and it's a relatively low margin business. Asking them to track new OS releases on day one is just not realistic, especially when Apple has a pretty bad track record on stability and maturity of x.0 releases of macOS.
Could be, but when the new OS updates every 12 months they can either dedicate a whole chunk of their time updating to the new version, or make it work good on a version that's still going to be supported for 3 or 4 years so they can focus on bug fixes and updates.
Just because Apple can bump out a new OS version once a year doesn't mind these app developers have the same bandwidth to keep up the chase. They have plenty of other priorities.
Or you could see it as your OS breaking lots of software you depend on and then telling you tough luck.
As a user I only see "OS upgraded -> stuff broken". I'll blame the OS for that. All finger pointing and shoulda/coulda/woulda is not magically going to unbreak things,rolling back the upgrade will.
And why would they care to improve when they know their user base will let them get away with it and even side with them against Apple ? Reposting a comment I left elsewhere in the thread :
For the most part, it's not a technical issue at all but a cultural one : pro audio users are notoriously, almost pathologically conservative when it comes to software upgrades.
You'll find plenty of threads on forums like Gearslutz, asking for tips on how to downgrade brand new Macs to an older version of macOS that doesn't even support their hardware. Or 2019 threads asking if it's now safe to upgrade to High Sierra. They're typically 2-3 versions behind. Why ? Older is just safer, better in their worldview.
In that context, audio developers know they have customers on their side against "evil Apple that's always breaking everything for no benefit", and they get away with emails that read like Apple just unexpectedly dropped a bomb on them without notice, and it'll take them 6-12 months to get ready, like WWDC and 3-4 months of developer betas never happened.
As a MacOS audio developer who supports legacy machines to this day, there's some truth to what you say but you're glossing over important realities: Apple has a long-standing pattern of revising developer tools to throw away support for working machines, and then requiring you to use their newest developer tools for current development.
It's a technical issue. It's a bear to support older systems from newer machines. (it's a lot easier to support current stuff from dawn-of-time old systems! I keep an antique laptop to code on which allows me to support EVERYTHING all the way back to PPC Macs. Which I do support)
My choices of what I choose to buy (in Apple hardware) or even CAN buy are conditioned very much by this reality. I'll get stuff if there's a fighting chance I can build a working ecosystem on it. I'll be willing to do things like ditch Logic and switch to Reaper, and I'll be well within my rights to tell users 'this is what I can offer, and this is what I cannot'.
Because Apple is not automatically my ally. It can be my adversary, even when I'm doing its bidding (I was fairly early in porting my entire product line to 64-bit when few others bothered. Apple literally called me and offered to help me do this, so I told 'em I'd already done it three months before. I did NOT tell them that I continued to support PPC machines or maintained a time capsule dev machine as the only way to develop for a large range of cheaply, easily available hardware)
Users have every right to side with me against Apple when I'm an open source developer letting them do professional-quality audio work on computers costing only a few hundred dollars, and/or letting them continue to use known-good and predictable equipment, and Apple is locked in to a course of action requiring it to churn its userbase at whatever cost to the userbase.
I totally get Apple's motivation here, but it doesn't serve my customers.
OS X's CoreAudio is still an incredibly well-designed technical architecture, designed by a team who really understood digital clocking from a hardware perspective and the importance of low-latency kernel support. It's still kind of amazing to me that it was essentially fully baked by 2002-2003. On Windows there's now WASAPI Event, which has a similar architecture, but for the longest time third-parties had to step in with a third party solution (ASIO) because the OS support wasn't there (and ASIO really only solves a subset of the problems CoreAudio solves). I'm frustrated by how little attention the driver and documentation side of things has gotten from Apple since then, but for some specialized requirements the underlying architecture is still just fantastic.
Audio people have been moving away from Apple over the past few years specifically because of show-stopping bugs introduced by new versions of the OS. This really never happens in Windows now and it's become more and more appealing to switch.
macOS has had a reliable low-latency audio API for years, when on Windows you had to resort to third party hacks like ASIO.
For years it has also had things like Audio Midi Setup, which lets you set up aggregate virtual audio interfaces from physical ones, dealing with latency compensation etc.
Or MIDI over Bluetooth. All of that out the box. It just feels it's been designed with pro audio in mind, compared to Windows.
Aside from the other replies you’ve already received that are spot on, macOS has also been consistently good at isolating the audio ports from coil noise / interference from the other electrical signals on both laptops and desktops. While “pro” audio folks are likely to be using an external audio interface anyway, having an audio jack that doesn’t garble the sound is one of many ways that Apple hardware engineers have been attentive to audio.
That's fair. Pro Tools crashing during a session has been a meme for awhile, despite it being pretty stable for the last 5-ish years.
But keep in mind these companies are usually pretty small, a lot of sole-proprietors out there, and their revenue comes from new products/sales not maintaining projects. So there's logistical and incentive problems in deploying fixes quickly.
The writing has been on the wall for 32-bit for literally over a decade and it’s not going to magically happen now just because support has been dropped.
Imagine digging up an old project, recompiling it for 64-bit, and finding out that:
1. It doesn’t compile any more, with modern tools.
2. When you get it to compile, it crashes mysteriously.
3. When you get it to run, it again crashes mysteriously when you try a 64-bit build.
Yes, there are a lot of “best practices” out there to avoid this. Any discussion of best practices is moot because people in the field have to work with actual practices and legacy code that might be full of undefined behavior, custom build systems, weird hacks, and lost tribal knowledge. And you are simply not given enough time to go through and fix it.
This is not all about the 32-to-64 bit transition, but that’s the biggest part.
Then consider the smaller shops—which might only have a couple of Apple devices altogether, and not a lot of spare developer-weeks to go through and test old plugins on new systems.
One of the big ones is that integer constants are 32-bit on LP64 / LLP64 systems unless they are large enough, so e.g.
// Equal to 0x80000000 on ILP32
// Undefined behavior on LP64 / LLP64
size_t max = 1u << (sizeof(size_t) * CHAR_BIT - 1);
// Correct version
size_t max = (size_t)1 << (sizeof(size_t) * CHAR_BIT - 1);
This can also happen with e.g. multiplication
#define K 1024
#define M (1024 * K)
#define G (1024 * M)
#define T (1024 * G)
// Undefined behavior, on both 32-bit and 64-bit.
size_t max_object_size = 10 * T;
// Correct version (#1)
size_t max_object_size = 10995116277760;
// Correct version (#2)
static const size_t K = 1024;
static const size_t M = 1024 * M;
... etc ...
Or if you need to align your pointers for some reason, so you do the cast correctly (with uintptr_t) and get
void *align_ptr(void *p) {
// Mask is 0xfffffff0 on 32-bit (correct)
// Is also 0xfffffff0 on 64-bit (mistake)
return (void *)(((uintptr_t)p + 0xf) & ~0xf);
// Correct version
return (void *)(((uintptr_t)p + 0xf) & ~(uintptr_t)0xf);
}
Consider that you might do some pointer alignment e.g. to work with SIMD. This stuff isn’t so crazy and if you haven’t been targeting 64-bit, a lot of it can creep into your code base over the years. Legacy projects may not compile even remotely cleanly with warnings enabled, it’s just a fact, so even though warnings / static analysis will catch some of the errors above you’re not safe.
This is why so many languages have stricter rules about converting integers to narrower / wider types.
I was hoping for some real life examples from some games and reasons why they’d use something like pointer arithmetic in such a way or so often it couldn’t be easily migrated, or why they’d even do it in the first place on a desktop machine. I get the old software.
Of course basic examples between 32 vs 64 are easy to find. I guess I should have clarified as the OP sounded like he knew the topic well.
I’ve never dug hard into C++ gaming architectures and the patterns they use.
In my experience a far more common and much harder issue is dealing with dependencies.
A large project probably has lots of them. If you are lucky there is a 64 bit version of it. Very often though there isn't so you have to find something equivalent and rewrite all interactions with it.
And there might have been very good reasons for choosing those specific dependencies.
That can take ages upon ages and can be quite demotivating. You might have issue even finding out if you have any problems in your own application after you've spent months on replacing dependencies.
It doesn't matter why they decided to. They did. We all know better, we can all point fingers until we are blue in the face, but that doesn't change that people will lose access to software that they purchased.
> except in a well-contained module?
This is probably one of the best reasons. Game developers aren't entirely to blame here, middleware developers seem to be sticking to 32bit like balsamic glazing. Even if you could pry their cold dead hands off their archaic architecture, they'd probably make you pay full price for the 64bit upgrade.
As for DAWs? Think about all the the VST plugins out there. Most of which probably aren't maintained and only exist as zip files on the artist's dropbox.
Dropping 32bit is aspirationally sound. It's grossly inconsiderate of the very most obvious aspects of reality.
I think that's reasonable if we were talking about a tighter time-scale, but we're talking about at least 13 years since it's been 100% obvious that macOS would become 64-bit.
Yeah, but 64 bit doesn't give your users anything usually, so it's a tax that is more of a drain on smaller software shops. Especially consider that lots of programs and especially games have a spike of sales when new and then sales decline to nothing. There may not be new versions, ever. So going back and updating them is pure loss for the developers.
This is one reason why ecosystems like Java are so valuable! The 64 bit transition was so easy for it because of the common insistence on "pure Java" for portability. Combined with pointer compression 64 bit was hardly noticed.
For many audio hardware drivers, it's not simply a matter of recompiling to 64-bit.
Apple has deprecated a lot of things and seems to be trying to move everything over to AudioServerPlugins, which essentially requires a full rewrite of the drivers. The architecture isn't similar at all (AudioServerPlugins actually follow a Microsoft-style COM interface, among other things). I don't even think Apple makes any sample code for updating old Firewire drivers to run on Catalina, so it's a tough slog, and low-level CoreAudio expertise to update old drivers is getting scarce. Traffic on the CoreAudio developer mailing list is down to less than a dozen posts most months. There hasn't been a single post to the mailing list yet in October.
I strongly suspect that some interface vendors are not going to update their 32 bit drivers for Catalina. (MOTU in particular is one, which kind of marks the end of an era because they used to be champions of some of the best CoreAudio features, like Firewire clock syncing.)
As a independent dev I would rather spend my time working on new features and projects on an OS where my older projects continue to work fine rather than spend my time constantly playing catch up with Apples policies. This combined with the notarization requirement has pushed me to stop developing for Mac OS.
This isn't just an OS thing, though, so I think that's crap. This change is a hardware change that's been forecast for literally years. To dismiss it as "playing catch up with Apple's policies" is nonsense.
You have a point, but another thing to note is that the quality of Apple’s developer docs for audio drivers and CoreAudio has been decreasing. Some major behaviours/quirks of new frameworks like AVAudioEngine on OS X are not documented at all. It’s a lot harder to chase the target than it used to be. This is IMHO one of the likely reasons that MOTU chose to implement as much as possible as an on-device web interface on their newer gear.
As a former MOTU engineer who worked on the software side of the new interfaces, the built-in web server was really about cross-device and multi-user access, not avoiding CoreAudio. We still had to write CoreAudio server plug-ins for Thunderbolt and proxy the web server through the driver as well.
I hear they are planning to update their 32-bit drivers for the older MIDI and audio interfaces with the exception of the PCIe devices. (There are no existing Macs that can run Catalina and the old PCIe interfaces with the exception of the new Mac Pros, but there will be no driver so...)
MOTU just released a statement indicating that they’re only working on new drivers for the hybrid and newer devices. Firewire gear like the popular 828mk3 classic aren’t getting drivers.
AVAudioEngine is not a new framework on macOS. It was first available on macOS Yosemite which was in beta in 2013 and released in 2014. Developers have had 6+ years to develop and test using these frameworks.
This literally just boils down to developers complaining that Apple isn't further letting them procrastinate.
That illustrates the problem though... It’s not a new framework, but the documentation is still poor, and important limitations of it on OS X are not documented at all, years later. (I picked this example specifically because it was a subject of traffic on the CoreAudio mailing list last month.)
Apple expects developers to adopt new technologies, but often never gets around to documenting them well enough to drive adoption. It’s been a real issue for low level audio work on the platform.
"forecast for years" is distinct from "totally a good idea."
Time and resources a software publisher spends on the upgrade treadmill is time they can't spend on other efforts, whether or not there's advance notice. Essentially, it's a cost Apple imposes on developers for their platforms. And either that shows up in costs for users or the software folds.
If there's a counter to upgrade treadmill criticisms, one of the few that makes sense is if there are compelling benefits with the upgrade to weigh against the cost.
At the moment, it's entirely unclear to me what benefits I'm supposed to derive from dropping 32 bit support, and moreover, I can't think of a single compelling benefit I've derived from macOS updates since Snow Leopard.
This distinction does not seem very useful. Regardless of whether it was a good idea, developers had to decide at some point whether they should prepare for the transition or cease macOS development (unless they wanted to continue supporting old versions with a dwindling userbase).
This decision could have been made years ago. It seems to me that anyone complaining the change is too soon or too sudden is forgetting the sheer amount of time they had to decide their best course of action. It should be a question of whether to continue development at all, since that should include a transition to 64-bit. If not, then deprecate the project.
I understand may situations will not be this black-and-white, but it seems like many of them are.
> anyone complaining the change is too soon or too sudden
Notably, that's not my complaint or my point. This isn't about the timing (which is why the distinction was important).
No matter how much time someone has to prepare for a change, there's a cost to making it. And if the benefits of the change don't outweigh those costs for the developer (and the user), then a complaint sure makes sense from those perspectives.
This does intersect the issue of timing, because in a resource-constrained situation, you inevitably have to defer some efforts until they're absolutely necessary (and simply rule out doing others). But timing is not the fundamental issue, cost-benefit tradeoffs are.
> [development] should include a transition to 64-bit.
Why? What's the benefit to ending 32 bit application support?
> This change is a hardware change that's been forecast for literally years.
Huh? What x86 processor doesn’t support 32bit code?
If they move to ARM, everything will get broken, regardless if whether it’s 32bit or 64bit. Is breaking things twice really better than breaking them once?
That's the wrong question to be asking. The relevant hardware change is when x86 CPUs that don't support 64-bit code finally disappeared from the market and eventually from the install base.
There is only a very narrow range of use cases for which running 32-bit code on a x86-64 processor is preferable to running the same code compiled as 64-bit. For everything else, going 64-bit is a clear improvement if not an outright necessity. Even if it didn't require any ongoing maintenance, continuing to ship 32-bit versions means wasting storage space and network bandwidth, and leaving on the table the improvements enabled by going 64-bit (eg. better ObjC runtime). For the entire existence of x86-64 processors it has been clear that retaining 32-bit compatibility through the entire software stack has significant downsides and that the cost/benefit balance has been inexorably moving toward eventually dropping 32-bit support.
BBEdit is not a real time audio engine. It’s a text editor. And they’ve released thirteen versions which all require a relatively substantial amount of money to upgrade.
Isn’t that also a good thing - that a company has a business model that allows them to keep supporting an app for almost two decades?
What alternative would you prefer? That Apple ships the latest MacOS with a 68K emulator, a PPC emulator, all of the 32 bit libraries, classic MacOS in a VM, and all of the Carbon libraries forever?
Apple isn’t exactly known for backwards compatibility.
I could never justify a long term hardware life knowing that I’m signing up with a short term software life cycle. Not only a short term software lifecycle, by a short term computer hardware/OS lifecycle. Want more memory or a faster processor? Not with that old OS! Btw, you have to rewrite all of your software if you want that extra memory.
Assuming the vendor is still in business, still supports the product line, and still develops software updates for models that have been obsolete for over a decade.
And they shouldn't have to. Developers should support their working equipment by updating drivers. They've known about the transition to 64-bit for years and it's not something that can just be ignored because all the hardware is now 64-bit. It's not like this was done on a lark.
This was addressed earlier in this subthread. It's not just an upgrade to 64-bit — they're also changing the low-level interfaces, and the new ones are apparently not well documented. So while it probably wasn't done on a lark, it doesn't sound like it was done in a very well considered manner either.
True, but a lot of those devs ignored the 32- to 64-bit transition for so long that now they're having to do both at once. Authors that moved to 64 bit several years ago have a lot more free time right now to concentrate on supporting new APIs.
The low-level interfaces in question were changed almost 4 major versions back. There aren't any new interfaces or APIs that haven't existed for 6+ years already. The only people complaining are the ones that procrastinated because Apple continued to support their outdated apps.
Apple introduced new low-level interfaces four major versions back, and Apple couldn't work up the interest to document them in the intervening years, and then Apple decided to cut off the interfaces that are documented, and somehow any problems resulting from this sequence of choices Apple made are the fault of third-party developers for not jumping to new technology that Apple didn't care enough to document? That interpretation of events seems a bit obsequious to Apple.
If everyone should have been prepared because this change has been in the works for so long, then surely it's inexcusable for Apple to have left the new stuff in a poorly documented state all that time. If you do feel that Apple's lack of preparation is reasonable when they had even more warning than third parties did, then it seems unreasonable to fault developers for also not being prepared.
Is there a reason you don't freeze the version MacOS, disable all the updates(if possible), disconnect it from internet to prevent the zero-day attack on it and continue using it in mojave or whatever your gear works the best with?
But the point is 32-bit apps aren't functional anymore. You either keep up by thinking ahead, or you find yourself suddenly stumped. There's no option to just ignore it.
Interesting. So it's still mixed and has disadvantages of a 64 bit program (no 32 bit plugin support 1) and of a 32 bit program (no compatibility with Catalina) while pretending to be a 64 bit program. Sounds great!
I recently updated my app to be macOS 10.15 compatible. Most of the changes were just annoying and difficult to debug, but some were glaring bugs related to Safari App Extensions which were show-stoppers. I really hope they fixed them before the release...
1) Although everything is "notorized," the Safari extensions aren't installed on app start up like it's supposed to in most cases.
2) The following API call works, UNTIL macOS wakes from sleep mode, in which case it always returns 'false.' SFSafariExtensionManager.getStateOfSafariExtension(...)
With audio hardware it’s looking like substantial rewrites to core code because of underlying is changes. I think it’s just a lot of work on a short timeline for small development shops.
I mean most software that's currently maintained has been 64-bit ready for a decade. The issue is that there's a lot of 3rd party ghostware that isn't, and 32 bit bridging to support that code has been popular for awhile.
That software is a lot like vintage gear, there may be alternatives but they aren't the same, and that's the problem.
Sounds like the software was effectively already dead and it was best to move off it as soon as it became clear there was only one developer and they were hard to get hold of. The problem isn't with macOS.
I would note Chris, given your insistence on all this, that your own project Graal is still shipping on Java 8 despite that being many years old. You're now working on moving to Java 11, which is itself already obsolete.
Imagine if tomorrow nobody could download GraalVM anymore because OpenJDK 8 stopped working for some reason (yes I know it's bundled, this is just a metaphor). It could easily be said you had years to upgrade, so why so sluggish? Well, of course, there were actual features you wanted to ship during this time too, not just doing upgrade work, especially given that Java 9 and 10 maybe didn't deliver many compelling upgrades.
Sure, but so is Mojave. It'll be some years before Apple stops shipping security updates to older releases. Until then app vendors saying "don't upgrade macOS" is no different to Java developers saying "don't run this on Java 11 because it doesn't work yet" and we've seen plenty of that.
In fact, I'm guessing the pain of losing Java 8 will be too much for many organisations after so many years of stability and 9/10/11 breaking so much (current Gradle doesn't even work on Java 13!). Maintaining 8 will be a good business for a long time.
Your software doesn't run in isolation. It needs services of the operating system. Apple has to spend resources maintaining 32-bit software and consumers would rather they didn't do that.
Going to 64 bit can be a lot of work. So there is quite some software which is still lightly maintained for which there isn't a 64 bit update available. Software which has worked perfectly fine up to date.
Only in misleading microbenchmarks. In the real world, the memory bandwidth saved by using 32-bit pointers in some programs that can be guaranteed to not need more than 4GB of memory (or ASLR or other features enabled by x86-64) is completely outweighed by the costs of keeping both 64-bit and 32-bit libraries on disk and in memory and in cache. That's why even on Linux the x32 ABI was never able to gain traction even among Gentoo users, and why retaining traditional 32-bit support is viewed as only a compatibility measure for closed-source code that literally can't be updated.
If a program works fine, with no issues, why should companies be forced to update it simply because Apple decrees they no longer support 32 bit applications? "Sweeping the dust" is an absurd declaration.
I think sidecar uses h265 so it's probably a question of the GPU either having dedicated h265 hardware or having enough grunt to run some kind of shader.
It's not just 64-bit though. There are also some fake-security "notarization" requirements that were notoriously vague and poorly documented for months, as well as some equally vague and unspecific threats that certain non-notarized applications might or might not cease to work on January 2020. I've been developing for Macs since the late 90s and have never seen less clear developer info.
Thankfully I'm not in that position, but many companies can barely keep up with their day to day stuff. There is never time for doing something for the distant (or not so distant) future.
For a game where 95% of the revenue is made in the first year after release, the cost:benefit ratio probably doesn't work out. Especially for games where the rights situation isn't clear or the publisher is defunct
Audio stuff is notoriously prone to issues with updates. This has come up continuously since Classic Mac OS in the 90s. Audio guys are even sensitive to changing their physical setup.
Outside of audio, I know of companies that ignore prerelease stuff because Apple has been known to change APIs during the beta period. It's not like Apple has a GM weeks before it is released publicly.
They have both a developer beta and a public testing beta prior to release. To ignore pre-release access to a codebase that will inevitably become the public release is, in my opinion, stupid and a death sentence. You know it's coming. Sticking your fingers in your ears on the off-chance that something changes before release is really, really silly.
"Ignore" is likely an exaggeration. It sounds like many of these audio companies have tested the betas. People have reported many, many emails over the past week pleading for them not to upgrade yet. I would think that anyone with experience in pro audio would be very careful about any upgrades.
The concern seems to be more of wasted time developing on a moving target. Often people report battery issues after major releases, people are reporting weird hangs after waking from sleep. Audio stuff is real-time in an OS that cannot guarantee it. Accommodating these things is a large undertaking and I'm sure there's gambling going on about what Apple will fix and what you can rewrite before Apple decides to ship.
But no one is saying that these companies are forcing people to move to the new OS. The issue is that there's not even an option to move to the new OS for some users because their software literally can't run. It's not about chasing a moving target when the 64-bit change was announced 4+ years ago. Waiting until the very last possible moment and then complaining that 1 or 2 APIs changed leaves no one to blame but the developer that ignored the warnings and waited to fix their issues.
I'm not talking about dropping 32-bit support. I'm talking about audio glitches that come up with every single major and minor update to macOS (or any OS). Catalina seems to be especially bad in regards to general stability.
Many audio tools have to deal with third-party, paid, and often abandoned drivers and plugins. So the 32-bit transition made for some difficult decisions. Nobody is arguing this is a surprise.
Wait until MacOS move to homemade ($$$) ARM cpu and everything you use except what is made by big publisher is broken, forcing you to buy a huge string of fresh arm software to replace depreciated x64 intel capable softwares.
In every Apple technical decision, there is a financial motivation.
a lot of developers won't update older versions of their software to be compatible either so a serious computer musician has learnt by now to stick with a system that is working
I don’t think I’ll upgrade my audio Macs for a very long time past 10.14. The fact is that after many years of recording and mixing music on computers I’ve got several older plugins that are simply not maintained anymore by the developers and moving to Catalina will certainly break any projects using them. Sucks that with DAWs unless you run a completely stock DAW without third-party plugins you eventually run the risk of things going out of date / support..
same here, i learnt the hard way when after upgrading and trying to use reason 7 again after a few months at which point i couldn't downgrade the OS at all. i essentially lost the ability to use reason at all without an expensive upgrade
I’m surprised a bunch of developers don’t worry bout breaking their development systems as well. I guess docker and such has taken a lot of the pain over how things used to be.
Both my audio macs are on Mojave now. I don’t think I’ll have any good reason to go to Catalina soon. I’d like to try it since it’s new but... too much could go wrong and it takes too long to restore backups to be worth my while.
Judging from all the "this will stop working soon" pop-ups I've seen, I'm pretty sure most of my Mac-capable Steam games will stop working if I upgrade.
There's wide reports of Ableton Live 9 not working in Catalina, including from Ableton itself... but I just updated to Catalina and it launches and works... so either I'm doing something wrong or they're trying to get people to pay for an upgrade?
Looks like it's the end of the road for my Dashboard usage. I know it's basically been deprecated for years, yet it remained vastly more useful for me than it's replacement in Notification Center
It was still the fastest way to access:
- Multiple calculators
- Multiple sticky notes
- Multiple unit conversions
- Stocks
- Weather widgets
Notification center as currently implemented is just not cutting it. The amount of widgets I can quickly access is dependent on screen size, and worse, they're moving targets! — The weather widget causes all the ones below it to shift up and down while it loads. Not to mention I can't see my notifications when in Widget mode.
What a sad state of affairs for what was once a very powerful feature.
When I four-finger swipe left for Dashboard, stocks and weather take several seconds to load, and to use the calculator I actually have to click inside of it. And visually they all look like toys that bear no relation to current OS look and feel.
Two-finger swipe-left from right edge brings up Notification Center with weather and stocks always instant (so much faster), and I use cmd-Space for Spotlight for all calculations and conversions without having to click/tap ever, just using my keyboard. And since Spotlight allows me to type complex math expressions with parentheses, I've never had a need for multiple calculators. And then Stickies has a dedicated app.
So except for multiple unit conversions (which I've never needed)... I'm personally very glad we've moved on from Dashboard.
i had been using spotlight for simple calculations for years, but i stumbled onto conversions (like "528 in2 in sq ft" or "32c") only a couple months ago. if you don't specify to the units you want, it will still give you a most likely conversion unit with less common ones down below. it's super useful and quick!
I've replaced Spotlight with Alfred [0]. Well, just the cmd+space shortcut. I've built a few "workflows", which are sort of like plug-ins/macros/shortcuts/etc. I can do things from emptying the trash to running one-off Terminal commands and from generating a randomized password to converting RGB color codes to hex. The free version is plenty useful, but I don't regret purchasing the lifetime upgrade.
I've developed my own widgets for personal use, that you can pry from my dead fingers. Or when I decide that any desktop or laptop that came out post-2009 is sufficiently not infuriating. Sincerely, have fun. And good luck. Bless your heart and all that crap.
Dashboard was a clone ("Sherlock") of Konfabulator, a third party app. It looks like Konfabulator was acquired by Yahoo but eventually shut down. Maybe this is once again an interesting third party opportunity?
I can't even recall how to invoke Dashboard. The fact that was always hidden meant I never used it.
I was the author of a Windows competitor named Kapsules back when Konfabulator was hot and before the buyout by death knell by Yahoo!. (I tried to go with Winfabulator but they didn't take too kindly to that - I was young and ignorant.)
This was a space that was useful, and then became saturated and commercialized to the detriment of usefulness. It was just before we had good off-screen rendering, right as the html-and-js-as-desktop-apps was starting to take off, and when transparency in window rendering was still difficult. I could share a lot more thoughts
Is there an opportunity to fill the void? I'm really not sure. Bear in mind that this was well before the iPhone hit and smartphone apps got huge. Most of the things we did with widgets back then are far easier done on our phones now. Kapsules had some good parity with what Konfabulator and Apple Widgets had offered, and I can't name a single widget for Kapsules, aside from the silly barking hamster, that doesn't ship by default with our phones now.
The widget craze was a fun phase of app development, and no doubt influenced UX and mobile apps, but I consider it merely an interesting footnote now. If anyone is interested in the source code for Kapsules, I can probably dig it up from one of my old HDDs. It was written in C# on .NET 4.0.
What's your take on Android widgets? I used to think they were all I ever wanted in a system only to use them less and less with every iteration of the OS, now fewer and fewer apps come with widgets, or even try to use them for something really useful. Has the user lost the appetite for at-glance desktop tools?
Great observation. I've been an Android user since the Galaxy Nexus; from my own personal experience, I think they've lost relevancy as really fast and easy app switching is available, and we populate our various launcher screens with more and more app icons/shortcuts. Apps also have really good notification bar "widgets" now that seem to be the preference (e.g. Spotify, Pandora)
I use multiple calculators for quick reference and when testing various implementations of my work, and was baffled that Apple explicitly stopped my from doing that with their stock calculator.app
This thing has been disabled by default for 5 years now.
Edit: and fun fact, if you hate Electron, don't go looking under the covers of Dashboard... it's tons of old-school web tech cruft. Fun, if you're into it.
I do my calculations and unit conversions from within spotlight search itself. I can type cmd-space "1000 yen in euro".
Also siri can be configured to have text-only input. a long hold of cmd-space will pop up an additional window where I can type "weather in london" or "time in london" etc.
I'm also sad they removed such as nostalgic feature but since years Apple is trying to remove it or at least make it less prominent. I guess its just a sign of times and how usability and trends change over the years. :(
It’s not a fundamental part of the OS, it’s a feature they pushed 12 years ago that never ever got any traction. User apathy towards Dashboard has been used as a darkly humorous but sad metaphor both inside and outside the company for many years now. Continuing to maintain things that have hardly any user adoption would be crazy. Better to take it out then leave it in as an attack surface and something that no engineer would ever want to work on. Many many more people know about Dashboard through jokes about how nobody ever uses Dashboard, than there are people who actually use Dashboard.
Similarly, someday MS will remove live tiles from the start menu. It’s inevitable, but clearly internal politics are keeping the feature around. Guaranteed that 99% of humanity will rejoice when it happens, but equally guaranteed that someone on HN will express how appalled they are that a company as big as MS didn’t choose to keep the feature alive for the sake of the handful of people who liked it.
Tiger came out 14 years ago. Dashboard has barely seen any investment since then. Calling it a "fundamental part of the OS" makes me think you're trolling. This isn't the least bit surprising.
(And I'm sure a 3rd party replacement will pop up, if there are enough frustrated users).
Dashboard was simply a way to get basic mobile apps prototyped on Mac before iOS existed. Apple does this a lot - make hay about something that's foundational to their next step.
A good example was usage of LLVM on the PPC->Intel transition which then helped when they ported OSX to ARM (ie, iOS, nee iPhoneOS).
Another is Safari (which was useful/needed on Mac at the time) but more importantly was critical in making the iPhone successful - mobile browsing sucked before the iPhone.
> A good example was usage of LLVM on the PPC->Intel transition which then helped when they ported OSX to ARM (ie, iOS, nee iPhoneOS).
I’m not an Apple insider, but I don’t believe LLVM played a substantial role in either the PPC-to-x86 or x86-to-ARM-for-iOS ports — the former was accomplished with Rosetta and a lot of bugs.
The current rumor, OTOH, is that Apple’s collection of LLVM bitcode for apps is intended to allow painless migration for applications when macOS is switched over to ARM.
Isn't that rumor solidly debunked by the fact that LLVM bitcode is strictly tied to the cpu architecure and kernel/system ABI which varies quite a bit between arm/arm64/x86/x86_64?
Has anyone been able to execute built-for-x86_64 bitcode on aarch64 ever?
I will say, however, that executing LLVM bitcode on different targets than the compilation machine is a subject of active research. It's one of the things that I work on in my day job.
Bitcode is not [12:30] a magic solution, though. You can't take a 32-bit app, for example, and run it on a 64-bit device. That kind of portability isn’t something that Bitcode can give you, notably because that is something that's visible in C. As you're writing C code, you can write #ifdef pointer size equals 32, and that’s something that Bitcode can't abstract over. It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything [13:00] magically portable.
What’s funny, is later on after Apple shipped a 64 bit chip for the Apple Watch. He admitted that forcing developers to ship watch apps as bitcode allowed Apple to recompile all of the third party Watch apps on the fly to support it, he knew that was coming, but couldn’t say anything at the time.
The bitcode requirement was driven by the Apple Watch launching with a 32-bit ARM core, but Apple knowing they would move to AArch64 3 years later and not wanting to make devs recompile their apps (or have to support both ISAs on the Watch). The ABIs were designed to be compatible, and apps in the store were statically recompiled to AArch64 for the S4 launch last year.
There are a lot of legacy apps which are still useful and not 64 bit. I have a license for Aperture and Logic Pro for instance. I use Aperture daily and it meets my needs perfectly. Now I need to find a solution. I don't see why they couldn't include an optional compatibility mode forever. Even if it were something I had to download and install.
Heads up for developers like me building Mac apps, this release is going to take a little more adoption time than most due to the 64bit-only nature of this release.
For example, I know there is a contingent of people who are stuck at Adobe CS6, whose certain critical components are 32 bit. Since Adobe no longer sells permanent licenses, opting to only rent their software instead, it's impossible to get these updated. And these expensive and still-in-use licenses are going to die the moment people update to Catalina.
It would be feasible to upgrade if you were incentivized to make it work. It sounds like some programs, particular Adobe which changed its licensing model, are not incentivized to make it work.
This is fine for the producer, who can drop support for old software. It's not fine for the consumer, who may not want to pay yearly for their software and therefore don't want to upgrade to the latest versions.
What about legacy applications which are no longer actively developed? I still use Aperture quite happily, and there's no obvious alternative (aside from Lightroom which has a subscription model).
I don't see why Apple couldn't provide an optional compatibility solution, even if it were something I had to download separately.
I've committed to just maintaining an "offline" mac for CS6 as on my 2016 Mac running Mojave I have _weird_ problems with visual artifacting using CS6.
I'm actually sad because I wanted to find a replacement that had:
- layers
- Good text engine
- good magic wand
I use Photoshop/Illustrator for very basic collage style works and those are the tools I need.
I was excited to try gimp, but it was slow enough on this Mac that I gave up. Inkscape is on the list, but my hopes are low.
Affinity Designer is an excellent option. It’s way beyond what you would expect a $50 app to offer, and bests Adobe Illustrator in several areas.
That said, I think its low price point has started working against it. New releases come at a glacial pace, and a few broken features have literally had fixes in the works for years (expand stroke is the standout). When the last thing I bought from the company was a $50 purchase four years ago, I can’t really complain, but in retrospect, I wish Affinity had gone the Sketch route with an annual upgrade program. I’d like to pay more to see Affinity Designer advance faster, but presently there’s no option to do so.
Seconded. It's just different enough from Illustrator to be unsettling for the first few days, but the core of it is immediately and very obviously excellent. I persevered (it's vastly less money) and I'm very pleased I did. It's significantly smoother and faster in daily use than Illustrator (at least on my machine) and that counts for a lot for me. Updates are thoughtful and contain useful features. There's very little now that I actually have to work around and some parts of it are just intrinsically better - snapping candidates, for example.
I'm really liking it myself. Unfortunately I've got hundreds of hours wrapped up in making maps that I periodically update, and there's no good path to move them from Illustrator to Designer. PDFs move, but then every path comes over weird... And without the layers and groupings that are otherwise so helpful.
It's a pretty great option, I think! Acorn doesn't get as much press, but it's really powerful for its price.
Also, while people are even more likely to forget Graphic Converter since it first came out in 1859 or something (this may be a slight exaggeration, but my point is, it's been around a long time), it has some neat tricks up its sleeve. I sent business cards to a print shop that required CMYK PSDs by doing the work in Acorn and converting in Graphic Converter.
Does anyone know if it's possible to start from a pure Catalina installation of macOS and install a partition with Mojave? For the first time in forever I won't update macOS on my computer so that I can keep using a few 32-bit app, including http://www.halomd.net/.
I've done this to install a beta, but not to try to install an older macOS version from a newer release. If for some reason, the Mojave installer won't launch from Catalina, then you could create a bootable Mojave installer:
Greetings to halo MD fans! Unfortunately the original Mac Halo binary that MD wraps is itself 32 bit, but some hope lies in a project called wineskin. Look up the Porting Team discord or atomical’s Halo MD discord for some discussion...
You can install macOS (this also works for Catalina) on an external hard drive (I recommend an SSD if possible). This runs at native speed and you can use it to test/try anything without touching the internal disk.
Unless you have a very powerful host system running macOS in a VM is painfully slow. On a 2019 MacBook Air with 16GB or RAM running a virtualized macOS is crawling to render the Finder window.
The biggest problem with virtualizing macOS is that it’s built assuming that a half competent GPU is available, meaning that its software rasterizer is dog slow which is a big problem because no VM simulates a GPU that macOS supports. I’ve heard things about getting GPU passthrough working to fix this but I’ve not tried that myself.
Parallels specifically is much better than e.g. Virtualbox in my experience. Still not really pleasant—there's a lot of latency for some reason, unless you directly pass through the mouse as a USB device—but usable enough.
A few months ago I tried a Mojave and a few older versions of macOS in VirtualBox on a 2013 Thinkpad (Hackintosh) and had no problems with booting nor basic things like Finder and other operations with the GUI. I didn't try more graphics-intensive apps, however, but it was actually surprisingly fast and easy to install from an ISO created using the official source download, minus the workaround I needed for EFI booting from APFS. Building an app with Xcode (the reason for doing all this in the first place) also worked decently.
Did Snow Leopard still bundle Rosetta with the install? I thought that Snow Leopard still required a download of Rosetta that likely wouldn't be available now...
OSX VMs are so slowwww in a virtual environment though. I’ve tried doing it several times in parallels and they just crawl. Unless I’m doing something wrong.
My experience and knowledge about it has said that this is because of the reliance of OSX on GPU hardware. That means it won't ever perform well on any kind of software rendering. Some kind of GPU passthrough or sharing is needed to make it work acceptably.
It's got to be more complicated than that. I've used Parallels to run complex DX10 games such as a Tomb Raider 2013. I'm not sure what wizardry they use to make that happen, but it works really well.
Parallels is, perhaps not coincidentally, not as terrible at running macOS as some other solutions, but it's still fairly poor.
It's not. I've run macOS under a hypervisor with GPU passthrough and it's essentially as fast as on metal (I think you can see a single digit percentage difference in benchmarks). I don't think anyone has a soft 3D driver though for macOS guests. Parallels and VMware have both put a lot of work into getting some level of soft VM based 3D acceleration working for Windows guests, presumably because that's where the demand is. At the same time macOS has been built heavily around GPU for everything for a very long time now, initially as a way to improve even basic interface smoothness in Aqua back in the day. So it's a dog in pure software on a VM. It really needs a GPU.
FWIW, in the past VMware did officially have Mac Pros on the hardware compatibility list for ESXi (up to 5.5 I think? maybe the trashcan lasted longer). And that in turn would be legit for running a Mac guest. I've read you can sort of get it to work on other Macs like the Mini, though secure boot must be disabled and the T2 causes other issues. Otherwise you need to patch it, or go with KVM or some other alternative.
CS6 hasn't worked right in OSX for years anyway. I hung onto it as long as I could but Save for Web stopped working around Yosemite so I could no longer save GIFs, then around El Cap PS started crashing when you did certain drag operations and Illustrator started acting weird.
Think CS6 is still a viable option for Windows 10 users though.
I dived (dove?) into Catalina on day 1, the very first developer beta, because of SwiftUI.
It's an amazing framework. Sure Flutter and others came first and already did parts of what SwiftUI+Combine do, but being able to take an app from design mockups -> interactive prototype -> final version right in the same editor and using the same language for UI, logic and model (with native APIs and look-and-feel) is something I've fantasized about since forever.
There are many rough edges (just like Swift itself which took like 3 years to become good enough for "serious" use), you still need AppKit/UIKit for some things, and Apple's developer documentation remains appalling as ever, but I was able to turn a bunch of ideas into usable apps in a matter of hours, that traditional frameworks would have taken me weeks to do.
I hadn't even planned or expected to make "proper" apps with it, I was just playing around, iteratively adding to mockups, and boom, there was an actual app on device.
Catalina itself however was the buggiest macOS beta for me. I permanently lost random files on iCloud Drive, CPU and network usage was always high, and I had to use a temporary local user account that was not tied to iCloud to avoid messing things up.
And it's annoying that they still haven't fixed some minor bugs I reported since the Mojave beta, like unreadable white text on brightly colored tags in Dark Mode and Books jumping around between desktops on its own (the kind of stuff that would have infuriated Steve Jobs I assume but is deemed unimportant now.)
My SwiftUI experience is quite different. For me it worked ok for everything they do in the tutorials but everything else is underwhelming. Animations are really cool though.
Some of my issues where that sometimes the buttons seem to have a very small hit-box (yea, I changed that but it didn't help), you have to use lists because tables mess up certain animations, lists always have this separator line, the documentation is not really there, ....
I started to use it from the 3rd beta and still, the API changed with every update and generally it felt more like an alpha. Overall I wouldn't do much more than a simple example ToDo app with it and definitely not rely on it for a product.
Yes, there are bugs and documentation has always been Apple's Achilles' Heel.
I definitely managed to make something a little more complex than a To Do app though. See the demos from other people like @MengTo [0] to see what's already possible.
Lists etc. will be customizable once they open up the -Style protocols. Try ScrollView -> VStack -> ForEach for now.
Yeah...and SwiftUI is by default an iOS only program. Flutter you can plug any phone in that's been made in the last 5 years, type `flutter run` in the terminal, and get hot reloading.
SwiftUI is walled-garden bait. Hard pass.
EDIT: Not sure why I'm being downvoted - (one of) Flutter's main selling point is that it's cross platform by default. SwiftUI doesn't do that and yet is marketed to be very similar in coding style to Flutter, which yeah great, but no cross platform so you still have to code everything twice, unless all your users happen to have iPhones. I mean really?
and macOS, tvOS, watchOS (and soon I suppose, AROS?), all counting for over a billion devices.
You can literally run the same SwiftUI code on all of them, then make small changes to adopt each OS's unique paradigms (like menus on macOS, the crown on watchOS, the remote on tvOS) and get the most native performance via Metal etc. for free.
It's ideal for publishing to services like the new Apple Arcade and macOS/iPadOS Catalyst.
How is Flutter for accessibility features? Those seem really effortless to adopt in SwiftUI.
> ideal for publishing to services like the new Apple Arcade and macOS/iPadOS Catalyst
I was just looking into this yesterday but found no info - so you're saying it's now possible to write an iPadOS app with SwiftUI and use Catalyst to port it to macOS? It used to be a "known issue" in the beta that this was not supported... does this work now?
I haven’t tried it but it must be one of their top priorities to get it working soon, as Mac/iPad hybrid apps are one of the use cases where SwiftUI makes the most sense.
You can of course write regular (non-Catalyst) projects that share a lot of the same code between Mac and iPad. In that case you may not even need Catalyst, so maybe Catalyst is only UIKit-on-Mac.
I guessss.....except if I want to make an app (and not a web page) I would probably make it in electron, because again I don't have to code everything twice. Making apps for apple watch or an iPad just doesn't appeal to me I guess - they always seemed like devices that were invented so people could spend more money on needless crap. Is a watch with a touch screen really that much more useful than a smart phone? Seems like just another way to suck people into a walled garden. Your watch sinks to your iPad, iTV, iWhatever...Yeesh, who cares?
> they always seemed like devices that were invented so people could spend more money on needless crap
As a view on the other side; I develop business apps. They are distributed via a local enterprise store, and never appear in the public App Store. Often, my apps replace paper in old-fashioned businesses. It's very honest and satisfying work.
No, RN isn't bundled with any browser runtime. You're possibly thinking of Apache Cordova (which leverages the device's browser runtime for rendering UI).
RN is Javascript so it will execute on the device's JS runtime, which I guess is connected to the browser in some way, but RN doesn't use the browser for UI. The rendering is true native UI.
The way React does this is by decoupling the core library from UI rendering. The core React library contains no UI rendering code, it just handles UI lifecycles, internal state, events, etc. for logical UI components as object instances. You then plug that into a renderer library (most commonly the "ReactDOM" lib for web browser rendering).
If I do this my apps are limited to the lowest common denominator which means supporting either 6% best case of Android users, or going back further, supporting say 30%, if Flutter will even support doing so, and giving up many features thus hurting not only my Android users, but also my iOS users who could be way ahead and who stay updated. And tying the future of my project to Google? No thank you. Have you seen any Google projects lately? Shallow and not impressive at all, and often abandoned. OMG I have to code everything twice you say that like coding is not fun, or like it's the end of the world. How about this: code everything once, and target iOS. If cross platform is really needed, go with something from a serious company, like Xamarin.
Unfortunately, I made the mistake of "upgrading" the Reminders app on my new iPhone, and now I can't access my reminders on my Mac until I upgrade to Catalina. That's really lousy. Apparently there's a web interface I can use, but yeah no thanks.
> Upgraded reminders aren't compatible with earlier versions of iOS and macOS. If you upgrade your reminders on your iPhone with iOS 13, your iPad and Mac using the same iCloud account can’t access your reminders until iPadOS and macOS 10.15 Catalina are available. from https://support.apple.com/en-us/HT210220
Anyone care to explain what happened that there are audio complaints and breakages? What part did they rewrite? I see this comment a lot, but googling doesn't find a quick answer.
For the most part, it's not a technical issue at all but a cultural one : pro audio users are notoriously, almost pathologically conservative when it comes to software upgrades.
You'll find plenty of threads on forums like Gearslutz, asking for tips on how to downgrade brand new Macs to an older version of macOS that doesn't even support their hardware. Or 2019 threads asking if it's now safe to upgrade to High Sierra. They're typically 2-3 versions behind. Why ? Older is just safer, better in their worldview.
In that context, audio developers know they have customers on their side against "evil Apple that's always breaking everything for no benefit", and every year in September/October they get away with emails that read like Apple just unexpectedly dropped a huge bomb on them out of the blue, and it'll take them 6-12 months to get ready, like WWDC and 3-4 months of developer betas never happened.
While this take is accurate, it's because they want to _do audio stuff_ and not debug computers.
As a DJ, My Serato set up _works_. I don't have any show stopping bugs, and I don't want any new features. It's running on Sierra with an older version of Serato from like 2 years ago. Why do I need to upgrade the OS?
When I'm playing in the Club, I shut off wifi/bluetooth, and everything else that I can.
If I could simplify even more, I would. General Purpose computers are both great and a liability when it comes to digital audio especially for any live performance.
You're right, users absolutely should not have to debug computers and live performance is especially sensitive to realtime constraints.
It's the developers job to do so, and they're basically procrastinating for as long as they can, not heeding Apple's deprecation warnings for _years_ and then trying to blame them in front of users when st finally hits the fan, pretending they couldn't possibly have known. That's simply dishonest.
I thought professional audio developers try to exploit very low level access to the hardware for the sake of minimizing latency. If these same exploits allow system vulnerabilities, it seems to make sense that developers of macOS are constantly changing the software in ways that unintentionally impact anyone writing kernel extensions or other software that tries to access the hardware at a low level.
Most of the developers emailing their users in panic are not in this situation though.
They're writing audio plugins using the AU or VST APIs. They don't ever touch hardware or even deal with realtime constraints directly : they just fill buffers as far as they can and pass them on to the host DAW application, which together with audio interface drivers + the OS deal with the hard stuff.
In this case, it's not conservative me not wanting to upgrade (this computer is actually only a month old). It's vendors saying they can't guarantee that their software will work. Several of them.
This is the first version of macOS that doesn't support 32-bit applications. Most of the software in question hasn't been updated in years so people are hesitant to upgrade. It's mostly a legacy issue.
On top of using their main application (DAW), which is most likely 64-bit, musicians tend to use a ton of plug-ins; some commercial, some freeware. Many if not most are 32-bit only and probably will never be updated (abandonware, or just old unsupported releases from commercial vendors).
Basically for many musicians, upgrading macOS will mean killing some of their plugins.
I usually install the latest MacOS version right away. After installing iOS 13, 13.1 and 13.1.1 and finally (so far) 13.1.2 in a month I think I'll wait this one out until a maintenance release.
Does Catalina boast any fixes/improvements/features for business users? Looks like mostly lackluster enhancements for mainly consumer users (Apple Arcade, Screentime, entertainment apps, etc). I would have like to see some UI/UX overhauls in some of the default apps at least.
Some useful security improvements, for example OS files now sit on a different read-only volume from all the users files and programs, making it more difficult to insert worms, Trojans, rootkits and other things that can compromise the actual OS. And all apps installed on the Mac are now checked not just that they’re trusted, but for known security vulnerabilities too.
To the extent businesses care about reducing losses from cyber attacks, that’s probably useful.
How does moving system files to a read-only volume provide any additional protection on top of SIP, which prevents unsigned processes from writing to system files?
SIP had numerous exploits over the years, basically. The new volume provides additional isolation and utilizes native mechanisms in APFS to make it transparent to the user space. 'Defense in depth'
I had nothing but bad experiences with Mojave. Everything was noticeably slower, and stuff seemed to crash more often. This was despite the fact that Mojave shared a base with the very stable iOS 12.
Now we have Catalina, which shares a base with iOS 13, which according to numerous reports is very buggy... I don't want to touch Catalina with a ten foot pole. The fact that my copy of CS6 would stop working is icing the cake.
I should get one more year of security updates on High Sierra. Not sure what I'll do after that...
That's weird. Mojave has been rock solid for me, way better than High Sierra. But I guess mileages vary.
I'm not updating to Catalina either, I plan to stick around on Mojave until they release something that actually makes me want to upgrade. (maybe when Catalyst matures)
Mojave was a frustrating experience for me until I bit the bullet and did a clean install and remigrated my stuff. I doubt I'll do another in place upgrade again.
This hasn’t been necessary for many years as long as you haven’t had to replace the drive or lack an internet connection: just hold Command-R down at boot.
I had nearly 9 months of very slow response times in Mojave but I suspected I needed to reinstall from scratch. I resisted doing so because I'd developed many dozens of dependencies that I didn't want to chase down (e.g. custom-compiled ImageMagick).
Doing the dreaded "clean install" fixed my issues (primarily a Finder that would routinely spend up to 30 seconds or more displaying the contents of any folder).
Up until Mojave, I'd never done a "clean install" on a Mac for performance reasons. Once doing so worked for my laptop, I followed suit on my desktop.
Did you have Adobe Creative Cloud installed by any chance? I had the same issue, and found out after several reinstalls that Adobe’s core sync finder extension was the cause.
iOS was forked from MacOS more than a decade ago. Of course some code is shared between them, but they do not have the same base in any sense of the word.
It’s really more than “some code”: the kernel, core frameworks, and many utilities are a single codebase with platform-specific #defines. I have no idea if there was an actual fork when iOS was being made, but if there was they merged the changes back in.
True, but there are a lot of elements of the system that are not shared but are pervasive, and so the assumption that the bugginess of ios13 somehow must also be in Catalina is not valid.
iOS 13 is driving me crazy. Between constant “prompts” to approve (and reapprove app permissions) and it losing permissions for some apps entirely I’m getting furious.
If you read those prompts, note how often those are asking for permissions used to track people which don’t benefit the user. The number of apps which ask for Bluetooth greatly exceeds the number which have any use for it, for example.
Well then, time to copy/paste one of my Mojave VM and upgrade it to Catalina. On a side note, 20 years ago my girlfriend at the time name was Catalina. Hopefully this macOS not going to leave me with broken heart like the ex-gf.
I was amazed to see that with Catalina, zsh is now the default shell on MacOS. Then it occurred to me that this is probably more about Apple's great GPL purge than anything else.
After reading a bunch of different articles and reviews about this topic, I'm currently testing AdGuard For Safari, which is 1) free, 2) open source, 3) in the Mac App store. (Not to be mistaken with "AdGuard for Mac", which is an all-encompassing machine firewall.) Overall I'm happy with it so far. It's a little weird in that some aspects of the Safari plugin only work if the standalone app is running at the same time, like the ability to disable blocking for a specific site. Not sure if all new-style adblockers have the same limitation, or if that was a specific decision by AdGuard? Either way, I'm happy with it so far, and happy with the fact that they use multiple Safari extensions to achieve > 50k block patterns, which is the limit for a single extension. (1BlockerX does the same on iOS.)
Struggles with some videos, and YouTube in particular. But, as @jzl wrote in the sibling comment, most ad blockers require that their app is running as well, for them to function. "Ad And Stuff Blocker" does not, which is why I'm trying it out. Has been treating me well for two weeks.
At the moment I am not upgrading because I regularly use Aperture for photo editing, and it will be unusable after the update. I bought it 5 years ago, and it's worked perfectly since then, meeting all my needs for photo editing and not even feeling remotely dated in terms of UX/UI even with all the OS updates since then. I have no idea what I'm going to replace it with, since I really don't want to go to Lightroom and it's subscription model.
If you are looking to replace the 32-bit-only Aperture with something else for photo editing on Catalina and don’t like Adobe’s subscription model, you may want to consider Capture One. It is actively supported, has the “buy and own” option, and is very capable though its interface may take some getting used to and/or customizing.
I tried the demo earlier this year and liked it a lot, and they even happened to have a promotional discount at the time, but for whatever reason the purchase button was broken for me. I’m sure it was either just my machine, or Phase One has fixed the bug long ago.
"The new Find My app combines Find My iPhone and Find My Friends into a single, easy-to-use app on Mac, iPad and iPhone. Find My can help users locate a missing Mac even if it’s offline and sleeping by sending out Bluetooth signals that can be detected by Apple devices in use nearby, and then relaying the detected location of the Mac to iCloud so a user can can locate it in the Find My app."
I'm curious about what kind of T&C will need to be accepted for this to work.
Yep, this release decimates the already unfortunately small library of games available on Mac. I don't use my Mac much for gaming but it was a nice thing to have available in a pinch.
that was helpful, thank you. somewhere else in this thread I mentioned that I had just updated to Mojave about a week ago. during the upgrade, the stock standard warning message about the upcoming 32bit noncompliance apparently did not include all the non compliant applications on the laptop, discovered Adobe, missed Steam.
This is probably going to be what gets me to switch all my audio applications to Windows 10. Once again, everything I use -- Serato, Ableton, and half a dozen pieces of hardware from different manufacturers -- is broken in this release.
Apple's become a phone company that grudgingly still makes computers, and this is reflected in their treatment of end users.
It appears that the system font was changed. I'm trying to figure out what it is now, it appears that San Francisco isn't even installed on my system anymore. GitHub, Twitter, and other sites using system-ui / -apple-system as the font-family now look very odd.
No, it's very much still San Francisco. Are you sure it's not a browser plugin issue, or perhaps something changed in Catalina that causes the browser not to display the font the same way as in previous versions?
If you're using Chrome, this may be the result of a bug in Chrome. Have a look in Safari, it should be fine there.
I've had the beta for a while specifically to fix an HDMI handshake issue with my new mac mini. The only big deal for me was the switch from bash to zsh as the default shell. I had to rework some of my dotfiles. Maybe took 2 hours to get it all how I wanted.
Other issue is that arduino flashing is broken for my redox wireless keyboard, so I have to flash firmware on my old laptop for now. Something to do with super low baud rates not working in catalina!
Other than that, nothing in catalina that gets me excited, the screentime thing is pretty broken, it shows the same amount of time for all apps pretty much, so kinda pointless.
Welp, that's the end of my 2011 Macbook Air. Sigh. There are already 6 incompatible updates out. Plus the recent iOS update ended support for my iPhone, so that's on the way to joining my iPad and iPod Touch.
If you upgrade and wonder why fonts in Chrome look just a little bit off, there's a bug in Chrome/ium (HarfBuzz). Most text will look a tiny bit too narrow, some text will be slightly too wide. Nothing major, but I noticed. (Also affected: Chromium-powered apps like VS Code, Atom, many messaging apps, ...)
I know dropping 32-bit support will cause issues but isn't is broadly positive? Windows has always had a strong focus on backwards compatibility and look where it has ended up. I feel like in 5-10 years time, we will look back and say it was the right decision.
I remember when Apple dropped the CD-ROM drive....I haven't used a CD/DVD since 2013...over 6 years ago and I cannot remember a time when I needed to use one other than playing old DVDs which is not a big deal with Netflix & co.
Did Apple lose some critical people in the last year or so? Johnny Ive we all heard about. But maybe more such important foundational people on systems and core OS side also left? I'm guess this because the drop in quality in both iOS and MacOS even in released software is significant that regular people are feeling it. I seriously hope this is a temporary glitch and I won't be forced to figure out a new system setup (back to Windows? Or Linux or ChromeOS?) for my day-to-day.
I shows up on my Mojave-based MacBook but not on the one with Catalina Beta. Are there different release dates for MacBooks enrolled in the beta program?
Not the best answer you'll get but my experience in the past has been that once you put your device on the "beta" cycle (iphone, mac, everything else), they will follow that until you hard reset it...meaning once the OS goes general release, you're still on the beta releases.
This means you're probably already using latest Catalina on the device that's on the beta cycle and you will continue getting new minor releases before the general public release one.
Is it possible to get off beta cycle without "destroying" the device? iPad also shows beta 13.2 available but I stopped it from upgrading and would like to "downgrade" to regular iPadOS.
Reminder: 32-bit apps will not work in Catalina.
If you use your computer as your main work machine, hold off on the update. You're bound to run into a random forgotten app you use every once in a while that's no longer supported.
To see what's still 32-bit on your mac, go to:
Apple icon > About this mac > system report > applications > then click the 64-bit column to sort. No will be 32-bit apps.
My only question is how do I sync both selected music (a playlist) and selected podcasts to my 10-year-old ipod mini without iTunes?
I have a playlist called "ipod" that I select to sync to ipod. I have certain podcasts that I select to sync to ipod. I plug my ipod in and click sync. The end. I've been doing this for 10 years.
I've experienced a number of problems. Anything from Apple fuckups to software that won't run for one reason or another. It's much safer to wait at least 6 months before updating.
Crashed when installing and already crashed once running Lightroom. This is worse-than-Windows reliability, Apple. You don't need to run faster than the bear, you only need to run faster than Microsoft. And you're failing at it.
Catalina feels like a "Elves are Leaving Middle Earth" moment. There's just too much going wrong with Mac for me to try to remember why it's still worth it. Windows is uglier for sure, but at least it works.
- return of scripting, alright maybe not AppleScript, but JS, Python, anything: I want to automate my UI meanderings, what the hell
- return of services: make this a reminder, make this a note, send this as email, etc. come on
- a chat app with windows: why is it exactly that every Telegram and Twitter and whatnot has me clicking back and forth and back and there and back and here, why? also why can't I open a chatroom with these three WhatsApp peeps and this one Twitter dude and my mom on Skype? this is backwards
- return of managers: at some point iTunes stopped being my 90+GB music library manager, and became hell knows what. same with Photos, Safari, Mail. all full of cloud and gotchas and eye-candy that keeps me away from my stuff by making me wait.
- the return of self-published dashboard widgets. they are awesome. I'll be where they are, thank you very much.
- Scripting isn't gone. The OSA services are still there; Python isn't installed by default but that's all.
- Services isn't gone.
- Yeah, that's fairly annoying. I think Skype has tear-off-able windows but that might only be for voice calls, not chat windows.
- The new Music app (which is really just iTunes with all the videos, podcasts, and other crap ripped out) now just manages music — it's oriented towards Apple Music by default but a couple of clicks in the View menu changes that.
> Scripting isn't gone. The OSA services are still there; Python isn't installed by default but that's all.
Python is still installed by default. Launching /usr/bin/python (2.7.16) prints a big warning about how "future versions of macOS will not include Python 2.7", but that's because Python2 is EOL.
Yes, the new Music app is literally just iTunes with the podcasts, audiobooks, and such taken out. It still retains all the Music-related scriptability.
At a glance, the new Podcasts app isn't scriptable but the TV app is.
> - a chat app with windows: why is it exactly that every Telegram and Twitter and whatnot has me clicking back and forth and back and there and back and here, why? also why can't I open a chatroom with these three WhatsApp peeps and this one Twitter dude and my mom on Skype? this is backwards
Is this directed towards Apple? Cause they only make one chat app, called Messages, which lets you open conversations in separate windows.
No can do. This will be the first macOS that I will never install. And when support for the current OS runs out, I'l have to move to a Linux box, assuming that 32-bit support still exists by then.
As far as I'm concerned, macOS Catalina never happened. I'll wait for the next major version (10.16), which will undoubtedly be a maintenance release with almost no new features.
It moved my Anaconda installation to a relocated folder with all the envs gone. So I had to reinstall it and recreate all my envs. Also had to reinstall Xcode because git stopped working.
Don't you just compile a 32bit program source code with a 64bit library to make it 64 bit? All my c++ project from college work once they get new links to the Apple libraries.
A strange bug was that a permission prompt appeared during the OS setup phase (large centered window in background), blocking part of the setup window but refusing to accept input.
Each time I tried to enter my password the focus would glitch back to the large background window, which oddly could still be clicked. So I had to keep clicking grayed-out Continue buttons in the background setup window, until the desktop finally appeared and the password prompt (which was in front the whole time) would finally accept input.
I mean, this is the first thing you see when you launch the OS, these are exactly the kinds of bugs that need to be found by Apple and not by users.
Not too many coders seem to be concerned, but QuickTime was never really replaced. AVFoundation is not a full replacement for QuickTime if you do advanced authoring...
I'm still holding back from upgrading my hardware (my 2013 Macbook Pro is still going strong with no maintenance required). For one, the butterfly keyboard issues have really put me off the newer laptops. It seems like everyone I know has a key that doesn't work properly anymore. I also like having plenty of ports without buying an adaptor and carrying one around with me.
When I upgraded my iOS devices to 13, my shared To Do lists stopped working in macOS. Each item in the list has a warning triangle next to it that explains I have to upgrade my desktop OS to use the lists again.
It turns out that I underestimated the importance of the grocery list shared among my family members. I now have five gallons of milk and no kitty litter in the house.
No iTunes? no thanks. I refuse to "upgrade" to marketing adware that takes away features. I'll stick with Mojave on my Hackintosh for however long that lasts. Oh and Catalina won't run anything that's 32-bit either.
I don't use it, so I don't know the previous behavior. But in Catalina, when I use Ctrl-Up, the desktop zooms out and a narrow strip appears on top, labeled "Desktop 1", "Desktop 2", "Desktop 3", etc. When you move your mouse over to the label, it expands into a preview.
Yes, it is the dumbest thing ever, and demonstrates they've forgotten what Exposé was all about and what the innovation was.
Instead of showing you labels or icons in a task switcher, they just showed you all your windows. Direct representation instead of symbolic proxies.
"Desktop 1/2/3" is meaningless. Show me what's on it so I can see where my windows are. Don't put a dumb gesture between me and what I need to see.
They only did this because of tiny screens, it makes zero sense on any decent monitor.
Old Apple would've put in a hidden pref, tracked its use, and then quietly eaten crow. New Apple thinks they know better than even their power users. It's ridiculously arrogant.
I remember the last update (Mojave?) where the first release gave root access and allowed unlocking of the computer by default. Woops!
Yeah, no thanks. Until Apple learns to release non-buggy crap I'll wait out the horror show for at least the next 6 months. You guys have fun debugging this for me!
EDIT: Pretty funny watching all the Apple fanboys going through my account and downvoting all my posts. Oh no! My fake internet points! /s
This is a bit of an odd release, no? I did not see an advance announcement of the date, there is no feature in the Mac App Store indicating that the OS is now available (though there is one for Apple Arcade), and until a moment ago, clicking "How to Upgrade" on the Apple site still led to a link to Mojave.
I've suspected that notifications of upgrade opportunities and advertising of new versions may track with Apple's desire to pace rollout. For example, I'd be surprised if they hit every available device with the upgrade notification about ios 13 given 13.1 would be available only days later.
I read a lot of people debating about how "difficult" is maintaining 32-bit support, or if it adds more vector attacks to the system.
Don't fool yourself. Maintaining 32-bit support is "easy" (with all the technical issues we all know). This is simply a sales strategy.
It's the same strategy than disabling a glorified vnc (Sidecar) on three years "old" laptops. Sure you need a lot of horsepower to display a remote image in real time. Never done. Yeah.
Apple is taking the "appliance route". Your (my) Apple computers, your (my) Apple phones...are closed appliances (no ram upgrade, no battery upgrade, no significant OS upgrade). This appliance version do this, the next appliance version do that. Soon we'll see that they're no longer upgradeable computers, and we will be fine with it...sadly.
How is dropping 32-bit support a "sales strategy" for Apple? They haven't sold a 32-bit Mac since 2006. If anything, Apple is helping drive sales of other companies' software, and hurting the adoption of their own $0 operating system. For anyone with 32-bit software that won't run on Catalina, there's nothing you can buy from Apple which will help one bit.
Remember, Google tunes your search results based on your own personal search history.
I searched for "Catalina" in a private browser window and got exactly two results about today's release news, then a whole lot of Catalina Island results.
Honestly, the 32-bit support shouldn't have been removed. It should have been split off into a separate package like the XQuartz project, as some of us still use 32-bit applications daily.
Very disturbing that one of the biggest companies around can't keep 32-bit support, at least in some capacity.
It’s not that they can’t keep 32-bit support, it’s that they don’t want to. Apple has a history of forcing people in to the future that they envision. Much like they did with removing the disk drive and the headphone jack. Seems like that is what they are doing here by killing 32-bit applications.
This is more like when they dropped support for PowerPC emulation. It's less about forcing people into the future than about forcing Adobe and friends into the present.
Adobe wasn't 64-bit clean at the time that Apple announced they would be deprecating 32-bit binary compatibility. At the very least, Apple forced Adobe to update their DRM to something that didn't require running 32-bit code.
However, I think it's worth asking, who was that hurting? Users certainly aren't going to notice, and license activation isn't performance-critical code.
I'm sure for Apple it's QC, build process, documentation, examples, and constraints around building new things--maybe sharing stuff between iOS or preparing for a transition to ARM. Who knows? Apple tends to support the old OS for a few years, so while it does suck, it should be manageable.
It drives me nuts that installers and license managers are old and crufty. I do understand why. A few times now I've encountered situations where the installer cannot run even though the software it installs is fine.
I understand why it benefits Apple. I think the idea that it benefits users by forcing app developers to write better apps is a load of nonsense.
Separately, I feel like Apple should deal with it. They're one of the richest companies in the world and they can afford to maintain extra copies of libraries, possibly indefinitely. No one is asking them to go full-on Microsoft and explicitly test against old 3rd party apps. But, Apple clearly doesn't care, and I can't do much.
> and license activation isn't performance-critical code.
No, but DRM is pretty likely to require your OS to remain exactly bug-compatible with older versions. After all, the entire point is for it to cause trouble if it detects unexpected changes in system configuration or behavior, even if those changes are within the scope allowed by loose API definitions or undefined/unspecified behavior. E.g. it's pretty much expected that when an OS tightens security restrictions, it'll break a lot of DRM and video game anti-cheat systems. Inserting a new compatibility shim is also likely to be mistaken by those systems as a circumvention tool.
Well, that assumes the DRM is stringent. I don't think Adobe's ever was, it was certainly cracked easily enough. CS6's activation system has also survived _many_ macOS updates, up until this moment when Apple outright ripped out 32 bit. Maybe that's because Apple was purposefully maintaining compatibility with CS6 explicitly, but given how they operate, I kind of doubt it.
The real issue is that some people are relying on unmaintained software. If they want to serve customers, IMO, the platform vendor should make a best-effort attempt to let unmaintained software keep working.
I hear a lot of post hoc justifications from Apple fans about how hard to maintain the compatibility layers are. But. It strikes me that a job has fun and not so fun parts. If there is really an ongoing maintenance issue generating more work release-to-release maybe look to re-design how the compatibility layer works.
> If they want to serve customers, IMO, the platform vendor should make a best-effort attempt to let unmaintained software keep working.
I agree. The problem is when the major ISVs abuse this and force Apple to keep doing high-priority QA to preserve binary compatibility with major applications that are mission-critical for many Apple users and are still maintained to some degree.
Users of unmaintained applications are generally somewhat understanding or accepting of gradual breakage driven by real technical necessity. Users with an active subscription to Adobe CC rightfully have higher expectations that their software continue to work without being broken by OS updates - but Adobe was trying to make that entirely Apple's problem, just as they did for migrating away from PowerPC and Carbon APIs.
It's not, really. Nobody wants to carry support for both 32- and 64-bit forever. You've got to call the ball at some point. Now's as good a time as any.
> What does Apple or the users gain from removing 32-bit?
> Nobody wants to carry support for both 32- and 64-bit forever.
Support means money and developer time, no one wants to waste money unless they really have to. In this case they don't have to, because everyone should have already updated whatever they use that was first made only for 32bit to 64bit.
imho the actual blame lies on whoever have resisted moving to 64bit(again mostly because of money).
We are talking about one of the richest companies on the planet that makes by far the largest margins on their laptops and desktops in the industry. If any company is equipped to offer 32 bit legacy support for the benefit of their users it is Apple.
First I would like to say that I feel why you are frustrated, but the party to blame is whoever made the 32bit-thing you are using now, they refused to pay their technical debt. They should have moved to 64bit long ago to avoid frustrating you when this eventually happened. I am also genuinely curious what 32-bit software you depend on, would appreciate if you mention which software/company it is.
On the other hand, yes Apple has great margin but companies are not charities, they don't stop making money when they have "enough". When they make more money than expected, their stock rises, they pay some dividend, CEO gets a nice bonus and everyone gets back to work to figure out how to make even more money.
You can argue that Apple is already charging a premium to be user friendly, and 32bit support is also an item that can count as being user friendly. That would be a valid argument.
Actually this might be the reason they are only now stopping it and have been ok with supporting it until now(2019). Similarly there is a reason Apple computers don't have CD-ROMs anymore, this is because the vast majority of their users, don't care about CDs at this moment, the industry has mostly left it behind to better alternatives, those who have not(think medical devices that are expected to be function for 50 years because they are expensive) make support agreements for 20 years or something with corporate friendly manufacturers/developers such as Oracle and Microsoft etc. or just write their own OS that no one can deprecate. See how Redhat Support of Python 2 for example, Python 2 will be ancient on January 1 2020, but Oracle needs to support it because that is how they make money, being very very reliable in terms of supporting stuff. [1]
Finally actually Apples' profits has been dropping as far as I remember because of decrease in iphone sales year over year, so they need to do something to cut costs and get back to the "largest margins" you mentioned again.
That's not the point. Apple gave every developer ample time to update their software. This has been in the works for years and there have been 2 major OS releases that specifically called this out for developers.
You literally need 32-bit builds of every system library & framework. That's the state of things in Mojave.
If you run `otool /System/Library/Frameworks/AppKit.framework/AppKit -f` you'll see 2 slices, one for "cputype 16777223" (CPU_TYPE_X86 | CPU_ARCH_ABI64) and one for "cputype 7" (CPU_TYPE_X86).
I don't expect new features to be implemented in 32-bit builds - maybe security patches at the most - so freezing it and keeping it as a separate package should be feasible.
This is exactly what Linux distros are planning to do.
Apple uses the concept of fat binaries, where single binary contains code segments for several architectures. Optional support would mean basically two versions of the entire operating system: one supporting only 64 bit, and the second supporting both, 32 and 64 bits.
Linux solves it differently, it uses separate binaries for separate architectures. You can install the libraries into separate paths, have separate dynamic loader and everything works. Apple has no such option.
Also, macOS has a lot of system libraries that do IPC to either system daemons or kernel drivers, where the library exposes a stable API/ABI, but where the IPC interface itself has absolutely zero stability guarantees. This is because the library and the daemon/driver are developed together as part of the same codebase; users are expected to upgrade them in lockstep as part of an OS update, and to always use the library to talk to the daemon/driver rather than reimplementing the IPC yourself. This way, the developers only have to manage one stable interface (the library) rather than two (the library as well as the IPC interface). But that means you can’t just freeze the version of the library and expect it to work with newer daemons/drivers. In theory Apple could change course and decide that all system IPC interfaces must be kept stable starting now, but that would be really annoying, and probably more work than just continuing to update the 32-bit libraries.
(This even applies to the base Unix system calls. Go previously did syscalls by hand but recently switched to dynamically linking against libSystem and using its wrappers, because they’re the only guaranteed-stable interface.)
This explains the downvotes. I did some googling and noticed "Universal Binaries" mentioned in the results, which I remember in the 00s but had no idea that was remotely related to the OS binaries themselves.
Unfortunately the applications I use are Proprietary and Music related _on top of_ being OSX/Windows specific, and there's no way I can replicate this setup on Linux.
Also, clicking on a dropdown box in a web browser (Safari, Chrome, or Firefox) after the computer has been asleep for a while freezes the whole computer for about 10 seconds.
Maybe it's just me, but that feels like a showstopper.
The whole 32/64 bit thing doesn't seem too bad, although I've had to use Pages instead of Word and can't use Adobe products anymore and have had to switch to open source alternatives, but I don't use those products very much so it wasn't a huge deal for me.