Adding support for controllers involves having them physically present to create and test the mappings. You can create the profiles yourself. It’s not very hard but takes a little bit of manual trial and error.
First, you’ll want to fire up the TestInputManager scene on device (or run it in the Unity editor for desktop systems). The controller should come up as an unknown controller if InControl doesn’t support it and will list a bunch of analogs and buttons. Fiddling with the controls will show you which inputs respond as which buttons and analogs.
Then copy one of the profiles in InControl/Source/Unity/DeviceProfiles and adjust it accordingly. Other than the button/analog mappings, you have to make sure the IncludePlatforms array property contains the right string in it and the Matchers array property should have a matcher with the NameLiteral field containing the name exactly as it appears to Unity in GetJoystickNames(). This also shows up in the TestInputManager scene when run.
Similarly, if you want to add support for the native input module, the profiles are located in InControl/Source/Native/DeviceProfiles. The primary difference is device matching is usually based on hardware vendor ID and product ID values instead of a name string. Just look at one of the other native profiles and you’ll see an example of this. These will also show up on screen.
The Matchers array can contain multiple matchers, where necessary, to cover multiple devices that have the same mappings, although generally it is preferred to make two separate profiles unless it is two models of the same controller (e.g. Dual Shock 4 has two models/versions with identical mappings). Matchers can also make use of a NamePattern field instead of NameLiteral, which allows for regular expression matching.
If you have a full working profile, you are welcome to send it in for official inclusion in the package.