For the record, in regard to the Live C API in general:
The read-only live C API wasn’t really complete until SU2019.2 that was just released. While the symbols has been exported on Windows a couple of versions ago, mac did not export the C API symbols from the SketchUp app.
People working with the live C API on mac up til now have been linking against the standalone SketchUpAPI.framework which have appeared to mostly work. But this isn’t the correct way to consume it, and will lead to incorrect behaviour (such as not getting the cutout holes in faces) or in some cases crashes (SUSectionIsActive for instance.) Since it mostly appeared to work, this went under our radar.
We will provide better documentation to how the Live C API should be consumed. What we currently have is the licensed_ruby_extension example in the SDK package. But it’s not clear exactly what is going on. I’ll describe below - and we’ll get this documented publicly.
Windows:
Link against sketchup.lib.
If you link against SketchUpAPI.lib (the standalone version) you will run into the same issues as described before.
Mac:
Don’t link against SketchUpAPI.framework - due to same issues as above.
Instead add the path to the SketchUpAPI.framework to you Framework Search Paths in your Xcode project. This will allow Xcode to locate and use the header for the API.
To allow the project to build you must set the Bundle Loader to the path of the SketchUp application on your machine. Xcode will use the symbols exported from that binary when it links.
Both of the above is demonstrated in the licensed_ruby_extension (just not explained in detail).
Additionally we added SUApplicationGetActiveModel as the official way to obtain the model pointer for live C API. This saves you from doing the boilerplate of calling Ruby and interpret_cast’ing the pointer address. We will leave model.skpdoc(true) working! For backwards compatibility with existing users of the API. But going forward you should prefer SUApplicationGetActiveModel.