Skip to main content
TablePro reads its update preferences from the com.TablePro domain before falling back to the values inside the app. A managed preference written by MDM therefore wins over anything a person picks in Settings > General. The switch is not dimmed: it takes the click, and then reads back at the pinned value. Three keys decide the behavior. Pinning SUAutomaticallyUpdate on its own does nothing while SUEnableAutomaticChecks is false. Sparkle derives the install setting from the check setting, so the install never runs and the switch stays dimmed. A profile that turns off background updating entirely:
One that keeps updates flowing but checks weekly:
Deploy either as a com.TablePro payload through whichever MDM the fleet runs.
Pinning SUEnableAutomaticChecks to false means security fixes never arrive on their own. Pair it with whatever process pushes the new build instead.

What this does not change

Check for Updates… still works and still reaches the feed. It is a person asking, not a background check, so no key here suppresses it. Signature checking is not configurable. Every build is verified against the EdDSA public key inside the app before anything installs, and there is no key that turns that off. Privacy covers what an update check sends.

Auditing what a Mac is set to

A key that reads does not exist is unset, and the shipped default in the table above applies.