How do you add new features to a product in this environment? Are they adding features to the legacy Mac software and having to add the same features to the native M1 Versions? That would effectively mean they are now offering three versions if you count PC? At what point does it make sense to drop or abandon legacy versions?
This seems like a potential nightmare for developers.
How are developers handling M1 + Legacy Mac?
-
jrides
- KVRist
- Topic Starter
- 432 posts since 18 Apr, 2008
-
FigBug
- KVRian
- 986 posts since 3 May, 2005 from Victoria, BC
Depends what you mean by supporting "Legacy Mac". If you just mean Intel based Macs, then yes, obviously still supporting them because they are the vast majority of Macs out there. If you mean old version of macOS, everybody makes the cut off somewhere different. The current version of Xcode will build software for 64 bit macOS as far back as 10.9. If you want to support PowerPC or 32 bit Intel Macs, then it's going to mean using an old version of Xcode, which means you have an old version of macOS running somewhere, probably in a virtual machine. I currently support back to 10.11.
It's a lot more than 3 versions. It's not uncommon for developers to now support on Windows: VST 32 bit, VST 64 bit, VST3 32 bit, VST3 64 bit, AAX 32 bit, AAX 64 bit. And then on Mac: VST 64 bit, VST3 64 bit, AAX 64, AU 64 bit. So even before the M1 macs, a developer could be supporting 10 builds of each plugin. Maybe 14 if they still offer 32 bit Mac plugins.
M1 adds VST, VST3 and AU M1 builds, and probably AAX in the future. Yes, this is a nightmare for developers. And it's something they should have already figured out how to manage before M1 came along. This means an automated build process, projects generated by cmake or projucer, all CPU specific features behind an abstraction layer like SIMDEverywhere.
So when M1 came a long, it should have been as simple as adding another architecture to a makefile, running builds and new plugins appear. In practice it wasn't that simple, for example I had to replace all my Intel Performance Primitives FFTs with KFRlib. I had to drop some features since the required libraries don't exist for M1 yet (REX).
Apple is still selling Intel Macs, and they support their machines for around 10 years, so I think supporting Intel Macs is going to be something we need to do for at least 10 years.
I image most developers will still support Intel Macs as long as the latest Xcode supports them, once it doesn't, that's when developers will probably think the deadache isn't worth it.
It's a lot more than 3 versions. It's not uncommon for developers to now support on Windows: VST 32 bit, VST 64 bit, VST3 32 bit, VST3 64 bit, AAX 32 bit, AAX 64 bit. And then on Mac: VST 64 bit, VST3 64 bit, AAX 64, AU 64 bit. So even before the M1 macs, a developer could be supporting 10 builds of each plugin. Maybe 14 if they still offer 32 bit Mac plugins.
M1 adds VST, VST3 and AU M1 builds, and probably AAX in the future. Yes, this is a nightmare for developers. And it's something they should have already figured out how to manage before M1 came along. This means an automated build process, projects generated by cmake or projucer, all CPU specific features behind an abstraction layer like SIMDEverywhere.
So when M1 came a long, it should have been as simple as adding another architecture to a makefile, running builds and new plugins appear. In practice it wasn't that simple, for example I had to replace all my Intel Performance Primitives FFTs with KFRlib. I had to drop some features since the required libraries don't exist for M1 yet (REX).
Apple is still selling Intel Macs, and they support their machines for around 10 years, so I think supporting Intel Macs is going to be something we need to do for at least 10 years.
I image most developers will still support Intel Macs as long as the latest Xcode supports them, once it doesn't, that's when developers will probably think the deadache isn't worth it.
