Always-On Display is a system behavior—not a lit Lock Screen.

The owner lists Always-on Display for iOS 18.0 or later in MisakaX and misaka26. On a matched product/build it may expose the setting and dim Lock Screen, but it cannot add a low-refresh panel path or guarantee Apple-supported power, pocket, touch and privacy behavior.

The owner labels the AOD feature iOS 18.0+. That is a feature minimum, not the complete product compatibility range. Match ProductVersion and BuildVersion to the exact MisakaX or misaka26 release before testing; iOS 18 or 26 by itself is not sufficient.

Apple currently lists iPhone 14 Pro and Pro Max, iPhone 15 Pro and Pro Max, iPhone 16 Pro and Pro Max, iPhone 17, 17 Pro and 17 Pro Max. Apple lists iPhone Air too, with AOD off by default. Check Apple’s current model list because it can change.

Yes. Apple lists AOD on the base iPhone 17 and says its display has ProMotion with adaptive refresh rates. Older advice that AOD is always Pro-only is now outdated.

No. Apple says AOD is off by default on iPhone Air. That is normal official behavior, not evidence that a feature flag failed.

No software flag can replace panel hardware. Apple says its supported AOD displays can operate as low as 1 Hz. MisakaX exposes a capability value; the owner does not claim that it converts an older OLED, ProMotion panel or LCD into the same low-refresh display system.

No. OLED only describes how pixels emit light. It does not prove Apple-supported 1 Hz operation, AOD power management, pocket logic or burn-in mitigation for that model. The base iPhone 15 is OLED but Apple does not list it as an AOD model.

Apple specifies adaptive ProMotion up to 120 Hz for iPhone 13 Pro, but its technical specification does not list AOD. Do not infer a 1 Hz floor from the maximum refresh rate or the Pro label.

A public misaka26 issue reports visible AOD on one iPhone 13 after an application-package problem was worked around. That proves a possible interface outcome on one device; it does not measure refresh rate, battery use, pocket behavior or long-term stability.

A public report says AOD was visible on an iPhone 13 mini running iOS 26.1, while Tap to Wake worked only intermittently and returned to normal when AOD was disabled. Classify that as visible AOD with a touch regression, not a full pass.

Community demonstrations report a visible AOD interface on LCD devices, but an LCD still uses a backlight even for black content and cannot become OLED or acquire an Apple-supported low-refresh panel through MobileGestalt. Treat it as the highest power-uncertainty class.

Community guides report visible AOD on some iPads, including LCD models. The owner label is still only a capability claim. Verify the exact iPad panel, build, off conditions, touch behavior and battery use; do not describe it as native iPad AOD.

After locking, it should show a dimmed Lock Screen with glanceable time, widgets or allowed notifications. For an experimental result, also test touch/media controls and every relevant screen-off condition. A setting alone and a dim screen alone are incomplete proof.

Apple documents face down or obstructed, away from a paired Apple Watch, CarPlay, Continuity Camera, Low Power Mode, Sleep Focus and the user’s usual bedtime. Unsupported devices may not reproduce every condition; record each failed state separately.

On Apple’s supported path, yes: obstruction or a pocket should make the display completely dark. MisakaX and misaka26 issues report unsupported AOD remaining lit in a pocket. That is a power-management failure and a reason to remove the experiment.

The interface was exposed without matching obstruction or proximity behavior. A misaka26 report describes both face-down and pocket failures. Do not mask this with another flag; capture it once and return to the original state.

Apple documents Low Power Mode as a condition that turns supported AOD completely dark. If experimental AOD remains lit, it is not reproducing the official power state. If it turns dark, that is expected and not a no-effect result.

Apple documents Sleep Focus and the user’s usual bedtime as screen-off conditions on supported models. Test Sleep Focus separately from a simple Focus mode so the result is attributable.

First rule out expected conditions: face down or covered, Low Power Mode, Sleep Focus, CarPlay, Continuity Camera, usual bedtime or distance from a paired Apple Watch. If none apply, record the exact build and whether the Lock Screen appears briefly before going black.

No. Auto-Lock controls when an active iPhone dims and locks; delaying it can increase power use. AOD begins after the phone is locked and keeps a dimmed Lock Screen visible on supported models. Do not use Auto-Lock: Never to imitate or troubleshoot AOD.

Apple provides Show Wallpaper and Show Notifications controls on supported models. An experimental device may expose both, one or neither. Missing subcontrols are a partial interface state, not proof that the write failed completely.

It is a privacy choice. Review Lock Screen notification previews and access settings before testing. A dim screen can still reveal names, message previews, calendar items or widgets to someone nearby.

The legacy 2.0 release described Always-on Display vibrancy with auto-off on unsupported devices. The misaka26 owner page labels AoD Vibrancy for iOS 18.0+ and warns that it may affect other tweaks. The owner does not publish a brightness level, power cost or universal compatibility table.

Not for the first test. Apply AOD alone, verify the Lock Screen, off conditions, touch and battery, then decide whether a separate vibrancy test is worth the added write. Otherwise you cannot attribute brightness, heat or drain.

A historical release description paired vibrancy with auto-off wording, but that does not establish a universal proximity repair. Current issue reports still show pocket failures. Do not enable vibrancy as an automatic fix for a broken off condition.

There is no owner-published percentage and no controlled cross-model result. Panel, refresh behavior, brightness, wallpaper, notifications, signal, background activity, temperature and battery health all matter. Measure your own equal-duration A/B conditions and report percentage points per hour, not a universal claim.

No. It establishes what happened during that interval, not the cause. Compare one AOD-off baseline and one AOD-on interval of equal duration with the same starting range, network, Focus, wallpaper, charging, temperature and background activity.

Issue #36 reports a large drop after Dynamic Island, AOD, SOS and Boot Chime were enabled together on one iPhone 13 Pro Max beta build. It proves a multi-change complaint, not an AOD-only rate. This page therefore refuses to reuse its percentage as a prediction.

Record model/build, battery health, start/end percentage and time, room conditions, network, wallpaper/notifications, Low Power Mode, Focus and charging. Run the same duration once with AOD off and once with only AOD on. Avoid an update, restore or indexing period.

Charging hides discharge and adds heat, so it is not a useful drain comparison. For a short controlled test, keep the phone unplugged and safely placed. Never cover the device in a way that traps heat.

That describes StandBy, not ordinary AOD. Apple starts StandBy when a charging iPhone is stationary on its side; supported AOD models can keep that StandBy view on, while other models may require a tap, movement or Siri. Test the dim locked screen separately.

Apple explains that OLED image persistence may be temporary and that permanent burn-in can occur in extreme cases when the same high-contrast image remains at high brightness for a prolonged period. The available MisakaX evidence does not quantify extra risk. Remove abnormal static or over-bright states instead of promising zero risk.

LCD and OLED have different image-retention mechanisms, so the OLED burn-in explanation should not be copied to an LCD. The immediate concern for an experimental LCD AOD is that the backlight remains active, plus any observed heat, persistence or battery use.

Apple says image persistence is temporary and disappears after normal use, while burn-in is a persistent remnant associated with more extreme prolonged display conditions. A screenshot cannot capture panel-level persistence. Remove AOD and seek Apple display support if a remnant remains.

End the test, disconnect charging if applicable, move the device out of heat or direct sun and let it cool. Apple notes that thermal management can dim or black out the display and slow or stop charging, so a hot test cannot be used as clean AOD evidence.

Issue #344 reports moving music progress with unavailable previous, pause and next controls plus missing timestamps on one unsupported iPhone 15. That is a partial Lock Screen state. Do not add another tweak to patch it; revert if controls or wake behavior are unacceptable.

Public reports describe broken or intermittent Tap to Wake with experimental AOD. If it returns when AOD is disabled, preserve that A/B evidence and remove AOD. The separate TapToWake flag is not a universal repair and would add another variable.

A misaka26 report records the gesture bar remaining visible together with broken pocket behavior. That is a partial UI state and also creates static-content concern. Capture it once and restore; do not accept it as native AOD.

Success can describe the restore or reload stage. Issues #81, #115 and #362 show Apply/reboot followed by no AOD on builds outside the claimed route. Confirm the exact product/build and one required reload, save the log, then stop repeating Apply.

No. Repeated attempts are inconsistent community advice, not proof of a repair. They make the active state and rollback harder to attribute. Preserve one clean attempt and diagnose product/build or Apply separately.

Do not update as an experimental repair. A newer build can fall outside the product range; public reports show no effect on later betas. Revert first while the phone is reachable, verify the normal Lock Screen, then update for ordinary reasons.

First turn off the visible AOD setting if it is responsive, then use the matching MisakaX or misaka26 reset/revert path with the untouched device-specific MobileGestalt saved before the change. Perform the documented reload and verify Lock Screen, pocket behavior, touch, battery and temperature.

It can stop the visible behavior, but it does not prove the capability value or other display writes returned to baseline. If you want the experiment removed, use the matched reset/original workflow and verify the actual phone after reload.

Stop new writes. Record every tool and display flag, find the untouched pre-change MobileGestalt, undo the newest writer first and verify again. A newly extracted modified file is incident evidence, not the original. Do not borrow another device’s plist.

Include model, panel type from Apple specifications, ProductVersion, BuildVersion, product release/platform, AOD and Vibrancy selections, other simultaneous flags, reload, every off-condition result, touch/media behavior, timed battery comparison and reset result. Redact serial, UDID, IMEI, notifications, accounts and plist contents.

There is no zero-risk answer. The owner warns about bootloops, and public reports show no effect, pocket failures, touch failures, static UI and difficult attribution. Use a current backup and verified pre-change MobileGestalt, or do not test if restore, added drain or loss of normal wake behavior is unacceptable.