isobox is a Go CLI that compiles one sandbox policy to each OS's native mechanism: Seatbelt on macOS, gVisor on Linux, and AppContainer on Windows. Instead of pretending every backend is equal, it uses an explicit capability model that flags where enforcement falls short, and a strict mode that refuses anything that isn't portable.

webframe is now a tool for scripting and testing pages, not just watching them. You can inject stubs, run test files after load, pass in secrets, set timeouts, and let the page set the exit status, and hidden pages run unthrottled on every platform.

The first release of webframe, which runs a web page like a program: it loads a URL in a hidden web view and wires its console to stdout, its exceptions to stderr, and stdin to a JavaScript REPL. It's a single ~5 MB binary that uses the webview your OS already has.

Wanix Elements are web components for declaring filesystems, tasks, VMs, terminals, and even VS Code in plain HTML, so you can build a sandboxed Unix-style environment in the browser with a few tags. This preview also adds the rc shell and a Wanix-ready Alpine Linux as CDN extras.

Our biggest Apptron release yet. Embeds can now be just a terminal in Console Mode, public sites work offline with an automatic service worker, and environments got 4x faster networking and up to 2x faster builds.

Apptron Demo: CSS Themed Windowsyoutube · loads when you press play

Being able to customize the frame of your window is not new. With Electron you can create a “frameless” window, giving you a blank frame to populate with your webview. However, now you have to make sure you have all the basic window controls users expect. It also ties that window frame to the rest of your UI web code. What this Apptron feature does is make the window frame a separate HTML context that you can define or set with a pre-existing theme.

As I mentioned, this is experimental. Right now it requires and uses an iframe in the theme HTML to show what you normally expect in your webview. We can replace this with a separate native webview positioned where the iframe would normally be. I’d love it if somebody wanted to help make this happen.

However, there are other ways you can contribute. I’d love to have more built-in themes for users to play with. They don’t have to be retro throwbacks, but more of those are welcome, too!

Sign up to join early access if you’re interested in using or contributing to the project. This is the last demo for now, but I’ll be back soon with not only more Apptron, but more exciting projects.

-jeff

Apptron Demo: HTML5 Background Appsyoutube · loads when you press play

In the last demo, we made an app indicator background utility as a shell script. This week we re-create it using JavaScript in an HTML file. With apptron build we can make it into a standalone executable. This workflow was originally intended for quick webview apps, but because we can let the JavaScript of the page run while the window is hidden, we effectively get a background application.

Apptron wasn’t made just for webview apps. I wanted to expose other native APIs that let you hook into more pre-built UI elements the operating system provides. For now this covers the common ones like app indicators, dialogs, and desktop notifications. In the future I’d like to expose APIs to let you add new items to system menus, control panels, and other places the OS lets developers hook into. These are important to make scriptable so you can easily leverage them for simple workflow hacks. When it’s easy to throw that kind of thing together, you don’t need to find “an app for that,” you can just imagine what would work for you and make it happen.

If this is also a world you want to see, join Apptron early access and help us get this thing out. See you next demo!

-jeff

Apptron Demo: Shell Scriptable Native APIsyoutube · loads when you press play

There is a whole class of power users that doesn’t always want to take the time to “write a program,” let alone learn how. Since the functionality is right there, why not expose it in a way that’s useful for these folks? Sysadmins and devops engineers often spend most of their time at a command prompt, so this feature goes out to all of them.

It turns out having a CLI interface to the APIs also makes it easy to do basic regression testing for the project. It also provides a kind of accessible listing of functionality. And! It helps with our polyglot primitive goal, working as a stopgap before having native library support for a language, since nearly all languages can “shell out”.

As I mentioned in the video, this is a strategy I like to use when making generative primitives: maximize utility by providing multiple ways to access features. Like being language agnostic, this helps meet users where they are, and reach users you might not otherwise. There’s also often a dominant context people think of for some functionality, so showing it in a new or surprising context helps break people out of existing thought patterns and imagine new possibilities.

Let’s see what possibilities open up with the next demo! In the meantime, join early access to explore Apptron on your own.

-jeff

Apptron Demo: Zero Config HTML5 Native Appsyoutube · loads when you press play

The way this works is actually similar to the last demo where we built a simple Go application to host our webview app, except Apptron is building it for us. Unlike all other commands of Apptron, this build command does have a dependency, which is the Go compiler. Luckily, this compiler is also a self-contained tool that’s easy to install on any platform.

At some point, I’d like to try embedding the Go compiler with Apptron, but this does introduce some complexity I don’t want to take on just yet. However, if anybody is interested in making this happen, please join early access so you can help us make Apptron great.

Speaking of help, this demo avoids talking about something that’s somewhat necessary on modern platforms: signing. If you’ve ever downloaded an executable on Windows, I’m sure you’ve gotten a giant alert asking if you really want to run it. This is because it’s an unsigned executable, which means it can’t be proven to not be tampered with by a non-author. Platforms are getting stricter and stricter about this.

On Mac, you have to not only sign but notarize your executable before another Mac will be allowed to run it. This is a tricky process that can be done on your own with an Apptron built executable, but I have preliminary tooling to help with the process. The same tooling can also bundle up your executable into a Mac app bundle.

However, I need help getting these last mile features in. So please consider joining early access, not only to try Apptron, but if you have the experience, to help us finish these core features before it debuts as a public open source project.

See you with the next demo!

-jeff

Apptron Demo: Webview Window Building Blockyoutube · loads when you press play

To expand on the demo, in this post I’ll discuss some of the motivation behind this project. There are a few reasons why I made Apptron.

I’ve always loved the option of using HTML5 in webviews to build cross-platform native app UIs. Native controls definitely have their benefit, but become tricky to do consistently across platforms. Rendering the UI the way a game would with a GPU accelerated render frame is consistent across platforms, but usually means you have to invent your GUI paradigm from the ground up. Using a webview gets you general consistency across platforms, while also getting a well known paradigm for building user interfaces. It also comes with the largest ecosystem of frameworks and pre-built components that can generally be used together, and is constantly improving as the web evolves. It’s not always the best approach, but it’s a nice option to have.

Using a webview for desktop UI is not new, but was not a well known practice until Electron. I’m pretty sure significant chunks of UI in Windows as far back as Windows 95 were actually webviews. Recently, I was surprised to discover some parts of macOS today are actually using webviews. But Electron popularized it by focusing on the cross-platform benefit and riding on the initial success of Node.js, empowering JavaScripters to do more than they ever could before.

Today, Node.js is considered by many, including its author, a bit of a mistake. This is a complex thing to explain, but for me it has a lot to do with the culture of dependencies and complexity in that ecosystem. So if you explicitly don’t want to use JavaScript, or maybe just avoid Node.js and NPM, you don’t have much choice when it comes to easily making webview based apps.

Luckily, we’ve been seeing alternative frameworks for a couple different languages recently. Unfortunately, any language-specific framework is limited to that language. This has always frustrated me as a polyglot programmer. Broad approaches to software design shouldn’t be silo’d off to specific languages, even though obviously you have to pick one for an implementation.

It’s also frustrating to see how complex these full service frameworks become. At their core, they’re just re-exposing platform APIs, but they end up being full-fledged platforms of their own. Keep in mind, it’s not just webviews and windows, there are a bunch of platform APIs for features across all major platforms that you might want to use. Native menus, dialogs, notifications, etc. If you wanted to use one of these in a script or simple program, Electron immediately feels like overkill.

Depending on your language, you may find one-off libraries for these cross-platform native features. A library for webviews, a library for desktop notifications, etc. The problem there is when you want to combine them. Not only are these libraries usually going to be fairly inconsistent in their design, if they even exist, but because of the nature of platform APIs, they often need to set up an event loop and take over the main thread. This makes them difficult if not impossible to use together.

With all this in mind, it seemed the only option was to build a language-agnostic bridge to cross-platform APIs. Apptron uniquely sits somewhere between a full framework like Electron or Tauri, and small one-off libraries you might find for specific APIs. It can be used like a library, a tool, or a micro-framework, but it’s small and self-contained. This is why I describe it as a software primitive or building block.

I hope Apptron is compelling, and I’d like to invite you to try it out in early access. In the meantime, more demos are on the way.

-jeff

Apptron is a software primitive that lets you drive native platform APIs using the technologies you’re already familiar with, enabling cross-platform webview apps and more.

Usable from any language, or even the command line, Apptron gives you webview windows and common platform APIs for your simple scripts, homebrew utilities, or full applications. Building cross-platform programs that leverage native functionality (menus, dialogs, notifications, global shortcuts, etc) has never been more accessible.

These APIs are packed into a single executable that can be used a number of different ways, making Apptron a simple but powerful software primitive.

Zero Config Native Apps from HTML

Turn an HTML file and any other web assets into a self-contained, cross-platform executable in a single command.

Language Agnostic Building Block

Use the Apptron APIs like a library from any language without C extensions or tricky event loops.

Shell Scriptable Native APIs

Use platform APIs from CLI commands to break shell scripting out of the terminal and into the desktop GUI.

These features and more will be showcased in a series of demos coming out over the next few weeks. Given all the different ways it can be used, Apptron is something you really have to see in action. Catch their premieres on Twitch, or subscribe on YouTube so you don’t miss them.

Early Access

In the meantime, we’re opening up Early Access via the Apptron website:

https://tractor.dev/apptron

By joining early access, you’ll be invited to the currently private GitHub repository where you can try Apptron out, submit issues, and help bring Apptron to a stable 1.0 release and become public open source software.

Help Wanted

I’ve been using Apptron in some form with the rest of the Tractor System for over a year now, but to make this a solid standalone primitive I’ll need your help. Please consider joining early access to play around with it and give feedback.

Anybody interested in contributing or helping drive this project should definitely request access and get involved. This is one of many projects I have in the pipeline and I can only do so much.

Thanks

A huge thanks to my sponsors, who I depend on to fund this early R&D work on the Tractor System. As long as it’s sustainable, I look forward to releasing more powerful open source primitives.

Excited to tell you more next week with the first Apptron demo!

-jeff