Headers

Anything that uses the shared preference store or the licensing API needs the TI_Support headers at build time, and the dylib at run time. The dylib is installed with TweakInject; the headers you download.

Where to get them

headers.zip, on the TweakInject releases page, next to the .dmg. It is published with each release, so the headers you build against match the TI_Support that ships with that version.

What is inside

HeaderWhat it declares
TILicense.h Licence checks and the dispatch macros. Header-only: the inline half is compiled into your tweak.
PSPreferences.h CoreFoundation-style C access to the preference store.
PSUserDefaults.h The NSUserDefaults-shaped class.
PSPreferenceController.h The protocol a custom settings pane adopts.

The zip carries each header twice: once under include/, and once loose at the top. Point -I at whichever suits your project layout.

Building against them

Unzip somewhere your build can reach, add it as an include path, and link the dylib:

Build
clang -dynamiclib -arch arm64e \
    -isysroot "$(xcrun --show-sdk-path --sdk macosx)" \
    -I/path/to/headers/include \
    /Library/TweakInject/TI_Support.dylib \
    -o MyTweak.dylib MyTweak.m

In a theos Makefile that is _CFLAGS for the include path and _LIBRARIES = TI_Support with _LDFLAGS = -L/Library/TweakInject.

Keeping them in step

Headers and dylib come from the same source, so a tweak built against newer headers than the TI_Support on the machine can reference something that is not there yet. If you use a function the installed dylib does not export, the tweak fails to load rather than misbehaving. Build against the release you expect people to be running.