4 ms·

Developers who are affected by this (and who were on top of last summer's announcements) knew this day was coming, and have been working on updates since then.

Developers who are affected by this (and who were on top of last summer's announcements) knew this day was coming, and have been working on updates since then. 10.15 serves as a testbed that supports legacy kernel extensions as well as the new user-space frameworks (e.g. EndpointSecurity and NetworkExtension) that largely replace the deprecated APIs. Developers that have a revision ready to test against the first 10.16 beta this summer should be in good shape (assuming that Apple doesn't swerve wildly between 10.15 and 10.16 cough 64-bit Carbon cough). Yes, the documentation is scanty in places, and there is some missing functionality at the moment. And the support burden on these companies, once 10.15.4 ships, will be a pain ("It's OK, the software still works, don't worry about that alert message"). But it is incorrect to say that Apple has not given developers time to react.

pier25 7y ago
> knew this day was coming Certainly but the problem is that such changes should be announced years in advance. Cocoa, OpenGL, ObjC... all are going to die some day and Apple will probably announce it 1 year before it happens, at the most.
- floatingatoll 7y ago
  OpenSSL was deprecated 8 years ago and hasn’t been removed yet. Your bet of 1 year is not well-supported by their historical trends on Carbon, x86 32-bit, PowerPC, 68k, Garbage collection, and so on. Unless you’re suggesting that Apple will only give 1 year’s notice when they remove deprecated features - in which case, they might only give 0.25 years (at WWDC), which happens quite frequently.
  - 1over137 7y ago
    Past cases need not match future cases. They've been tossing things faster than in the past.
    - floatingatoll 7y ago
      The shortest on my list is GC, which they removed after a short 4 years of deprecation. I'm short on examples of things that were deprecated one year and then removed the next couple years. If you have some? They could remove Perl/Python/Ruby this year, having only deprecated them last year. Historically they're not inclined to do so, but I'd expect those to be left deprecated until some event permitted their removal to be more convenient (like "new architecture added", which would force a global recompile, at which point lots of deprecated things can go away more smoothly — OpenSSL, OpenGL, P/P/R, etc.)
  - pier25 7y ago
    What do you think is the sensible strategy when Apple deprecates a feature? Directly jumping on the provided alternative is basically doing beta testing for Apple. Very often the alternative is not ready yet. For years after it was announced Swift was not production ready. SwiftUI will probably replace Cocoa but again it is not production ready yet (and doesn't work on the majority of Macs). What if there is no alternative? There are many crossplatform projects that rely on OpenGL and moving to Metal is problematic since it's an Apple only API. No replacement for Carbon either because at some point Apple decided to abandon the port to 64 bits. How much time should one wait before fully jumping, say, into Swift? Nobody knows. Apple could announce today that it plans to kill ObjC by 2025 and give devs a good picture of what it's going to happen and its commitment to X feature. I suspect the problem is that not even Apple knows when it will finally decide to do that. There is a lot of uncertainty. How can one decide to start a new macOS project today without knowing how long that investment will last? For example if you invested heavily in OpenCL a couple of years now you'd have to rewrite all that code to Metal. Or moving from ObjC to Swift. Or moving from OpenGL to Metal. Etc. This is a luxury that not everyone can afford and Apple doesn't seem to care. No wonder Apple is the only big developer working on macOS exclusive products and they are trying to bring over iOS devs via Catalyst.
    - floatingatoll 7y ago
      Spend the six months after WWDC-announced deprecation porting your use cases and reporting bugs and evaluating whether it’ll be easy or hard to flip the switch if you need to. Each WWDC thereafter, either test your deprecated code for surprise breakage on the new betas (this happens), or remove your deprecated code if the betas remove support for it. If you aren’t committed to reviewing, testing, and updating your codebase annually (or shutting down products that are no longer a good fit, like iDefrag) then you should probably not develop for Apple platforms. If you’re concerned that there’s not enough revenue to support this every year, then you should reevaluate your position on subscription revenue models or accept that you’ll operate at a loss re: keeping your platform up-to-date.
Wowfunhappy 7y ago
> cough 64-bit Carbon cough I'm treading extremely old ground, but fwiw: I don't fault Apple for pulling 64 bit Carbon from Leopard. It makes sense—the OS had already been delayed and they had to cut stuff in order to ship. But I find it totally bizarre that they never shipped 64 bit Carbon. Why wasn't it in Snow Leopard? Heck, Lion even. Catalina's nixing of 32 bit would be a lot less painful if Carbon apps had some kind of upgrade path.
- duskwuff 7y ago
  > But I find it totally bizarre that they never shipped 64 bit Carbon. I don't. Carbon was a >20-year-old codebase which had always ran on a 32-bit system. I wouldn't be surprised at all if they simply determined that there was too much code which would have to be rewritten to run correctly on 64-bit.
  - Wowfunhappy 7y ago
    A usable 64 bit carbon actually exists in the Leopard developer preview.
  - vaxman 7y ago
    You think 20 years is a sign that a codebase needs to be replaced? 20 years is nothing (/grabs your lips and makes them say "NSObject"). Don't talk to me about code quality either, just because something is old doesn't mean it's bad (or good) it just means it's old. This is especially true for "the last 20 years" in particular (that featured elimination of most American tech workers with more than 20 years experience during the dot-com crash followed by a six year timeout where upon most American universities did not graduate many CS majors and those that did had no real "industry mentoring", just Google searches and blog sites.) IN MOST CASES, THE QUALITY OF THE OLD CODE FROM BEFORE THAT ERA IS GOING TO BE FAR SUPERIOR TO THE CODE PRODUCED DURING THAT PERIOD. Things are just now (14 years after the new CS majors began to arrive at their desks) starting..and I do mean starting..to get back to normal (the people who infested the industry in the absence of such formally trained talent are still around, many have whipped investors into FOMO, allowing them to live very well and thus be influential and even exploitative of the younger formally trained CS majors, instead of the other way around).

pier25 7y ago

> knew this day was coming Certainly but the problem is that such changes should be announced years in advance. Cocoa, OpenGL, ObjC... all are going to die some day and Apple will probably announce it 1 year before it happens, at the most.

floatingatoll 7y ago
OpenSSL was deprecated 8 years ago and hasn’t been removed yet. Your bet of 1 year is not well-supported by their historical trends on Carbon, x86 32-bit, PowerPC, 68k, Garbage collection, and so on. Unless you’re suggesting that Apple will only give 1 year’s notice when they remove deprecated features - in which case, they might only give 0.25 years (at WWDC), which happens quite frequently.
- 1over137 7y ago
  Past cases need not match future cases. They've been tossing things faster than in the past.
  - floatingatoll 7y ago
    The shortest on my list is GC, which they removed after a short 4 years of deprecation. I'm short on examples of things that were deprecated one year and then removed the next couple years. If you have some? They could remove Perl/Python/Ruby this year, having only deprecated them last year. Historically they're not inclined to do so, but I'd expect those to be left deprecated until some event permitted their removal to be more convenient (like "new architecture added", which would force a global recompile, at which point lots of deprecated things can go away more smoothly — OpenSSL, OpenGL, P/P/R, etc.)
- pier25 7y ago
  What do you think is the sensible strategy when Apple deprecates a feature? Directly jumping on the provided alternative is basically doing beta testing for Apple. Very often the alternative is not ready yet. For years after it was announced Swift was not production ready. SwiftUI will probably replace Cocoa but again it is not production ready yet (and doesn't work on the majority of Macs). What if there is no alternative? There are many crossplatform projects that rely on OpenGL and moving to Metal is problematic since it's an Apple only API. No replacement for Carbon either because at some point Apple decided to abandon the port to 64 bits. How much time should one wait before fully jumping, say, into Swift? Nobody knows. Apple could announce today that it plans to kill ObjC by 2025 and give devs a good picture of what it's going to happen and its commitment to X feature. I suspect the problem is that not even Apple knows when it will finally decide to do that. There is a lot of uncertainty. How can one decide to start a new macOS project today without knowing how long that investment will last? For example if you invested heavily in OpenCL a couple of years now you'd have to rewrite all that code to Metal. Or moving from ObjC to Swift. Or moving from OpenGL to Metal. Etc. This is a luxury that not everyone can afford and Apple doesn't seem to care. No wonder Apple is the only big developer working on macOS exclusive products and they are trying to bring over iOS devs via Catalyst.
  - floatingatoll 7y ago
    Spend the six months after WWDC-announced deprecation porting your use cases and reporting bugs and evaluating whether it’ll be easy or hard to flip the switch if you need to. Each WWDC thereafter, either test your deprecated code for surprise breakage on the new betas (this happens), or remove your deprecated code if the betas remove support for it. If you aren’t committed to reviewing, testing, and updating your codebase annually (or shutting down products that are no longer a good fit, like iDefrag) then you should probably not develop for Apple platforms. If you’re concerned that there’s not enough revenue to support this every year, then you should reevaluate your position on subscription revenue models or accept that you’ll operate at a loss re: keeping your platform up-to-date.

Wowfunhappy 7y ago

> cough 64-bit Carbon cough I'm treading extremely old ground, but fwiw: I don't fault Apple for pulling 64 bit Carbon from Leopard. It makes sense—the OS had already been delayed and they had to cut stuff in order to ship. But I find it totally bizarre that they never shipped 64 bit Carbon. Why wasn't it in Snow Leopard? Heck, Lion even. Catalina's nixing of 32 bit would be a lot less painful if Carbon apps had some kind of upgrade path.

duskwuff 7y ago
> But I find it totally bizarre that they never shipped 64 bit Carbon. I don't. Carbon was a >20-year-old codebase which had always ran on a 32-bit system. I wouldn't be surprised at all if they simply determined that there was too much code which would have to be rewritten to run correctly on 64-bit.
- Wowfunhappy 7y ago
  A usable 64 bit carbon actually exists in the Leopard developer preview.
- vaxman 7y ago
  You think 20 years is a sign that a codebase needs to be replaced? 20 years is nothing (/grabs your lips and makes them say "NSObject"). Don't talk to me about code quality either, just because something is old doesn't mean it's bad (or good) it just means it's old. This is especially true for "the last 20 years" in particular (that featured elimination of most American tech workers with more than 20 years experience during the dot-com crash followed by a six year timeout where upon most American universities did not graduate many CS majors and those that did had no real "industry mentoring", just Google searches and blog sites.) IN MOST CASES, THE QUALITY OF THE OLD CODE FROM BEFORE THAT ERA IS GOING TO BE FAR SUPERIOR TO THE CODE PRODUCED DURING THAT PERIOD. Things are just now (14 years after the new CS majors began to arrive at their desks) starting..and I do mean starting..to get back to normal (the people who infested the industry in the absence of such formally trained talent are still around, many have whipped investors into FOMO, allowing them to live very well and thus be influential and even exploitative of the younger formally trained CS majors, instead of the other way around).