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.
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.
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/.
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.
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.
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.
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.
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...
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.
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...
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.)
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.
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.
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.
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.
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.
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.
> 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.
"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?
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?
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!
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?
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.
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.
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(...)
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
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
> 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!
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.
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.
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.
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!
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).
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)
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 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)
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.
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.
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.
> 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.
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.
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.
* 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.
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.
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.
> 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!
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.
... 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.
> 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.
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".
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.
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.
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.
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.
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.
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.
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. :(
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.
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.
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'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.
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...
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.
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..
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.
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.
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'
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.
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.
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.
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
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'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.
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.
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.
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).
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.
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.
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.
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 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 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
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 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.
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.
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'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. :(
581 comments
[ 6.0 ms ] story [ 915 ms ] threadFor 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.
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.
[1] https://notebook.yasithab.com/macos/disable-sip-in-macos-vm-...
I still think I'd rather dual boot though.
https://support.apple.com/en-us/HT208891
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:
https://support.apple.com/en-us/HT201372
Installing macOS on a separate APFS volume https://support.apple.com/en-us/HT208891
“APFS makes it easier than ever to switch between versions of macOS, including a beta (prerelease) version of macOS.”
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.
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.
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.
If you were already using Cocoa, and were heeding deprecation warnings for the last 10 years, there should be zero issues.
Of course, with lots of software (especially projects started decades ago) it might have been difficult to do this. But the only paths forward were
(A) expect to drop support once 32-bit was removed
(B) gradually replace components which were dependent on things without 64-bit versions
(C) wait until 32-bit support was removed, then have a terrible time updating
And the writing on the wall has been there for a very, very long time.
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.
I don't see why Apple couldn't provide an optional compatibility solution, even if it were something I had to download separately.
Think CS6 is still a viable option for Windows 10 users though.
Here's a rundown of products that depend on 32-bit support or that haven't been tested in 64-bit on Catalina yet:
Audio products: https://www.sweetwater.com/sweetcare/articles/macos-10-15-ca...
Games: https://www.macgamerhq.com/opinion/32-bit-mac-games/
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.
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).
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.
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.
I wonder what MacOS has that Windows doesn't(which is a lot more backward compatible) that makes audio people stick with them.
All mainstream OSes are moving to an unsustainable release cycle.
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.
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.
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.
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).
Not saying it isn’t work, just that “I didn’t see it coming” isn’t much of an excuse.
That software is a lot like vintage gear, there may be alternatives but they aren't the same, and that's the problem.
They literally can't run without porting, disregarding performance. The benefit is infinite!
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.
It's just an Apple trick to force financial turnover for owner of 32 software.
It's not that there softwares are not compatible anymore, it's MacOS which block artificially 32 bit software.
It's for the same reason MacOS block sidecar for device older than 2016,even if they are capable to run sidecar in the first place.
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.
A better example is the obvious impending transition to ARM, which GraalVM is already preparing for.
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.
See the discussion here - and notice how confusing and contradicting the opinions about it are: https://news.ycombinator.com/item?id=21179970
Or that you haven't had the resources to spend on it
Depreciating 32 bit software is just an Apple trick to force financial turnover.
It's the same reason why the deactivated sidecar for macbook older than 2016.
Not saying I agree with apple's decision, but it's surely it's just about reducing their own engineering costs.
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.
This can also happen with e.g. multiplication Or if you need to align your pointers for some reason, so you do the cast correctly (with uintptr_t) and get 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.
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.
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.
A lot of audio developers are dealing with legacy code that has been growing over the years with a focus on pleasing a very specific user base.
Just look at how long studios held onto OS9 because of the long tail of plugins they had that were awesome, but abandoned.
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.)
Surely, surely it was obvious for years that Firewire is on the way out? Why are people so reactive and sluggish? People should be ready for change.
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.
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.
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.
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.
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...)
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.
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.
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?
- 68K Classic MacOS
- PPC Classic MacOS
- PPC OS X
- x86 MacOS
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?
I'm not sure if you'd be so ready for change if it meant replacing expensive gear that is still totally functional.
No? How come I can use Ableton Live 10 in 32 bits to make music then?
https://help.ableton.com/hc/en-us/articles/360003076340
1 at least on Windows
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.
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(...)
Unfortunately, the only way I’ve found to figure out why this happens is to sprinkle breakpoints throughout Safari…
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.
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.
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.
In every Apple technical decision, there is a financial motivation.
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.
Basically for many musicians, upgrading macOS will mean killing some of their plugins.
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.
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.
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.
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.
Very disturbing that one of the biggest companies around can't keep 32-bit support, at least in some capacity.
Removing 32 bit support hurts users.
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.
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.
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.
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.
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.
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.
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).
This is exactly what Linux distros are planning to do.
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.
(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.)
> 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).
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.
[1] https://access.redhat.com/solutions/4455511
http://www.linuxfromscratch.org/ https://www.openbsd.org/
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.
https://beta.apple.com/sp/betaprogram/unenroll
https://www.obdev.at/products/littlesnitch/releasenotes.html...
https://www.obdev.at/support/index.html?product=LS&topic=faq...
This seems like a sizeable change.
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...
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)
How do you do a clean install? Is this available from the recovery menu?
https://support.apple.com/en-us/HT201314
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.
Haven't reinstalled that software. It may have been the root cause.
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.
[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...
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!
For Apple, you and your 2015 Macbook Pro are just poor losers.
Now, You're free to buy a new one.
However, Numbers is not at all an Excel replacement and that is going to cause a lot of grief.
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.
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.
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.
https://en.m.wikipedia.org/wiki/Lighthouse_Design
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.
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).
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.
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!
Duet Display's iOS component costs US $9.99.
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.
What a fucking joke.
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)
16GB RAM
1TB SSD (3rd party upgrade)
Macbook Pro, 15inch, Mid 2015 2.5GHz i7 16GB RAM 500GB SSD
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.
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.
- 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.
Although I understand the Windows codebase is a nightmare.
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.
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.
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"...
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"...
Some things just don't ever need to change.
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.
Welcome to the life of a Mac developer.
*year
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.
https://www.dkia.at/en/node/180
http://v86-64.sourceforge.net/
Just don’t go there. Use an emulator for DOS code and use the normal kernel support (modify_ldt()) for 16-bit protected mode.
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.
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.
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.
* 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.
https://www.codeweavers.com/about/blogs/ken/2019/10/3/crosso...
And no, it isn't raw LLVM bitcode.
Xamarin among others ran into a snag but it seems they could retool and convert from armv7k to arm64_32 for example https://github.com/xamarin/xamarin-macios/issues/4864
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.
https://www.sans.org/reading-room/whitepapers/threats/unicod...
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.
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!
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.
[1]: https://www.gridsagegames.com/blog/2019/09/sorry-mac-users-a...
[2]: https://www.vice.com/en_us/article/43k4ww/its-hard-to-use-ap...
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.
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.
These aren't old games for the most part: https://www.macworld.co.uk/feature/mac-software/apps-wont-wo...
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.
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".
But tbh Mac was hardly a gaming platform to begin with.
The platform has never been "attractive to players" to begin with.
Now we have Arcade though and easy porting to iOS though, which could open a multi-billion market...
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.
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.
Even just recompiling the game might be a challenge for a lot of developers in the "long tail" of the Mac game library.
> 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!
[1] https://twitter.com/MammonMachine/status/1181327259057082368
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?
[1]: https://forum.unity.com/threads/installing-unity-on-macos-ca...
[1]: https://store.steampowered.com/hwsurvey
I'll hold off too. My macbook pro is 2013 and pretty old it overheat often if I play video. This update will definatedly exacerbate the problem.
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.
And yes, there's this Arcade, but I have no interest in playing for something which is locked down to one platform.
Do you boycott Xbox, Playstation, Switch, DS etc. exclusives too?
What about Windows-only games that aren't on Mac or other systems? There are certainly thousands of those. Do you refuse to play those either?
(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.)
- 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.
And Canon is notoriously bad at updating their drivers, so my scanner will now be a brick.
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. :(
I use it myself and ignore the manufacturers software altogether. Which form my scanner only supported PowerPC.
https://www.hamrick.com/vuescan/supported-scanners.html
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.
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.
https://www.exactscan.com
Homebrew has some broken packages, e.g. trying to run Midnight Commander dumps a nice "Bad CPU type in executable" message.
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.
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.
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...
- 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)
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.
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..
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.
Edit: it seems to be only old versions that won’t be supported (office 2011).
To the extent businesses care about reducing losses from cyber attacks, that’s probably useful.
https://support.apple.com/en-us/HT204899
overall performance seems better. connects to wifi network faster.
default shell on terminal is now zsh.
will upgrade homebrew managed packages now, Catalina bottles are available.
https://www.stclairsoft.com/Go64/
Note: I haven't tested it.
1. Click the Apple symbol () in the menu bar on your Mac's desktop.
2. Click on About This Mac.
3. Choose "System Report" at the bottom of the window.
4. Scroll down to the Software list on the sidebar.
5. Select "Applications."
6. Scroll all the way to the right to see the 64-bit list.
[0] https://www.macrumors.com/guide/32-bit-mac-apps/
You can sort on the "64-bit (Intel)" column to separate 32-bit from 64-bit apps.
When I tried this on my crufty main machine, Step 5 would yield a timeout and a very unhelpful error message. Works OK on my work machine. YMMV
[0] https://www.macrumors.com/guide/32-bit-mac-apps/
EDIT: formatting, punctuation
Otherwise it was all Apple or irrelevant.
(Sufficiently out of it to wonder if Catalina was related to Messalina ...)
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.
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.
> 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
https://bugs.chromium.org/p/chromium/issues/detail?id=100596...
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.
EDIT: For fun here's Steve Jobs' intro to Dashboard widgets https://youtu.be/XQQPTtdzBig?t=4872
(And I'm sure a 3rd party replacement will pop up, if there are enough frustrated users).
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.
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.
Has anyone been able to execute built-for-x86_64 bitcode on aarch64 ever?
https://atp.fm/205-chris-lattner-interview-transcript
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.
https://twitter.com/clattner_llvm/status/1046960724646465541
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.
I can't even recall how to invoke Dashboard. The fact that was always hidden meant I never used it.
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.
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 missed multiple calculators by default as in Windows. I found a simple Apple Script accessed with 'mcalc' that made this a bit easier for me.
http://www.markc.me.uk/blog/files/MultiCalc.htmlI 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
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.
Hot damn! That's the most useful thing I learned today!
[0]: https://www.alfredapp.com/
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.