The latest articles on DEV Community by Preston Brown (@iamprestonbrown). https://dev.to/iamprestonbrown https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4059835%2Fa5decd6e-f38d-4735-a826-3e6027d44e45.png https://dev.to/iamprestonbrown en Preston Brown Mon, 03 Aug 2026 04:17:43 +0000 https://dev.to/iamprestonbrown/i-built-peko-to-fix-native-app-deployment-4m7o https://dev.to/iamprestonbrown/i-built-peko-to-fix-native-app-deployment-4m7o <h1> I Built Peko to Fix Native App Deployment </h1> <blockquote> <p><strong>TL;DR:</strong> 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 </p> </blockquote> <p><a href="https://app.pekoui.com/blog/why-i-built-peko" rel="noopener noreferrer">Originally Posted on PekoUI.com</a></p> <h2> Native development has a release engineering problem </h2> <p>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.</p> <p>I don't think developers should have to become release engineers just to ship desktop software.</p> <h2> My story </h2> <p>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.</p> <p>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.</p> <p>Then I wanted those apps to feel native.</p> <p>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.</p> <p>Shipping was.</p> <p>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.</p> <p>That realization completely changed the direction of the project.</p> <h2> Peko today </h2> <p>Today I don't really think of Peko as "a desktop framework."</p> <p>The runtime is still there, and it works similarly to other native WebView solutions, but that's almost the bonus now.</p> <p>The real product is the developer pipeline.</p> <p>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.</p> <p>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.</p> <h2> What building an app normally feels like </h2> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>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 </code></pre> </div> <h2> What I want it to feel like </h2> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>Finish app ↓ Write demo script ↓ peko deploy ↓ Receive: ✓ Signed bundles ✓ Store screenshots ✓ Store recordings ✓ AI drafted descriptions ✓ Legal document links ✓ Release package ↓ Submit </code></pre> </div> <h2> The development pipeline </h2> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>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 </code></pre> </div> <p>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.</p> <h2> Who I built it for </h2> <p>People with ideas.</p> <p>Hobbyists.</p> <p>Solo founders.</p> <p>Small teams.</p> <p>Developers using AI.</p> <p>People who want the longest part of making software to be building the software itself.</p> <h2> Still growing </h2> <p>Peko is still a young public ecosystem, even though many of its systems have been evolving internally for the past five to six years.</p> <p>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.</p> <p>The goal hasn't changed.</p> <p>Keep shrinking everything between "my app works" and "my users can install it."</p> <p>If you're interested, I'd genuinely love feedback.</p> <p>Email: <a href="mailto:preston@pekoui.com">preston@pekoui.com</a></p> <p>Contact form: <a href="https://pekoui.com/contact" rel="noopener noreferrer">https://pekoui.com/contact</a></p> <h2> Where Peko Stands Today </h2> <p>One thing I want to make clear is that Peko isn't just an idea or a roadmap.</p> <p>You can use Peko today.</p> <p>Today the ecosystem includes:</p> <ul> <li>The MIT open source Peko Studio</li> <li>The MIT open source CLI (<code>peko-tools</code>)</li> <li>The MIT open source standard library</li> <li>The MIT open source UI library</li> <li>The hosted Peko Platform</li> <li>Cross-platform native bundling</li> <li>Remote macOS and iOS builds</li> <li>Signing</li> <li>Package management</li> <li>Deterministic app demos</li> <li>Automated App Store screenshots and recordings</li> <li>AI-assisted store descriptions</li> <li>Hosted legal document links</li> <li>Unified release packaging</li> </ul> <p>Right now, deploying with Peko ends with a single ZIP file containing everything you need to publish:</p> <ul> <li>Signed application bundles</li> <li>Generated screenshots</li> <li>Generated screen recordings</li> <li>AI-drafted store descriptions</li> <li>Store metadata</li> <li>Links to hosted legal documents</li> </ul> <p>From there, the remaining work is mostly creating your listing in each store, uploading the bundle, and completing the review process.</p> <p>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.</p> <p>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.</p> <p>If this sounds like the kind of tooling you've wanted, I'd love for you to give Peko a try.</p> <p>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.</p> <p>You can get started at <strong><a href="https://pekoui.com" rel="noopener noreferrer">https://pekoui.com</a></strong>, email me directly at <strong><a href="mailto:preston@pekoui.com">preston@pekoui.com</a></strong>, or use the contact form on the website.</p> programming automation