A web viewer is part of a larger model delivery process. Before choosing one, decide where source files will be processed, how users receive authorized content, and what happens when a model revision changes.
Autodesk Platform Services (APS) and the Flinker IFC Viewer SDK illustrate two approaches. This comparison covers Autodesk’s documented Simple Viewer workflow and Flinker’s standard IFC loading path. It does not describe every possible deployment of either product.
Compare the model delivery paths
Autodesk’s Simple Viewer tutorial combines Authentication, Data Management, Model Derivative, and Viewer. Source designs are uploaded and translated before the resulting representation is opened in the browser.
Flinker’s SDK API accepts a filename and raw file bytes through viewer.add(name, bytes). In the standard IFC path, the application retrieves the source file and the viewer processes it in the browser.
| Concern | APS tutorial workflow | Flinker standard IFC path |
|---|---|---|
| Input to the browser viewer | A translated viewable. | Source IFC bytes supplied by the application. |
| Processing before display | A Model Derivative job prepares the viewable. | The browser processes the IFC. |
| Revision handling | Track source changes and the corresponding derivative. | Deliver the intended source revision to the viewer. |
| Operational considerations | Translation jobs, service credentials, and derivative availability. | File delivery, client resources, and browser behavior. |
Both approaches render interactive content in the browser. They allocate the preceding model-processing work differently.
Map the responsibilities around the viewer
Your application still needs to authenticate users, authorize project access, retrieve the intended revision, and handle failed requests. Browser processing does not remove those responsibilities or eliminate the need for application infrastructure.
In a derivative workflow, include translation status, retries, and outdated results in the design. The APS data and derivatives tutorial demonstrates model upload and translation handling.
Document each system that receives source content, derived data, credentials, or telemetry. Flinker’s architecture guidance separates model processing from technical metadata. A statement that IFC processing runs locally should not be read as a claim that the entire application makes no network requests.
Choose according to the application's formats and workflows
If IFC is the primary model format and your application already owns file delivery and revision management, evaluate whether direct browser processing meets the requirements without adding a derivative service.
If the application accepts several design formats or already uses Autodesk services, evaluate the APS processing workflow against that broader requirement. Check the supported formats and required integrations for the actual deployment.
Include coordination and information review in the prototype where they matter. For example, the Flinker SDK documents loading BCF files and selecting topics. Test the required topic, viewpoint, and element-reference behavior rather than treating a standard’s name as proof that every workflow is covered.
Measure representative model loads
Architecture identifies the work to measure; it does not establish a performance winner. Use the same production models, target devices, browsers, and network conditions when comparing options.
- Measure time to useful interaction and total model-open time.
- Record peak browser memory and responsiveness during navigation.
- Test repeated loading, multiple models, and representative low-specification devices.
- Measure preprocessing separately where translation is required.
- Replace a source revision and test how outdated or failed results are handled.
Use the results to choose the processing path and operating model your team can support. Document the tested model sizes and device limits with the integration so that later projects can assess whether the decision still applies.