At Ordo One, we needed a fast fuzzy string matcher in Swift for interactive search over 250K–1M financial instruments. Swifts case-insensitive substring matching was too slow and too rigid for a real interactive UX. We looked at existing Swift libraries (Fuse-Swift, Ifrit, FuzzyMatchingSwift) which didn’t meet our performance or quality bar, so we built our own — partly to see how far Claude Code could take it with careful guidance.
It turned out: quite far.
Why fuzzy matching?
Users make typos (“Goldamn”), type incrementally (“gol”), and expect smart matches like abbreviations (“bms” → “Bristol-Myers Squibb”). Plain substring search can’t handle this well. Fuzzy matching supports typos, prefixes, substrings, and word-boundary shortcuts — essential for any real search field.
Scope
Built for financial instruments, but applicable anywhere with large, messy datasets: code symbols, file names, product catalogs, contacts. High performance also makes it ideal for portable devices (although we use it on the macOS desktop primarily).
What it is
FuzzyMatch is a pure Swift (6.2+) library with two modes:
- Edit Distance (Damerau-Levenshtein) — strong typo tolerance and prefix handling
- Smith-Waterman — local alignment (like fzf/nucleo), better for multi-word/code search
Both share a single API, zero-allocation hot path, multi-stage prefiltering, Span-based zero-copy access in the internal implementation, and strict Sendable conformance.
Performance
On Apple Silicon (M3 Max, single-threaded):
- 18M candidates/sec (Edit Distance)
- 31M candidates/sec (Smith-Waterman)
This outperforms lowercased().contains()with almost 10x while allowing for fuzzy matches.
1M dataset: ~55 ms single-threaded, ~5 ms with 16 workers, so scales nicely.
Quality
Benchmarked against nucleo (Rust), fzf (Go), and RapidFuzz (C++/Python) using 271K instruments and 197 queries:
- 98% overall accuracy (Edit Distance) — best in comparison
- 100% typo handling (41/41)
- 100% prefix, substring, exact name, and ISIN categories
- Smith-Waterman trades some typo accuracy for ~1.7× throughput
The reference systems scored ~79–82%.
Includes 500+ tests, 95%+ coverage, fuzzing via LLVM, and structured quality and performance benchmarks vs the other libraries on a reference data set.
The Claude Code experiment
This started as a test: could Claude Code (Opus 4.6) build a non-critical but real feature quickly?
From first line to open source release took ~3–4 days:
- Two algorithm modes with prefiltering
- 22 test files with 500+ tests
- Simple Fuzz harness
- Benchmark suite
- Algorithm docs
- DocC API docs
- Trivial sample app (
fuzzygrep)
Claude wrote nearly everything (code, tests, docs, benchmarks, sample app). We steered architecture, reviewed changes, and validated against real datasets. This isn’t “one prompt → library” — it required tight guidance — but the breadth achieved in days would’ve taken much longer manually.
fuzzygrep can even fuzzy-search a 1B-line file in just over a minute — mainly as a showcase.
We also defined a release workflow in CLAUDE.md: benchmarks and quality comparisons are re-run, docs are reconciled with implementation, and performance numbers refreshed — keeping everything in sync.
We wouldn’t use this approach for core systems. And LLMs won’t replace solid engineering anytime soon. But for testable, non-critical, black-box components, it’s pragmatic — like adding a dependency, except tailored exactly to your needs.
In our case: typo-tolerant, prefix-aware fuzzy matching with performance suitable for interactive search on large datasets.
Why open source?
The results exceeded expectations. The Swift ecosystem lacked high-performance fuzzy matching, so we open sourced it: zero dependencies, fully Sendable, Swift 6.2+, documented with DocC.
If you need fast, interactive fuzzy search — give it a try.
GitHub - ordo-one/FuzzyMatch: Fuzzy string matches at full speed
Joakim
