Xml example code still using slapi.framework?

So I’m finally trying to switch over my plug-in to install by default for SketchUp 2016 instead of 2015.

But SketchUp 2016 seems to be missing the slapi.framework that the example uses, and I assume it was replaced with SketchUPAPI.framework, but I’m concerned that the example doesn’t reference it.

Anybody at Trimble want to talk about this?

@drwave, I checked the samples xml_to_skp and skp_to_xml sample and see that we are using SketchUpAPI.lib. Which example from 2016 SDK is using slapi.lib and how are you checking for the same?


Hmm, where’s the link to the latest SDK?

I just downloaded “SDK_Mac_16-0-19913”, and looking at:


In the Target XmlImporter in Build Phases->Run Script I see:

xcrun install_name_tool -change @rpath/slapi.framework/Versions/Current/slapi @executable_path/…/Frameworks/slapi.framework/Versions/Current/slapi $BUILT_PRODUCTS_DIR/$EXECUTABLE_PATH

And I see the same issue with the exporter in the same place:


So to be clear - it looks like both examples are linking against the local copy of SketchUpAPI.framework, but then when you try and install that plug-in in the app, it won’t load because it can’t find the library it linked against, because the reference wasn’t rewritten to point to the one in the app bundle. Make sense?

it seems to be missing the 'Framework Search Path’s when compared to ‘ReadingFromAskpFile’, which has them listed, before any build attempts…

I have built it in a previous version and there were a couple of gotcha’s then as well…


Yea, the correct solution seems to just change Framework search paths to look in

/Applications/SketchUp 2016/SketchUp.app/Contents/Frameworks/

and don’t worry about rewriting it with the shell script. That has the advantage that you will pick up the latest version of the SketchUpAPI.framework that is in your local copy of the app.

I’m really hoping someone at Trimble will update the sample code to do this, since this kind of stuff can be really confusing to folks that are not familiar with this kind of stuff on the Mac platform.

that’s a good idea for ‘in’ SU usage…

but a lot of people write importers/convertors for external apps without SU being installed on the end users computer…

I assume that’s the reason for including it in the SDK…


Sure, but I’m specifically talking about a SketchUp plug-in example that’s expected to run inside of SketchUp.