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
| Header | What 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:
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.