The tapi tool produces .tbd files which summarize the visible interface to a dylib or Framework. Much like we did with abidw, we can use tapi to produce a lookaside file describing the interface to a library, allowing us to elide relinks when a dylib was updated in a way that does not affect its interface.

One limitation is that, unlike abidw, tapi uses the mangled symbol names which do not include return types. There isn't a great workaround for this, but it is probably mitigated by assuming reasonable header discipline: if you alter the return type of a function you almost surely updated the header as well, such that all clients need to recompile anyway.

Another limitation is that tapi requires that the LC_UUID be promulgated to the .tbd file if it is to be accepted by the linker to replace the underlying dylib at link time. This can be worked around by running tapi twice, once with and once without the --\no-uuid flag, and using the UUID containing .tbd file for linking (the Xcode linker will do this anyway), and the other for the ABI lookaside definition.

Performance of tapi actually seems quite good, so running it twice doesn't seem to be an obstacle, unlike abidw which is quite expensive.

Longer term, we should investigate tools like llvm-ifso and clang-tapi which might allow us to easily extend this to non-darwin based platforms.

A final benefit is that the macOS linker may be able to link faster when linking via .tbd files - a nice side benefit.