It used to be relatively easy to find a plugin that did almost exactly what you wanted or something close to it, but I feel like the plugin development community for Sketch is dwindling. Every time I use something new or existing (plugins I depend on every day), it’s common for it to not work in new releases of Sketch. There have been a few instances of people hacking what is available on GitHub to get it working again, but support for plugins feels like it is dying. I’m not exactly sure what the solution is??
I understand your concern and there’s not a lot we can do form our end unfortunately. When we update Sketch to provide new features, some outdated plugins might break. It could help to contact the developers of the plugins that you’d like to see updated.
1 Like
I’ve contacted a few but most of the fixes have come from other devs still using Sketch.
Be great if the larger, more popular plugns could be considered as Sketch features to permanently add or roll into the product. 
I am amazed at the response of not a lot Sketch can do. This is the whole reason Figma has the foothold it has, a well supported plugin api and community. Last time I looked there was not even entries about breaking changes to the API in recent versions. Key plugin devs have abandoned the platform.
3 Likes
This is a peculiar response considering the situation is completely of Sketch’s own doing. You are moving to a new architecture and have made a conscious decision to no longer support plugin development. Don’t put this on the plugin developers.
7 Likes
I can only second that this became a major pain point for me. I heavily relied on Jason’s plugins to maintain my libraries and seeing him explaining what the roadblocks are is heartbreaking. There is someone who spends his private time to develop free plugins that provide immense value and you, Sketch, make it as hard as it can get for him to continue doing so.
You could a) document the APIs properly, b) communicate changes and especially breaking changes early and transparently and c) could invest into plugin developers. If you can’t or don’t want to do this, then you could at least ship new features to embed the most needed functions that are now solved by plugins into the app.
Still, i think you are not doing yourself a favour if you are making it hard to develop plugins. Please consider focusing on the plugin ecosystem much more.
4 Likes
Jason, our apologies, it surely isn’t what Jonne’s intended to say but I can totally see how it can go that way.
Now, being absolutely transparent with you folks, the problem is:
There’s this core issue where people do not employ our guidelines on Plugins API usage, our documentation exists, but people don’t want to follow it.
People use private APIs, instead of the official ones and the only way to truly document all the APIs that might change between versions is to effectively open-source the app, because people can theoretically get to anything. As I said before, the official docs we have published on the API that we do officially support exist, but people don’t want to use them.
Now, Jason, I know you’ve been a fantastic Sketch supporter and contributor all these years, lots of respect for your and other’s work. I do wish we can come to a better solution for everyone, but as of today, the plugin development community keeps migrating to the tool who offers the most users (fair!), and that’s not Sketch, it’s Figma’s.
Can we rewrite our plugins API? Yes we can, but rewriting our plugin APIs is a significant effort, and as a small team we have to choose where we spend our efforts. Doing that, together with just fewer people being interested in writing plugins in the first place, its for all those reason we have chosen to invest our time elsewhere as of late.
This can change, it’s not set in stone, and I’ll insist on saying, i’d love to work on a better solution, and if that comes in the form of features, i’m all ears.
(A former plugin on Sketch, Runner, is coming as an official feature soon).
as a sidenote: we’re deep down working on some major re-thinks of everything Sketch, so Jason (and other devs/designers alike), my DM’s are open if there’s interest and availability on your side in discussing these topics in depth, as users, as makers.
5 Likes
Hello Emanuel and thanks a lot for your detailed response!
While I’m sure Jason will have a few notes to add on his own, I (as a fellow plugin developer and a member of this community) also want to add some to the discussion.
There’s this core issue where people do not employ our guidelines on Plugins API usage, our documentation exists, but people don’t want to follow it.
[…]
People use private APIs, instead of the official ones […]
Maybe I’m reading this wrong, but it looks like Sketch has no idea why plugin developers often have to fall back to the native APIs and thus ignore the official JS API (and by extend the official documentation) and what could’ve been done to convert them?
If that’s so, I’m happy to revive my old post from “Sketch Friends” Slack circa 2021 which, I hope, will reveal at least some of the reasons:
👉 Click to show the post 👈
Re: https://sketchplugins.com/d/2419-why-are-sketchs-plugin-api-docs-so-incomplete – this post is also worth a read.
[…]
1. Why use this?
[…]
One major upside of using the official API package could be that it’s always up-to-date with the Sketch internals, but that’s not always true unfortunately – even with public updates – so we still have to test and tune things ourselves.
2. No clear API boundaries.
It’s not clear from the outside what exactly should be included into the JS API and what shouldn’t. Are some features not covered yet because nobody asked for them? Or are they not included into the JS API because the underlying Sketch feature is subject to a major update or even removal soon? We don’t know. There’s quite a lot of feature requests open in sketch-hq/SketchAPI, some of them been open for years without an answer.
Or maybe third-party developers should just use sketch-hq/SketchAPI as a “core” package and fix bugs/build their own APIs on top of that instead? Well, this brings us back to my previous point #1.
3. Maintenance and decision making.
Sketch JS API is not a regular open-source project because it relies on private Sketch implementation details knowledge not available to third-parties. This makes Sketch the sole owner and maintainer of the project, but the rules of decision making are not clear enough for a public project:
- How it is decided that a PR with a particular API update is worth merging into the official repository?
- Can the Sketch team provide feedback and suggestions on the internal API usage that we (third-party contributors) often have to “guess” based on Sketch.app disassembly and header dumps?
- If it doesn’t, who decides how a particular JS API feature should be implemented internally with native API? Are third-party developers even expected to use it in their PRs at all?
Now, it’s been a couple years and none of these core questions about the official JS API have been answered and no changes have been made to address any of them.
Not sure how you can build trust in the official API if there’s virtually no communication (except for Ale and Kevin posting occasional notes in the private Slack channel) and no clear guidance from the team. Basically, developers were/are still on their own even if they choose to rely on the (not that reliable – sorry, no offense!) official API.
Doing that, together with just fewer people being interested in writing plugins in the first place, its for all those reason we have chosen to invest our time elsewhere as of late.
That sounds like a proper reasoning and a perfectly valid one. Admitting that third-party developments are no longer a focus for the team is absolutely fine and I’m sure the community would understand that decision for their beloved design tool to become better in the long run. We just wanted a bit more clarity and transparency on the topic from day one.
But ghosting third-party developers and now blaming them (at least partially) on the current state of things in the ecosystem (which, to be honest, has been like this since forever)?
I admire Sketch as a product and a company (I even was on track to join the team one time – and I’d still join now if I had a chance). And I definitely don’t want to play the blame game and upset anyone involved.
Nor do I believe that any amount of sad posting will change the situation – at the end of the day it’s all up to Sketch and the only thing we as a community can do is to accept the new reality and to adapt (or not, and thus go gentle). This is still a sad post, but I couldn’t help myself, sorry.
4 Likes
Hey Dmitry!
I’ll insist, i’m far from blaming anyone, if anything, I’m forever thankful you devs take the opportunity to build on top of Sketch, that’s always something good, either by using the official API or resorting to any other methods. My take is that most of the support tickets we get are resultant of such deviations, and again, it doesn’t make us any upset, just a little more constrained on how far we can go to help fix it.
Our developer relationships have not been the best, I’ll own that, and it’s definitely something both I and Pieter always feel a little upset about, but yeah, as of today, I can’t promise any work on improving the existing API or release a new one, it’s just not doable considering the main mission, and trust me when I say, we’re working real hard on improving the fundamentals of Sketch in an unprecedented way, hopefully, allowing us to do better as an app, but also as a development friendly platform.
3 Likes
I have no idea if this belongs here. But yesterday @raulrincon gave me the tip to start Sketch in “Rosetta mode” in order to persuade a plug-in that no longer works to work together with Sketch:
Maybe this is also a possible workaround for one or the other plugin until the whole problem with the disappearing plugin support has either been solved or important plugin features have become official Sketch features.
Greetings from Germany
2 Likes
I’ll just add that if Ashung ever stops updating Sketch Automate I might jump off a bridge.
3 Likes
me too