_mattt

Author / creator here. I built this because integrating LLMs into Swift apps meant juggling completely different APIs for MLX, llama.cpp, CoreML, Ollama, and cloud providers. AnyLanguageModel gives you a single interface modeled on Apple's Foundation Models framework.

GitHub repo here: https://github.com/mattt/AnyLanguageModel

Happy to answer questions about the implementation or trade-offs we made.

For your listening pleasure, here's a supercut of Melvyn's iconic intro: https://pascalwyse.com/blog/2017/12/15/in-our-time-machine

Update — Source is now available here: https://github.com/NSHipster/sosumi.ai

Update — Source is now available here: https://github.com/NSHipster/sosumi.ai

Following up — I just pushed a fix for this. This latest version significantly improves how references like protocol conformances and default implementations are rendered.

Amen to that. It's funny how virtues like accessibility and good API design matter just as much as ever in this new era. Good ideas don't go out of style.

Hi Saagar! One could indeed use this method to export this information en-masse, however that would require the kind of automated access that the site ToS explicitly forbids.

For the Swift standard library and other open-source frameworks, you could probably extract this from documentation comments using DocC, Jazzy, or the like.

I think HTML -> Markdown is a bit of a red herring.

In many cases, a Markdown distillation of HTML can improve the signal-to-noise ratio — especially for sites mired in <div> tag soup (intentionally or not). But that's an optimization for token efficiency; LLMs can usually figure things out.

The motivation behind Sosumi is better understood as a matter of accessibility. The way AI assistants typically fetch content from the web precluded them from getting any useful information from developer.apple.com.

You could start to solve the generalized problem with an MCP that 1) used a headless browser to access content for sites that require JS, and 2) used sampling (i.e. having a tool use the host LLM) to summarize / distill HTML.

This is only possible for some of Apple‘s open source Swift code, including the Swift standard library. This is not the case for hundreds of other SDK frameworks, such as SwiftUI.

Even for those open source projects, there is still some value added in the generated documentation that isn’t directly available from documentation comments, such as type members and protocol conformances (though a LLM could certainly suss that out with the right context).

Thanks for pointing that out. That’s most likely a mistake in how I’m translating into Markdown. I’ll look into this.

Great idea! I just added that. Try clicking the icon in the header.

Once upon a time, I built a project called `swift-doc`, which eventually got Sherlocked. I think what I was most upset about was their decision to call their thing "DocC". Like, adding redundant consonants to avoid name collisions is my shtick.

Long live Jazzy.

In my experience, coding agents seem to do a normal fetch when provided links. Which makes sense — headless browser automation is expensive, and only really necessary for interacting with a webpage.

But with these RLHF'd AIs, being confident and helpful as they are, it took me a while to realize that they couldn't actually read the Apple developer links I was giving them. Like a kid who can't read the chalkboard, but doesn't realize they need glasses.

I agree, it'd be great if Apple provided accessible documentation in the first place. Time was, Apple published self-contained docsets that you could download and read offline.

Apple's ToS pretty explicitly forbid the kind of automation required to download everything. But even if someone did that, it'd only be a snapshot in time. And a lot can can change between OS releases.

As for the hosted web app, I wanted to provide this as a public service. I plan to open source it, so anyone can self-host instead, if they're inclined.

Not yet, but I plan to open source it soon. Just gotta tidy up a little bit, you know?

Sure, here are a few more examples:

- https://developer.apple.com/documentation/swift/tasklocal

- https://sosumi.ai/documentation/swiftui/button

- https://sosumi.ai/documentation/foundation/measurement

Most of the docs about the language itself live on swift.org (e.g. https://docs.swift.org/swift-book/documentation/the-swift-pr...). I've had pretty good luck getting Claude to write modern Swift code by saying things like "Use Swift 6 structured concurrency instead of GCD". But I could totally see expanding sosumi to include swift.org content, too.

Edit: Another Swift developer life hack: for new language features, copy-pasting the Swift Evolution proposal works pretty well! https://github.com/swiftlang/swift-evolution/tree/main/propo...

Thanks for troubleshooting with us. Glad you got it to work!

What version of macOS are you on? We've been building for macOS 15.3 (Sequoia), but haven't tested earlier versions...

Mattt here, co-creator of emcee.

Thanks! Yeah, having everything just work gives me the same goosebumps that I remember from back in the Web 2.0 days.

One of the next steps for us is to expand emcee beyond just tool use. MCP has concepts [1] for prompts and resources (files, db records, etc.), and it'd be great to support those, too. Right now, emcee creates a 1:1 correspondence between OpenAPI operations and tools, but there should be heuristics or annotations to establish that, say, `GET /prompts/{id}` manages a prompt.

[1]: https://modelcontextprotocol.io/docs/concepts/architecture

Mattt here, co-creator of emcee.

Carl and I are working on a PaaS for deploying agents, and emcee has given us a nice way to quickly prototype these kinds of workflows.

We can take a handful of OpenAPI specs for code deployed on our platform, and have Claude calling tools without any extra setup. That's been really helpful for figuring out how to get the LLM to pick the right tool for the job.

It's also been interesting to see just how far you can get with tool calling on its own. Normally, you have to write some kind of UI or client code to interact with a platform. But with emcee, we've been able to take a tool-driven development approach, using Huma [1] to generate OpenAPI endpoints for our Go web API, and talking to our service first through Claude, before making a UI or SDK.

And to your point, I think MCP could be really powerful as a connection point to various clients, servers, and hosts — a lot like LSP [2] for IDEs and programming languages. I'd love to hook emcee up to Zed, for example, to give the AI assistant even more context to do its thing.

[1]: https://huma.rocks [2]: https://microsoft.github.io/language-server-protocol/

SemBr author here. I chose SHOULD NOT for this rule for a couple reasons: First, as an affordance for text with ambiguous or unknown meaning. Second, as a hedge against introducing new meaning unintentionally.

Adding a semantic line break inherently changes the relationship between words, and we can't always be sure about the intended meaning of text. If this were MUST NOT, then any modification would risk violating the spec.

Then again, this may be my own, idiosyncratic reading of RFC 2119. If you'd like to discuss this further, feel free to open an issue on the GitHub repo here: https://github.com/sembr/specification/issues

This is a great way of thinking about technical decision-making. I'm most familiar with this idea through the framing of "innovation tokens" from the essay "Choose Boring Technology" [1].

[1] http://boringtechnology.club