Liwu
Free Download

Is a MacBook Charge Limiter Safe?

2026-07-27

A MacBook charge limiter can be reasonable to use when you can verify where it came from, who signed it, why it needs privileged access, what network requests it makes, how it handles conflicts, and how to stop and remove it. No one checkbox proves that an app is completely safe; use the checks together, and do not approve access that the developer cannot explain.

Verified: Apple security documentation and current Liwu behavior checked July 27, 2026.

Why a charge limiter may need privileged access

A normal menu bar app cannot necessarily write the low-level charging controls it displays. A limiter may therefore install a privileged background helper that performs narrowly defined charging operations after you approve it in macOS.

The presence of a privileged helper is not, by itself, proof that an app is safe or unsafe. It raises the standard of evidence: the developer should explain why the helper exists, exactly what it can do, which app is allowed to call it, whether it uses the network, how it behaves when the visible app quits, and how to unregister it.

A six-point safety checklist

1. Download it from the official source

Start from the developer's official site or its documented release repository. Check that the site, app name, publisher identity, and release history agree. Avoid copies from download aggregators, reposted archives, or links whose ownership you cannot establish.

Action: find the download through the product's own site, then compare the domain and publisher name with its support, privacy, and release pages.

2. Check Developer ID signing and notarization

For software distributed outside the Mac App Store, Gatekeeper checks whether it comes from an identified developer, is notarized by Apple, and has not been altered. macOS also asks for approval the first time downloaded software opens.

Action: open the app normally and read the macOS prompt. An unexplained instruction to disable Gatekeeper globally or bypass a malware warning is a reason to stop. If the publisher offers signature-verification instructions, use them to confirm the Developer ID identity.

3. Understand the privileged helper

The helper's responsibilities should be narrower than “the app needs admin access.” Look for a concrete list such as reading battery and adapter state, applying charging commands, or enforcing a selected sleep rule. The developer should also describe which client is allowed to send commands to the helper.

Action: compare the permission request with the developer's system-access documentation before approving the background item in System Settings.

4. Check what leaves your Mac

Signing and notarization do not establish an app's complete network or data behavior. A useful privacy disclosure distinguishes local battery and configuration data from requests for updates, purchases, licensing, or other services.

Action: read the privacy policy for an exhaustive network boundary. Treat vague phrases such as “we value privacy” as incomplete unless they say what is sent, why, and to which services.

5. Avoid competing charge controllers

Two tools can make different decisions about whether charging should start or stop. macOS built-in charging features can also affect the result. A trustworthy limiter should document conflicts instead of promising that every other controller can remain active.

Action: use one charging controller at a time. If the reported level or status does not match the configured limit, disable the other controller and verify the behavior again. See how macOS Optimized Battery Charging and Charge Limit behave before diagnosing a conflict.

6. Confirm that Quit and uninstall are reversible

Closing a settings window, choosing Quit, disabling a background item, and deleting the app are different lifecycle events. The developer should say what happens to charging at each point and provide a complete helper-unregistration path.

Action: before installation, locate the documented Quit and uninstall steps. After removal, confirm that normal macOS charging has resumed and that the background item is no longer registered.

Warning signs

Pause before installing when you see any of these:

  • instructions to bypass Gatekeeper without a specific, verifiable explanation;
  • an unsigned build or a publisher identity that changes without explanation;
  • unexplained network traffic or an incomplete data-use disclosure;
  • persistence that is hidden from the user or absent from the documentation;
  • no complete removal path for a privileged helper;
  • claims that the app is absolutely or guaranteed safe.

What macOS verifies—and what it does not

Question What macOS can verify What the developer must explain What you can observe
Who published this build? Developer ID signature Official download and publisher identity First-launch dialog and official site
Was the distributed build checked? Gatekeeper and notarization ticket Release and notarization process Whether macOS accepts the build normally
Why is privileged access needed? User approval for the background item Exact helper responsibilities System Settings and app behavior
What data leaves the Mac? Not fully established by notarization Exhaustive network disclosure Privacy policy and observed traffic
Can it be stopped and removed? Background-item controls Quit and uninstall procedure Charging behavior and removal result

Developer ID signing helps establish who signed a build and whether it was altered after signing. Gatekeeper checks that identity, notarization, integrity, and first-launch approval. Apple's notarization service performs automated checks for malicious software and code-signing problems.

Those are valuable signals, but notarization is not App Review. It does not prove that every privileged action is appropriate, establish the app's complete network behavior, or guarantee how a future update will behave. Background-item approval gives you visible control; it does not replace understanding what the approved component does.

Liwu as a transparent example

Liwu publishes its boundaries across the Liwu safety and system access page, Liwu privacy policy, Liwu compatibility and lifecycle boundaries, and Liwu changelog. The official Liwu download points to the current distributed build.

According to those published boundaries and the current implementation:

  • the distributed app and helper are Developer ID signed and notarized;
  • macOS asks the user to approve one privileged background helper;
  • that helper reads local battery and adapter state and applies charging, sleep, and scheduled actions requested by the correctly signed Liwu app;
  • the helper makes no network requests, while the app's product-service requests are listed exhaustively in the privacy policy;
  • choosing Quit restores normal macOS charging control and stops the helper;
  • the safety page documents how to unregister both the helper and the app's background registration before moving the app to Trash.

These are vendor-published facts that users can inspect. They are not an independent security audit or a guarantee of complete safety.

FAQ

Does a root helper automatically make a charge limiter unsafe?

No. A helper can be a legitimate way to perform a narrow system operation, but its elevated privileges increase the importance of verifying its signature, responsibilities, client restrictions, network boundary, lifecycle, and removal path.

Does Apple notarization mean Apple reviewed the app?

No. Notarization is an automated Apple service that checks submitted software for malicious content and code-signing issues. It is not the Mac App Store's App Review process and does not evaluate every product decision or future behavior.

Should I disable Gatekeeper to install a charge limiter?

Do not disable Gatekeeper globally as a routine installation step. If macOS cannot verify a limiter, stop and ask the developer for a correctly signed and notarized build or a specific explanation. Apple warns that unsigned or unnotarized software can expose your Mac and data to malware.

Can two charge limiters run at the same time?

They can issue competing charging decisions, so use one controller at a time. If behavior is inconsistent, disable the other limiter or built-in charging control and verify the result before continuing.

How do I completely remove Liwu's helper?

First choose Quit Liwu so charging returns to normal macOS control. While Liwu is still in /Applications, run the following command once to unregister its helper and main-app background registration, then move the app to Trash:

LIWU_UNREGISTER=1 LIWU_UNREGISTER_MAIN_APP=1 /Applications/Liwu.app/Contents/MacOS/Liwu

The same maintained procedure is available on the Liwu safety page.

Sources