mattiemass

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!

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.

If you have any other questions, let me know!

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.

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).

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.

Practically speaking, that's still basically an SDK. It's all over XPC, but the interface still needs to be defined.

(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.

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.

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.

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.