I Built Peko to Fix Native App Deployment
I Built Peko to Fix Native App Deployment
TL;DR: I think native application development has a release engineering problem. Building the app should be the hard part. Packaging, signing, screenshots, App Store assets, legal pages, deployment, and release pipelines should mostly disappear into the background. That's why I built
Native development has a release engineering problem
Every time I wanted to ship a desktop app, I found myself spending more time learning release engineering than improving my product. Code signing, notarization, icon sizes, installers, screenshots, recordings, App Store descriptions, CI, legal pages... none of those are why I got into programming.
I don't think developers should have to become release engineers just to ship desktop software.
My story
I've been interested in software since I was about eight years old. I started in Scratch making games, moved into game development, and eventually found web development. Something about building beautiful interfaces with HTML, CSS, and JavaScript just clicked with me.
I still think the web has the best UI system we've ever made. It is expressive, fast to iterate with, and capable of producing incredible user experiences.
Then I wanted those apps to feel native.
At first I focused on the runtime. Peko started as a cross-platform WebView runtime capable of embedding or connecting to web applications. As I kept building, I realized the runtime wasn't actually my biggest problem.
Shipping was.
I wasn't frustrated because I couldn't open a WebView. I was frustrated because every release felt like assembling ten different tools into one fragile pipeline.
That realization completely changed the direction of the project.
Peko today
Today I don't really think of Peko as "a desktop framework."
The runtime is still there, and it works similarly to other native WebView solutions, but that's almost the bonus now.
The real product is the developer pipeline.
Peko includes MIT licensed Studio tooling, CLI tooling (peko-tools), the standard library, and the UI library. The hosted platform is closed source because it powers cloud features like remote macOS builds, deployment, encrypted native bridges, asset generation, and legal hosting.
Pekoscript sits underneath as the native layer. It handles things like WebView startup, native integrations, packages, demos, and platform logic while the majority of the application stays in your web framework.
What building an app normally feels like
Finish app
↓
Figure out packaging
↓
Generate icons
↓
Configure signing
↓
Debug notarization
↓
Set up CI
↓
Capture screenshots
↓
Record videos
↓
Write store descriptions
↓
Host legal pages
↓
Upload everything
↓
Hope nothing breaks
What I want it to feel like
Finish app
↓
Write demo script
↓
peko deploy
↓
Receive:
✓ Signed bundles
✓ Store screenshots
✓ Store recordings
✓ AI drafted descriptions
✓ Legal document links
✓ Release package
↓
Submit
The development pipeline
Create project
↓
Build frontend (React, Vue, etc.)
↓
Need native functionality?
↓
Use JS APIs or write a small Pekoscript module
↓
peko build --release
↓
(Optional) peko deploy
↓
Platform performs remote builds, signing,
asset generation, hosting and packaging
↓
Download final release bundle
Peko is intentionally an all-in-one system. You can absolutely build many of these pieces yourself, and experienced teams often do. But getting all of those systems working together takes time, experience, and maintenance. That isn't who I built this for.
Who I built it for
People with ideas.
Hobbyists.
Solo founders.
Small teams.
Developers using AI.
People who want the longest part of making software to be building the software itself.
Still growing
Peko is still a young public ecosystem, even though many of its systems have been evolving internally for the past five to six years.
There's still plenty to build. Unified App Store payments and verification are next, followed by even tighter store integrations that remove more manual release work.
The goal hasn't changed.
Keep shrinking everything between "my app works" and "my users can install it."
If you're interested, I'd genuinely love feedback.
Email: preston@pekoui.com
Contact form: https://pekoui.com/contact
Where Peko Stands Today
One thing I want to make clear is that Peko isn't just an idea or a roadmap.
You can use Peko today.
Today the ecosystem includes:
- The MIT open source Peko Studio
- The MIT open source CLI (
peko-tools) - The MIT open source standard library
- The MIT open source UI library
- The hosted Peko Platform
- Cross-platform native bundling
- Remote macOS and iOS builds
- Signing
- Package management
- Deterministic app demos
- Automated App Store screenshots and recordings
- AI-assisted store descriptions
- Hosted legal document links
- Unified release packaging
Right now, deploying with Peko ends with a single ZIP file containing everything you need to publish:
- Signed application bundles
- Generated screenshots
- Generated screen recordings
- AI-drafted store descriptions
- Store metadata
- Links to hosted legal documents
From there, the remaining work is mostly creating your listing in each store, uploading the bundle, and completing the review process.
The next major milestone is a unified in-app purchase platform that wraps Apple, Google, and Microsoft payment APIs behind one API, along with hosted server-side receipt verification. That is planned for the next month.
After that, the focus is deeper App Store integration so even more of the publishing process becomes automatic. I don't expect there to ever be a completely hands-off publish button because every store has review requirements, but I do think the amount of manual work can become very small.
If this sounds like the kind of tooling you've wanted, I'd love for you to give Peko a try.
This isn't meant as a marketing stunt. I'm genuinely looking for developers who care about this problem and want to help shape the platform while it's still young.
You can get started at https://pekoui.com, email me directly at preston@pekoui.com, or use the contact form on the website.