I have found myself, many times, in exactly the same situation. I think a concurrency-compatible queue is basically essential for many kinds of pretty boring situations. I made one here, and it look a lot like an OperationQueue. But it also points to another implementation I found recently that is certainly different, but also might be interesting.
thanks, yes i saw that link in the video linked in OP. I am absolutely dumbounded swift concurrency and actors don't offer a trivial solution to that problem.
Author here. I'm not entirely sure why this project would be of interest, but I noticed it here so figured I'd provide a little more context.
The test suite is small, and there are no concrete results. This is because the very first truly stressful test I got to produced terrible results. Instead of continuing, I began investigating that more closely. I also opened up a developer support ticket (distinct from a Feedback) with Apple. Apple got back to me about 3 day later, pointing out a bug in my use of TextKit 2. I'm a long-time TextKit 1 user, and this stuff is new to me. I also write a lot of bugs.
TextKit 1 is a very fast system. But with this problem addressed, TextKit 2 now outperforms it by quite a bit. From a performance perspective, it seems really good so far.
These tests are being extracted from an editor project I work on. The tests themselves use the OSSignpost API for high-precision measurements combined with the XCText infrastructure for driving the UI and capturing the measurements. I've been using this combination for performance testing for a while now. It can be flakey a bit, but that's kind of the nature of UI testing sometimes. Still really great when it works.
The only truly interesting test is one that creates a 1 million line document, measures the loading time (extremely fast) and then measures the time it takes to navigate to the final line in the document. This exercises the layout system. It's really fast. On my machine TextKit 1 can do it in about 70 ms, and TextKit 2 in around 10. This isn't quite good enough for 120 fps UI on macOS machines that support it, but it's really close.
Live scrolling and window resize are both things I'm really interested in testing. But, the UI automation framework doesn't, as far as I know, have good ways of driving those interactions. But I may be able to cook something up. Ideas welcome!
I'm truly sorry to hear that you are disappointed. And I really do get it! The full story is long, but I can sum it up with: our number one request, by far, is support for more languages. Even since this release, we've still gotten requests for yet more not yet available.
The hope is that an open source extension system will make it much easier to add new languages and improve support for existing ones.
But, I also want to be really clear: if you aren't happy, contact us and we'll try to make it right. If you are willing, I'd also love to hear from you about problems and/or missing features. We prioritize requests from license holders over all others.
The only reason I was able to figure out how to use ExtensionKit at all was because of a chance encounter with an Apple engineer during WWDC that provided some needed information.
I'm sorry to disappoint, but ExtensionKit/Foundation do not make use of any Swift features in the way you describe. It's all just IPC (via XPC), so much of it is useable from ObjC, or even C!
Also, this does not provide a direct app-to-app communication channel. The extensions themselves must be separate executables and run within their own sandbox. I think the extension could communication with its containing app, but the system is not set up to do that. All your scheduling questions are really around how XPC works. The view itself is basically an image within your hosting app, so communication is entirely async to the other process.
> I think the extension could communication with its containing app, but the system is not set up to do that.
and on iOS, the containing app is likely not running (in a GUI context).
Typically, the extension is its own small program bundled within the app. The app can be run by an end user, while the extension can only be invoked via the extension mechanism.
Same thing on macOS. The containing app does not need to be running for the extensions to be active. You are right that the extension bundle can only be used by this mechanism, but interestingly the containing app can use its own extensions (though this may not make sense in many cases).
That's sad that it has a serialization layer. It makes sense, but it's not ideal or more performant than existing techniques.
I'm more interested in the extension handling after that IPC layer, it's usually non trivial to integrate the call into an existing app's threading model.
(author of that quoted blog post here). You are correct, there's nothing new about apps offering plugins/extension systems. What's new here is: this works across sandboxed apps, support for remote (out-of-process) views, and the extension permission and discovery system is entirely managed by Apple.
Like I mentioned in another comment most of this has been practice for awhile. The big one is discovery, but there have been techniques to fix that (like standard install locations). AU (v2, v3) is a good example.
I'm sorry it's working so poorly for you. 2.0 has some performance issues that do make it seem more like slow-open in a number of situations. We're working on it.
Honestly, dropping v11 for 2.0 was a really tough call. Adopting ExtensionKit, and getting that out the door right when v13 shipped was difficult, but that was the goal we set out for. Supporting v11 made a number of things more difficult, and SwiftUI was some of it. It was not strictly technically necessary, but it made it easier.
We did start off with just Go. After doing a bunch of infrastructural work, we added another, Ruby. We've just finished generalizing this, in a way that both more 1st- and 3rd-party extensions can be created. To date though, we've only gotten to Rust and Swift.
You did not. Aside from Rust and Swift, all the added languages are preliminary. A minimal extension is required to, for example, connect Chime up to an LSP server to get semantic features going like completions and diagnostics. We do not have a 1st-party extension built for C# yet.
That's more or less exactly what we've done. Our SDK does have support for LSP. But, unfortunately those extensions still need to be made. Or are you talking about a generic LSP extension that is server-agnostic? That is definitely buildable, but my experience has been that the experience tends to be a lot better when customized for a particular server.
https://github.com/mattmassicotte/Queue