| name | ifc-impl-library-selection |
| description | Use when choosing which IFC implementation library to use for a project, or when unsure which tool reads and writes IFC files for a given language, platform, or target IFC version. Prevents picking a library that does not fit the language or platform, expecting this package to teach a library API, asserting an unverified IFCx Rust library, and confusing schema migration with geometry conversion. Covers the library landscape (IfcOpenShell, web-ifc, xBIM, IFC++), the language and platform decision matrix, routing to the owning OpenAEC skill packages, and the emerging state of IFC5 and IFCx tooling. Keywords: IFC library, IfcOpenShell, web-ifc, ThatOpen engine_web-ifc, xBIM, XbimEssentials, IFC++, ifcx-rs, which IFC library should I use, read IFC in Python, parse IFC in the browser, IFC in dotnet, IFC in Rust, IFC WASM, library decision matrix, pointer skill, which tool for IFC, how do I open an IFC file in code, "library does not support my IFC version", "no IFC library for my language", "IFC parsing is too slow", "cannot install the IFC library", what software reads IFC files, getting started with IFC code.
|
| license | MIT |
| compatibility | Designed for Claude Code. Requires IFC IFC2x3, IFC4, IFC4.3, IFC5, IFCx. |
| metadata | {"author":"OpenAEC-Foundation","version":"1.0"} |
ifc-impl-library-selection
IN DEVELOPMENT : subject to change. IFC5 and IFCx are not released standards.
The IFCx Rust tooling named in this skill is emerging and unverified ; treat
that row as a moving target. The IFC2x3, IFC4, and IFC4.3 library guidance
below is stable.
This is a POINTER skill. It routes a reader to the right IFC implementation
library and to the OpenAEC skill package that owns that library's detail. It
does NOT teach any library API. The IFC skill package teaches the IFC standard
itself : schema, entities, formats, geometry, version evolution. Library APIs,
installation, and code belong to the dedicated per-library packages.
For the IFCx data format see ifc-core-ifcx-architecture. For changing a
file's schema version see ifc-impl-version-migration.
Quick Reference
The package-boundary rule
- ALWAYS treat a library as a pointer here : name it, state what it does, route
to the owning package. NEVER write library API calls, install commands, or
code snippets in this package.
- ALWAYS pick the library by language, platform, and target IFC version, in
that order. The language is the hardest constraint : a .NET project cannot
consume a Python library.
The library landscape
| Library | Language | Runtime / platform | Verified IFC version coverage |
|---|
| IfcOpenShell | Python and C++ | desktop, server, CLI ; embedded in Blender via Bonsai | IFC2x3, IFC4, IFC4.3, plus runtime-loaded schemas |
web-ifc (ThatOpen engine_web-ifc) | TypeScript and C++ compiled to WebAssembly | browser and Node.js | reads and writes IFC ; exact version list is owned by the ThatOpen package |
| xBIM Toolkit (XbimEssentials) | C# / .NET | .NET desktop and server | IFC2x3 and IFC4 |
| IFC++ | C++ | native desktop applications | C++ IFC implementation ; exact version list owned by the IFC++ project |
NEVER assert an IFC version a library supports beyond the "verified" column.
When a project needs a version not listed as verified, route the reader to the
owning package or project to confirm.
Routing to the owning OpenAEC package
| Library | Owning package for API detail |
|---|
| IfcOpenShell | Blender-Bonsai-ifcOpenShell-Sverchok skill package |
| web-ifc | ThatOpen skill package |
| xBIM Toolkit | no OpenAEC package : route to the xBIM project documentation |
| IFC++ | no OpenAEC package : route to the IFC++ project documentation |
Hard rules
- ALWAYS match the library language to the project language first. This filters
the list before any other criterion.
- ALWAYS route library API questions to the owning package. This skill answers
"which library", never "how to call it".
- NEVER recommend
IfcConvert for changing an IFC schema version : it is a
geometry / file-format converter. Schema-version migration is the ifcpatch
Migrate concept. See ifc-impl-version-migration.
- NEVER assert a concrete repository for IFCx Rust tooling. No
ifcx-rs
repository is verified to exist. Refer to it only as "emerging Rust tooling
for IFCx".
- NEVER present a community Rust project as an OpenAEC package.
Decision Trees
Which library for which language and platform?
What language and platform is the project?
|
+-- Python (data pipeline, automation, server, CLI)
| --> IfcOpenShell owning package : Blender-Bonsai-ifcOpenShell-Sverchok
|
+-- TypeScript / JavaScript, runs in a browser or Node.js
| --> web-ifc owning package : ThatOpen
|
+-- C# / .NET (desktop or server)
| --> xBIM Toolkit no OpenAEC package : xBIM project docs
|
+-- C++ (native, high-performance desktop)
| --> IfcOpenShell (C++ core) or IFC++
| --> IfcOpenShell owning package : Blender-Bonsai-ifcOpenShell-Sverchok
|
+-- Rust
| --> emerging only : see the IFC5 / IFCx branch below
|
+-- Blender add-on / 3D authoring inside Blender
--> Bonsai (built on IfcOpenShell)
owning package : Blender-Bonsai-ifcOpenShell-Sverchok
Which library for which target IFC version?
What IFC version must the project read or write?
|
+-- IFC2x3 or IFC4
| --> any of IfcOpenShell, web-ifc, xBIM (all cover this range)
|
+-- IFC4.3 (infrastructure : roads, rail, ports)
| --> IfcOpenShell has verified IFC4.3 coverage.
| For web-ifc, confirm IFC4.3 coverage with the ThatOpen package.
| xBIM verified coverage is IFC2x3 and IFC4 only : confirm IFC4.3
| support with the xBIM project before relying on it.
|
+-- IFC5 / IFCx (.ifcx JSON)
--> see the next tree : tooling is emerging, not production-ready
IFC5 / IFCx tooling : emerging
Does the project target IFC5 / IFCx (.ifcx JSON) ?
|
+-- Yes
| --> Tooling is in development. IFC5 and IFCx are not released standards.
| NEVER treat IFC5 / IFCx library support as production-ready.
| Rust tooling for IFCx exists only as emerging work : NEVER assert a
| concrete repository. Community Rust projects exist (clearly labelled
| community, NOT OpenAEC). See ifc-core-ifcx-architecture.
|
+-- No --> use the language / version trees above.
Library question, or API question?
What is being asked?
|
+-- "Which library should this project use?"
| --> this skill : the decision matrix above
|
+-- "How do I call this library / install it / write this code?"
--> NOT this skill. Route to the owning package :
IfcOpenShell -> Blender-Bonsai-ifcOpenShell-Sverchok package
web-ifc -> ThatOpen package
xBIM, IFC++ -> the project's own documentation
Patterns
Pattern : select by primary language first
ALWAYS filter the library list by the project's implementation language before
weighing any other factor. A library is only usable from its own language
ecosystem : IfcOpenShell from Python or C++, web-ifc from TypeScript or
JavaScript, xBIM from .NET. The language constraint is absolute and removes
most of the table immediately.
Pattern : select by deployment target
After the language filter, confirm the deployment target fits :
- Browser or Node.js front end : web-ifc compiles to WebAssembly and runs
client-side at near-native speed.
- Desktop or server batch processing : IfcOpenShell (Python or C++) and xBIM
(.NET) run natively without a browser runtime.
- Inside Blender : Bonsai, which is built on IfcOpenShell.
Pattern : route to the owning package
Once a library is chosen, ALWAYS hand off API detail to the owning OpenAEC
package : IfcOpenShell to the Blender-Bonsai-ifcOpenShell-Sverchok package,
web-ifc to the ThatOpen package. For xBIM and IFC++ there is no OpenAEC
package : route the reader to the project's own documentation. This skill stops
at the recommendation ; it never crosses into API teaching.
Pattern : handle an IFC5 / IFCx request honestly
When a project asks for IFC5 / IFCx (.ifcx) support, state plainly that IFC5
and IFCx are in development and that tooling is emerging, not production-ready.
Name Rust tooling only as "emerging" : NEVER assert a repository such as
ifcx-rs, which is unverified. If a Rust pointer is needed, community projects
exist and MUST be labelled community projects, never OpenAEC packages. Route
the reader to ifc-core-ifcx-architecture for the format itself.
Pattern : do not confuse the two "convert" tools
A reader asking to "convert an IFC file" wants one of two unrelated things.
Changing the IFC schema version is the ifcpatch Migrate concept, covered by
ifc-impl-version-migration. Converting IFC geometry into a mesh or non-IFC
format (OBJ, glTF, DAE) is IfcConvert. NEVER recommend IfcConvert for a
schema-version change. Both tools' API detail belongs to the
Blender-Bonsai-ifcOpenShell-Sverchok package.
Reference Links
references/methods.md : the full library landscape detail, capabilities,
owning packages, verification status, source URLs.references/examples.md : worked library-selection scenarios by language,
platform, and target version.references/anti-patterns.md : the library-selection mistakes and why each
one fails.
Related skills : ifc-core-ifcx-architecture, ifc-impl-version-migration,
ifc-impl-format-transcoding, ifc-core-validation.
Authoritative sources (see SOURCES.md) :
