3 ms·

If I recall, it was mainly due to the market size, and to a lesser extent Apples xenophobic posturing toward 3rd party developer control. Information appliance

If I recall, it was mainly due to the market size, and to a lesser extent Apples xenophobic posturing toward 3rd party developer control. Information appliances like Mac are a streamlined workflow for Desktop Publishing, but are not intended to be repurposed in an arbitrary manner. For example, you would see a dozen choices for CAD or IDE solutions on PC, but there would only be 1 option that cost 1200% more on Mac (OS 7.5.3). Eventually the MacOS application/compiler options users had would slowly diversify under OSX/intel-cpu, but the M1/M2 architecture shift would drop again to burn down any progress people made opening the platform. The easy to cross-port GNU applications still cling to the underbelly of modern posix based MacOS, but you can guarantee it is an uphill battle to get anything deployed outside the Apple App store ecosystem build tree. Apples irrational need to monopolize their own ecosystem meant they always locked down their platform though obscurity and or DRM security. It is unfortunate Microsoft Windows 11 and Google Android still copied Apples worst design choices, as users had their control slowly stripped off hardware they purchased. Thus, most modern computer user interface design is just a sales funnel for App stores, and gentle racketeering. =3 https://www.youtube.com/watch?v=aFTyJDjfjG0 https://www.youtube.com/watch?v=aFTyJDjfjG0

jen20 2y ago
> to a lesser extent Apples xenophobic posturing toward 3rd party developer control. Classic MacOS didn't even have a first-party IDE. Everything was third-party. > but you can guarantee it is an uphill battle to get anything deployed outside the Apple App store ecosystem build tree. It's hard to even parse this sentence, to be frank, but any possible reading of it is nuts. It's trivial to install Nix on macOS and have basically every package available to you. Same with Brew, though it's less nice that way.
- Joel_Mckay 2y ago
  It is OK, people wouldn't know what is missing if they never saw the alternative. "It's hard to even parse this sentence" Try to cross-compile something on modern MacOS, and handle the DRM signing on another platform. For example, you are still going to need an active Apple Developer account to run https://quasar.dev https://quasar.dev for MacOS/iOS targets, or users are going to incur a bit of hassle running your code. It is ok, most people have trouble understanding each other at first. =3
  - samatman 2y ago
    > DRM signing In what world is code attestation Digital Rights Management? Is there even meaningful overlap between these two things?
    - Joel_Mckay 2y ago
      Indeed, App stores must sign the software on their platform to deploy, and offline binaries now require a valid registered Developer Account signed code in order to easily run. A bodged on ecosystem like Brew doesn't practically count here, as a signed-check block is functionally also preventing most users running unapproved code. It is marketed as a security feature, which is why it sounds odd to people inside the ecosystem. "Is there even meaningful overlap between these two things?" If one wants to target every platform, than people are ultimately forced to use a Mac with a Developer Account subscription. Accordingly, there is no practical guarantee your project will reach market (app store rejections are common)... or worse... some dimwit chooses a platform ecosystem specific language to really double-down on a bad investment. Hence, my opinion on the answer to the threads question: "Why did Borland ignore the Macintosh market?" Have a nice day =3
      - samatman 2y ago
        > App stores must sign the software on their platform to deploy This is true, or rather "developers must sign software in order to sell it on the App Store" is true, and I believe this is what you meant. That's attestation. It isn't DRM. > offline binaries now require a valid registered Developer Account signed code in order to easily run "Easily" here means one click. "Not easily", then, is three clicks. The dialog boxes tell you exactly what to do. This is needed the first time you open a program, after which it just opens. > A bodged on ecosystem like Brew doesn't practically count here Why don't Homebrew, Mac Ports, and Nix, count here? Practically, I mean. > as a signed-check block is functionally also preventing most users running unapproved code This just isn't true though, it isn't even in the same neighborhood as the truth. Most users are, in fact, able to: read a dialog which says "go to Privacy and Security", go to Privacy and Security, and click the button which lets them run unsigned code. > forced to use a Mac with a Developer Account subscription Yes, it's true, you do need to have a Mac (or borrow one, cloud code signing does exist) and pay $99 a month, to sign code. Or you can just release it. Weren't we talking about Digital Rights Management? I thought you were going to explain how code attestation is DRM. I haven't seen you do that yet, did you want to? > there is no practical guarantee your project will reach market (app store rejections are common) You can just sell software for the Mac. The App Store is completely optional. The checks involved in the attestation process are quite minimal and focus on whether your program is malware. Failing that, you can sell your mal^H^H^H software directly, and users will have to endure three clicks, instead of one, to open it for the first time.
- pjmlp 2y ago
  Object Pascal and MPW had something, but Metrowerks was clearly much better.
  - Joel_Mckay 2y ago
    CodeWarrior was mainly popular for PalmOS, but had numerous targets. It was a standard prior to the gcc getting mainstream recognition. =3
    - pjmlp 2y ago
      Not much of a standard on PC, other than being the way to produce Palm, Epoch and Symbian apps, until Nokia replaced it with Eclipse based tooling, Carbide.
      - Joel_Mckay 2y ago
        Metrowerks stuck around a long time in the embedded space. Eclipse was more of a phenomena in the Java/OO paradigm, but was often slow on older platforms. Still, many folks embraced the open ecosystem when it became popular. Symbian was 10 years ahead of their time, and brought a lot of new paradigms to mobile. Leaving the master signing key on a reset device was a teachable moment for most folks. =3
samatman 2y ago
> Eventually the MacOS application/compiler options users had would slowly diversify under OSX/intel-cpu, but the M1/M2 architecture shift would drop again to burn down any progress people made opening the platform. The easy to cross-port GNU applications still cling to the underbelly of modern posix based MacOS, but you can guarantee it is an uphill battle to get anything deployed outside the Apple App store ecosystem build tree. This entire paragraph is completely mystifying to me. What are you trying to say here? What uphill battle? What burned down progress?
- Joel_Mckay 2y ago
  "What are you trying to say here?" Any CTO foolish enough to rely on Apples partner offerings, had better plan on mitigating chaotic shifts in their architecture/legal/DRM policies... often primarily focused on locking out general purpose small firm software/hardware. i.e. The thread asks "Why borland" (or any sane company) would avoid Apple's walled garden ecosystem over the years. "What uphill battle?" Try to publish anything on their platform without signed software DRM, or integrated 3rd party hardware. Essentially your group will end up paying Apple with a tithe and legal encumbrances, as it is essentially a closed ecosystem from the users perspective. "What burned down progress?" The generic hardware around Intel cpus meant better support for standardized game engine GPU drivers, easier compiler ports, and alternate software sourcing ecosystems. The M2 was nice silicon... but few folks are going to invest years porting to Apples whimsical unicorn product trajectory for lower market share. lol "This entire paragraph is completely mystifying to me" That is because you don't yet understand most successful commercial software companies make money by reselling the same software, and not mired in the perpetual cost/liability of software porting to product-run specific chips. I was not specifically picking on Apple here if that was your concern. You would likely have needed to experience the OS8 and Desktop PowerPC deprecation to understand why people avoided Apple for years after. =3

jen20 2y ago

> to a lesser extent Apples xenophobic posturing toward 3rd party developer control. Classic MacOS didn't even have a first-party IDE. Everything was third-party. > but you can guarantee it is an uphill battle to get anything deployed outside the Apple App store ecosystem build tree. It's hard to even parse this sentence, to be frank, but any possible reading of it is nuts. It's trivial to install Nix on macOS and have basically every package available to you. Same with Brew, though it's less nice that way.

Joel_Mckay 2y ago
It is OK, people wouldn't know what is missing if they never saw the alternative. "It's hard to even parse this sentence" Try to cross-compile something on modern MacOS, and handle the DRM signing on another platform. For example, you are still going to need an active Apple Developer account to run https://quasar.dev https://quasar.dev for MacOS/iOS targets, or users are going to incur a bit of hassle running your code. It is ok, most people have trouble understanding each other at first. =3
- samatman 2y ago
  > DRM signing In what world is code attestation Digital Rights Management? Is there even meaningful overlap between these two things?
  - Joel_Mckay 2y ago
    Indeed, App stores must sign the software on their platform to deploy, and offline binaries now require a valid registered Developer Account signed code in order to easily run. A bodged on ecosystem like Brew doesn't practically count here, as a signed-check block is functionally also preventing most users running unapproved code. It is marketed as a security feature, which is why it sounds odd to people inside the ecosystem. "Is there even meaningful overlap between these two things?" If one wants to target every platform, than people are ultimately forced to use a Mac with a Developer Account subscription. Accordingly, there is no practical guarantee your project will reach market (app store rejections are common)... or worse... some dimwit chooses a platform ecosystem specific language to really double-down on a bad investment. Hence, my opinion on the answer to the threads question: "Why did Borland ignore the Macintosh market?" Have a nice day =3
    - samatman 2y ago
      > App stores must sign the software on their platform to deploy This is true, or rather "developers must sign software in order to sell it on the App Store" is true, and I believe this is what you meant. That's attestation. It isn't DRM. > offline binaries now require a valid registered Developer Account signed code in order to easily run "Easily" here means one click. "Not easily", then, is three clicks. The dialog boxes tell you exactly what to do. This is needed the first time you open a program, after which it just opens. > A bodged on ecosystem like Brew doesn't practically count here Why don't Homebrew, Mac Ports, and Nix, count here? Practically, I mean. > as a signed-check block is functionally also preventing most users running unapproved code This just isn't true though, it isn't even in the same neighborhood as the truth. Most users are, in fact, able to: read a dialog which says "go to Privacy and Security", go to Privacy and Security, and click the button which lets them run unsigned code. > forced to use a Mac with a Developer Account subscription Yes, it's true, you do need to have a Mac (or borrow one, cloud code signing does exist) and pay $99 a month, to sign code. Or you can just release it. Weren't we talking about Digital Rights Management? I thought you were going to explain how code attestation is DRM. I haven't seen you do that yet, did you want to? > there is no practical guarantee your project will reach market (app store rejections are common) You can just sell software for the Mac. The App Store is completely optional. The checks involved in the attestation process are quite minimal and focus on whether your program is malware. Failing that, you can sell your mal^H^H^H software directly, and users will have to endure three clicks, instead of one, to open it for the first time.
pjmlp 2y ago
Object Pascal and MPW had something, but Metrowerks was clearly much better.
- Joel_Mckay 2y ago
  CodeWarrior was mainly popular for PalmOS, but had numerous targets. It was a standard prior to the gcc getting mainstream recognition. =3
  - pjmlp 2y ago
    Not much of a standard on PC, other than being the way to produce Palm, Epoch and Symbian apps, until Nokia replaced it with Eclipse based tooling, Carbide.
    - Joel_Mckay 2y ago
      Metrowerks stuck around a long time in the embedded space. Eclipse was more of a phenomena in the Java/OO paradigm, but was often slow on older platforms. Still, many folks embraced the open ecosystem when it became popular. Symbian was 10 years ahead of their time, and brought a lot of new paradigms to mobile. Leaving the master signing key on a reset device was a teachable moment for most folks. =3

samatman 2y ago

> Eventually the MacOS application/compiler options users had would slowly diversify under OSX/intel-cpu, but the M1/M2 architecture shift would drop again to burn down any progress people made opening the platform. The easy to cross-port GNU applications still cling to the underbelly of modern posix based MacOS, but you can guarantee it is an uphill battle to get anything deployed outside the Apple App store ecosystem build tree. This entire paragraph is completely mystifying to me. What are you trying to say here? What uphill battle? What burned down progress?

Joel_Mckay 2y ago
"What are you trying to say here?" Any CTO foolish enough to rely on Apples partner offerings, had better plan on mitigating chaotic shifts in their architecture/legal/DRM policies... often primarily focused on locking out general purpose small firm software/hardware. i.e. The thread asks "Why borland" (or any sane company) would avoid Apple's walled garden ecosystem over the years. "What uphill battle?" Try to publish anything on their platform without signed software DRM, or integrated 3rd party hardware. Essentially your group will end up paying Apple with a tithe and legal encumbrances, as it is essentially a closed ecosystem from the users perspective. "What burned down progress?" The generic hardware around Intel cpus meant better support for standardized game engine GPU drivers, easier compiler ports, and alternate software sourcing ecosystems. The M2 was nice silicon... but few folks are going to invest years porting to Apples whimsical unicorn product trajectory for lower market share. lol "This entire paragraph is completely mystifying to me" That is because you don't yet understand most successful commercial software companies make money by reselling the same software, and not mired in the perpetual cost/liability of software porting to product-run specific chips. I was not specifically picking on Apple here if that was your concern. You would likely have needed to experience the OS8 and Desktop PowerPC deprecation to understand why people avoided Apple for years after. =3