It is possible for module versions to be incompatible, meaning that they can't be used together in a Forge app.
Trigger.io tries to identify some of these incompatibilities to help both module producers and consumers. Right now we inspect the uploaded module versions for build time issues. We look for pairs of module versions which will cause a Forge app to fail to build when both are included. The possible issues we currently look for are:
The Toolkit interface allows you to see incompatibilites for modules you develop. Look in the "Existing" tab to see each module version that you've uploaded. You should see either "No clashes detected" or an expandable section detailing the incompatibilities.
The clashes reported here are only between public modules versions (everything visible on the module index) and module versions in the same project.
Right now it's probably best to contact support@trigger.io.
The incompatibilities detected by Trigger.io all relate to symbol names. These can be resolved either by more careful naming or by sharing common library code in a separate module.
These are some tips to consider when developing a Forge module, which should help reduce introducing build time incompatibilities.
In objective C, the namespace for classes, functions and variables is flat, so
it's easy to introduce an incompatibility when writing a simple utility. E.g.
something like AppDelegate is very likely to get used somewhere else, so it's
a good idea to prefix these names with something unique, in the same style
as the API and alert classes:
alert_AppDelegate alert_API alert_EventListener alert_Util
If you want to use functionality from a library it might make sense to make that in a separate Forge module, which can then be marked as a dependency for your own module.
Important: Right now (platform v2.0.4) it's not possible to have inter module dependencies, this will be released in a platform update soon.