Custom C plug-in works in 2018, not 2019 - where to put it?

Hi folks. Years ago, I wrote a USD exporter in C:

For many years, to install it, I just dragged it into the app’s plug-in directory:

/Applications/SketchUp\ 201/

This doesn’t work for SketchUp 2019 - it tells me my app is damaged. I assume this is because the app and its bundle is signed, which is fine.

So how is one supposed to load a custom C plug-in into SketchUp 2019? Is there someplace off one’s home directory that I can put it?

Did your exporter (years ago) use the old C++ API ?

If so, that API has been deprecated for 6 YEARS (or more) and has been removed in the latest release (v19.2.) New exporters (and importers) need to switch to use the newer C API.

There has been a “migration” help document included within the SDK archive for years that should help give you pointers.

Also a new “live” model getter function was just added (it is exported by the application only and is not available to standalone SDK use, … ie, in 3rd party applications.)

No, it uses the C API.

Well then it isn’t that old.
I myself can’t help much with signing issues as I’m not a Mac person. Sorry.

@Barry would be the Mac guru (former Apple employee) on the SketchUp team to ask.
He has posted many times using terminal commands to solve issues like this.

Seems like I’ve read about issues like this here in the forums.
(But I cannot find much now, so I must be using the wrong search terms.)

I did find something by @thayer re Corrupted Launch Services …

Maybe, @slbaumgartner or @john_drivenupthewall have run into this kind of thing ?

So I’m still thinking … “What changed between v18 and v19?”

And I just remembered that the C API had a build bug that was NOT exporting the symbols properly for the Mac. (The Windows build was always fine.) They just noticed it the past few months or so. The latest version 19.2 (C API Version 7.1) is the only one that has the symbols correctly exported in the libs.

@drwave I betting that this is the difference you are seeing.
Which also means you’ll be needing to release 2 versions (one for pre-2019 and one new build linking to the proper libs for 2019+)


I never put anything

I believe you can access the exporter menu with ruby [@DanRathbun may clarify ]…

I do inject replacement nib files into .app/Contents/, so I’m not sure why your getting stopped…

I also run compiled bin scripts etc… from the standard Users plugins folder…

I did the mac port for this have a look…

jf-mesh-importer.rbz (13.7 MB)

EDIT: just had a look at github and I must say you like to make it hard for yourself :wink:

you don’t need to link externally to the SDK, as can bundle all the dependencies…

I’ll have a proper look when I get some time and maybe recompile…


Hey John, … if ya’ have time see if dropping his binary in the app/Contents/PlugIns/ folder will let your SketchUp run …

The .plugin importers and exporters are supposed to be just droppable in that folder.
On Windows they are DLLs and are dropped into the binary path’s “Exporters” and “Importers” folders. SketchUp automatically enumerates them when it loads, but has been known to crash if there are issues with any of these “plugins”.

Note that these drop in import/export “plugins” are not the same as Ruby/C extensions.

@drwave, yours won’t run [crashes SU on startup] and the source project won’t open in my version of Xcode?

but I just compiled the export to xml sample project in the SDK and dragged it into .app/Contents/PlugIns/ and it all works fine…

the issue seems to point to your code… (98.5 KB)


I am betting the reason is the libs linked to … see post 5.

Su2019 uses ruby 2.5 where 2018 is 2.2, not?
Edit: it seems you are not creating a ruby extension, so this comment is not making any sense.

That only applies for Live C API. Not importers/exporters.

Let me check up on this.

By the way, what version of OSX are you using?

I was using and older OSX, 10.11 along with SU2019.2 and was able to put the USD exporter into the app bundle. I’m guessing this is related to changes in OSX being stricter in not allowing anything to modify the app bundles.

I was also able to load from ~/Library/Application Support/SketchUp 2019/SketchUp/Plugins
Can you try this?

(I’m making a note to better document the installation paths.)

1 Like

I’m running this on 10.14.6, which is the latest shipping macOS version.

It certainly could be a combination of stricter OS and more recent app.

I will give it a try on an older version at home when I get a chance.

I remember ~/Library/Application Support/SketchUp 2019/SketchUp/Plugins

Working in the past and then there being some issue, but if that works, I’m much more comfortable with that solution for myself and anyone that wants to use the plug-in. I never liked putting stuff in the app bundle.

Thanks, will take a look at the old example. There’s a lot of moving parts here - updated versions of the app (both 2018 and then 2019) vs. what I tested against (first release of 2018), new versions of Xcode, macOS, etc.

Note to self: I will put in the README what versions of those pieces I’ve confirmed the binary works against.

Thanks for all the discussion. This has been niggling me for months, this is finally causing me to spend some more time to get clarity on what’s not working.

So I just confirmed with the SDK’s XmlExporter.plugin example, compiled on macOS 10.14.6 with Xcode 10.3 (both latest shipping versions), running SketchUp 2018 Version 18.1.1180

copying it to:

/Users/wave/Library/Application Support/SketchUp 2018/PlugIns

does NOT show up my 3D exporters, but if I move it to:

/Applications/SketchUp 2018/

It does show up. This agrees with my memory of trying to use the local version and it failing (I believe it used to work some number of years ago).

I then tried this same process on SketchUp 2019 Version 19.2.221.

copying it into:

/Users/wave/Library/Application Support/SketchUp 2019/PlugIns/

I didn’t see Xml as an export option, and if I copy it into the app bundle it shows up as an exporter.

With this setup, I then tried to build my latest version of my plug-in, and it doesn’t load into either.


  • the local install option does not work. I wish it did.
  • the example plug-in does work once installed in the app bundle, while my exporter doesn’t. So that puts the blame back on me, where I like it, as I can debug that :slight_smile:

I do code sign my plug-in (since I put a binary on the web), and the example is not code signed, so that might be related. That also may be why older binaries from my GitHub repo do load.

Another bread crumb, that perhaps someone at SketchUp w/access to the plug-in loading code - when I run SketchUp in the debugger, I see:

Cannot find plugin in /Applications/SketchUp 2019/

which implies that there’s some failed handshake between SketchUp and my plug-in. Would love to know what question it’s asking that my code is answering wrong…

Is this the USDExporter.plugin checked into the GitHub repo? Or a build of more recent source code?

Yes, it’s the one on GitHub (which I just updated yesterday).

I rebuilt everything clean here with the 19.07 release of USD and now everything seems to work (and I updated the binary and the README to reflect this). I think my previous confusion was just conflating a bunch of things, so getting clarity here via this discussion was very helpful.

I would still love to know if there’s a way to tell SketchUp to load this plug-in without having to copy it inside the app bundle. Any news on that?


inject_me = path_to_file
name = File.basename(inject_me)
su_tools = Sketchup.find_support_file('Tools')
new_name = File.join(su_tools, name)
File.rename(inject_me, new name)

or [escape the spaces in file paths]

ditto "#{path_outside_su}" "#{path_inside_su}"