You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Fixed
doctor reported "Numbers.app not found" on every Mac that had upgraded, even with Numbers running in front of you. The check tested two hard-coded paths, /Applications/Numbers.app and /System/Applications/Numbers.app. Apple's 2026 iWork refresh renamed the bundle to Numbers Creator Studio.app and moved the bundle ID from com.apple.iWork.Numbers to com.apple.Numbers, so neither path could ever match again and the check emitted a permanent false warn telling users the formula and formatting tools were unavailable when they were fine. Only the diagnostic was wrong — the AppleScript tools themselves target the app by name (CFBundleName is still Numbers), so set-formula, set-cell-style, set-column-width/set-row-height and merge-cells/unmerge-cells were working the whole time. Detection now tries the known paths (including the new name) and then falls back to Launch Services, resolving path to application id for com.apple.Numbers and then the pre-2026 com.apple.iWork.Numbers. That is a registry lookup: it does not launch Numbers and needs no Automation permission. Resolving by bundle ID rather than by path is what makes the check survive the next rename too, and accepting both IDs keeps it correct on machines that never upgraded. The reported detail now names the resolved bundle path, so a surprising location is visible rather than silently accepted. A Launch Services answer pointing at a path that no longer exists (a stale registration) still warns.