News for hackers. Stuff that matters.
Re:macOS Kernel Extensions are officially deprecated by pier25 on Thursday February 06, 2020 @01:11PM (#22258509)
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.

Re:macOS Kernel Extensions are officially deprecated by floatingatoll on Thursday February 06, 2020 @05:22PM (#22261093)
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.