4 ms·

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, Power

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.

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.