Launched this week
PylibKit: Python as a Swift SDK

PylibKit: Python as a Swift SDK

CPython + curated wheels, wrapped in Swift async APIs

2 followers

Visit website
PylibKit lets iOS/macOS apps use Python libraries—including C-extension and Rust-backed wheels—without exposing Python to app code. Everything is bundled into a single Swift XCFramework. You call generated Swift services with async/await, receive Swift types, and never touch PythonObject. We handle CPython, pinned wheels, asyncio safety, threading, signing, and reproducible builds—so app teams can focus on features, not toolchains.
PylibKit: Python as a Swift SDK gallery image
PylibKit: Python as a Swift SDK gallery image
PylibKit: Python as a Swift SDK gallery image
PylibKit: Python as a Swift SDK gallery image
Payment Required
Launch tags:SaaS•Developer Tools•Tech
Launch Team
NMI Payments
NMI Payments
Don’t Integrate Payments Until You Read This Guide
Promoted

What do you think? …

HeeJun Gwon
Maker
📌
We built PylibKit out of frustration. Every time we wanted Python in an iOS/macOS app, more time went into packaging CPython, native extensions, SSL/libffi, codesigning, simulator/device splits, and CI reproducibility than into the actual product. So we changed the model. Instead of “embedding Python,” we treat Python as a versioned SDK dependency. PylibKit: 1. Bundles CPython and curated, pinned wheels (yes, C/Rust ones too) 2. Generates Swift-first façades so app code stays 100% Swift 3. Runs Python on a dedicated executor-owned thread 4. Enforces asyncio safety by design (no loop or reference mixing) 5. Produces deterministic, reproducible, signed XCFrameworks Swift developers call async/await. Python stays in the engine room. We’d love feedback on: 1. Which Python modules or use cases you’d want first 2. Where the Swift API could feel even more “Swifty” Our goal is simple: use Python as a hidden engine, without compromising the Swift developer experience.