sindresorhus / LaunchAtLogin-Legacy

Add “Launch at Login” functionality to your macOS app in seconds
MIT License
1.55k stars 122 forks source link

Allow the usage of legacy approach on macOS 13.0 #86

Closed ulian-onua closed 1 year ago

ulian-onua commented 1 year ago

@sindresorhus thank you for your work on LaunchAtLogin. It is really smart and useful.

It would be great to make it possible to use the legacy approach on macOS 13.0.

Now (v.5.0.0) it is hardcoded in the code and it is impossible to change that in the app that uses LaunchAtLogin.

if #available(macOS 13, *) {
  isEnabledModern = newValue
} else {
  isEnabledLegacy = newValue
}

However, the legacy approach also works on macOS 13.0 and can be used by developers to test if it works with the app that uses LaunchAtLogin to check if it works with previous macOS versions (I understand that it is not the best way to test as it is better to have a machine with a certain macOS version installed but it is better than nothing).

Without this change, a developer has to add edits to the package code to run in legacy mode on macOS 13.0

So it would be great to have a variable or method to change the default type of the approach (legacy or modern). If you support this idea I could prepare a PR for that.

Thanks.

sindresorhus commented 1 year ago

I intentionally did not add this capability. You should test on the macOS versions you target. I don't want to encourage otherwise. Major macOS versions may have differences, even in the same API.

Setting up a VM is easy enough: https://github.com/insidegui/VirtualBuddy

ulian-onua commented 1 year ago

@sindresorhus the previous versions of macOS will not be changed in the future and I suppose that the feature implemented in your library was tested with them before you released it.

Since macOS 13.0 there is a new simple approach, I don't think that Apple will return to the previous one (with an additional helper application) in the future macOS version.

I agree with you that ideally is to test on every macOS version that the app targets (especially, if it is a public release) but there could be cases for internal apps where it could be omitted. I would rather let developers have the freedom to select the approach rather than hardcode it and the necessity to dig into your library and comment out parts of code.

Maybe you will change your opinion in the future about that.