@chris1 If you want Windows, Mac, and Linux support, you should look at IfcOpenShell. It offers similar functionality to xBIM as you described your needs above, but is a bit more portable, and can be used in C++ instead of C#, and also offers Python bindings. It also uses OpenCascade.
IfcConvert is a light wrapper on top of IfcOpenShell.
There are many other utilities included with IfcOpenShell that are not advertised on the homepage, including IfcCOBie (to and from COBie spreadsheet templates), IFCCSV (partial data export and import of IFC to and from CSV), IfcDiff (comparisons between IFC files), IfcPatch (execute predefined templates to modify IFC data), IfcClash (clash detection in IFC), … etc, they are all also cross platform.
Going through Blender is not necessary nor recommended.
Most BIM authoring programs treat IFC as a monolithic import and export procedure with very limited capabilities to import or export portions of the model or IFC data. They do not stream data, nor write diffs. An export for a complex project may take an hour. An import will take another hour.
Any conversion of IFC into a raw geometry format (e.g. OBJ) will lose a huge amount of data, as OBJ cannot capture the same depth of metadata and relationships that IFC can.
Methods to mitigate this data loss include converting an IFC into two formats, a geometry format (e.g. OBJ, glTF, DAE) plus a data format (e.g. XML, JSON), which are correlated on the client-side (web, Unity, etc) at runtime.
Might I convince you otherwise? IFC can store this data and it is the perfect place to store it!
A word of warning that some BIM authoring platforms do not maintain these IDs correctly. For example, in Revit,
IfcZones created from rooms (can be important in environmental calculations) have a new ID generated with every export. Another example is
IfcDistributionPort objects. I also warn that some BIM autohring programs don’t expose the ID very easily within their native interface.