4 ms·

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

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.

dkonofalski 7y ago
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.
- AlanYx 7y ago
  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.
  - dkonofalski 7y ago
    >new frameworks like AVAudioEngine on OS X 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.
    - AlanYx 7y ago
      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.
  - michaelrmmiller 7y ago
    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...)
    - AlanYx 7y ago
      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.
- Wowfunhappy 7y ago
  > 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?
  - wtallis 7y ago
    > What x86 processor doesn’t support 32bit code? 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.
- wwweston 7y ago
  "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.
  - spsful 7y ago
    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.
    - wwweston 7y ago
      > 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?
scarface74 7y ago
Counterpoint: BareBones software has continuously updated BBEdit as Apple transitioned from: - 68K Classic MacOS - PPC Classic MacOS - PPC OS X - x86 MacOS
- flomo 7y ago
  However BareBones did drop TextWrangler, and that's one of the thing that's going to keep me on Mojave for a while.
  - wl 7y ago
    What's the issue with using BBEdit in free mode?
    - flomo 7y ago
      Didn't know it existed - thanks!
- selectodude 7y ago
  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.
  - scarface74 7y ago
    And what’s the problem with paying for software you use?
    - selectodude 7y ago
      Nothing. But it's in their best interest to keep it working since they're going to charge you for the upgrade that continues to work.
      - scarface74 7y ago
spsful 7y ago
A caveat: the notarization is not forced. Apps can still run even if they aren't notarized, it just takes an extra click.

dkonofalski 7y ago

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.

AlanYx 7y ago
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.
- dkonofalski 7y ago
  >new frameworks like AVAudioEngine on OS X 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.
  - AlanYx 7y ago
    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.
- michaelrmmiller 7y ago
  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...)
  - AlanYx 7y ago
    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.
Wowfunhappy 7y ago
> 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?
- wtallis 7y ago
  > What x86 processor doesn’t support 32bit code? 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.
wwweston 7y ago
"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.
- spsful 7y ago
  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.
  - wwweston 7y ago
    > 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?

scarface74 7y ago

Counterpoint: BareBones software has continuously updated BBEdit as Apple transitioned from: - 68K Classic MacOS - PPC Classic MacOS - PPC OS X - x86 MacOS

flomo 7y ago
However BareBones did drop TextWrangler, and that's one of the thing that's going to keep me on Mojave for a while.
- wl 7y ago
  What's the issue with using BBEdit in free mode?
  - flomo 7y ago
    Didn't know it existed - thanks!
selectodude 7y ago
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.
- scarface74 7y ago
  And what’s the problem with paying for software you use?
  - selectodude 7y ago
    Nothing. But it's in their best interest to keep it working since they're going to charge you for the upgrade that continues to work.
    - scarface74 7y ago

spsful 7y ago

A caveat: the notarization is not forced. Apps can still run even if they aren't notarized, it just takes an extra click.