Kyvenza: run macOS and Linux VMs on Apple Silicon without touching a config file. $49 one-time.

Kyvenza: run macOS and Linux VMs on Apple Silicon without touching a config file. $49 one-time.

I made this, so weigh everything below accordingly.

Problem:

I needed a clean macOS install to reproduce a bug that only showed up on a fresh system. Ninety minutes later I had four tabs open about disk image formats and still no VM. That's the whole origin story. VM tooling on Apple Silicon splits into CLI tools that assume you enjoy configuring things, and commercial suites that want to be a platform. I wanted the boring middle, something that treats a VM the way Finder treats a folder.

Kyvenza is a native Swift app on Apple's Virtualization framework. No QEMU, no emulation layer, no CLI it's quietly shelling out to, zero third-party dependencies. You fill in a form and get a VM. macOS guests and Linux ARM, with Ubuntu, Debian, Fedora and Alpine pulled straight from the official download pages for you, or point it at any other ARM64 ISO yourself. Clone, snapshot, import and export. Pause a running VM and pick it up later, or force power off when a guest stops answering. Rosetta shared into Linux guests so x86-64 binaries still run. Shared folders. A diagnostics panel for when virtualization does what virtualization does.

Comparison:

The honest way to sort this is by what you actually want to run.

If you want Windows, VMware Fusion is free now for personal and commercial use, and it runs Windows 11 ARM. That beats me, and it beats Parallels on price. I can't run Windows at all: Apple's Virtualization framework can't boot Windows on ARM. That's a framework limit rather than a hardware one, and it's not a roadmap item I'm being coy about. Go get Fusion.

If you want a macOS guest, Fusion is out entirely. Broadcom's own docs say the Arm variants of macOS aren't supported in a Fusion VM. So on Apple Silicon the field is Parallels, UTM, the CLI tools, and me. That's the case I built this for, and it's where one-click snapshot and clone earns its money, because testing against a clean system means rolling back constantly.

Parallels is more mature than I am and does both Windows and macOS guests. It sells a perpetual Standard licence alongside the subscriptions, but that one is current-version-only, same shape as mine and more expensive. Pro is subscription.

UTM is free, more flexible, and does x86 emulation through QEMU, which I don't do at all. If you already have a UTM setup you like, stay. I'm not going to beat free on flexibility. What's different here is that snapshot and clone are one click instead of a disk image chore, and sharing Rosetta into a Linux guest is a toggle instead of a mount you look up every time.

Tart, lume and the other CLI tools beat me if you're scripting CI. This is for when you want a window, not a pipeline. And if Docker already solves your problem, keep using Docker, this isn't a container replacement.

Two limits worth knowing before you download rather than after. Apple Silicon only, macOS 14 or later, no Intel Macs. And Apple's own license caps you at two macOS guests per host, which no app on this list can change.

Pricing:

$49 one time, not a subscription. Twelve months of updates, then a perpetual fallback license, so when the update window closes the app keeps working. 7-day trial, no card, because virtualization performance depends far too much on your specific hardware for me to ask anyone to take it on faith.

Link: https://kyvenza.com

Also on the Mac App Store. The direct download is a signed and notarized DMG.

One bit of history since someone always finds it: versions before 1.1 bundled lume (MIT, by the trycua folks). Since 1.2 it runs on its own engine, but the credit is still in the app's Open Source Notices, because that project is what got this off the ground.

I'll be in the comments, including for the "why would I pay for this" ones.

u/ScholarBackground836 — 22 hours ago
▲ 13 r/AppleWatchStandalone+2 crossposts

Wilds Survivor: a wilderness survival sim that runs entirely on the Watch, no iPhone needed [Freemium]

The watchOS app is the whole game, not a companion view. It runs the same engine as the phone version, doesn't need your iPhone nearby or even powered on, and works in airplane mode.

What it is: you're stranded, and every hour you spend is an hour you don't get back. Gathering firewood costs 42 minutes and 60 calories and will probably work. Scouting the high ground costs 90 minutes, might turn up a map fragment, might turn up nothing. Those numbers are on screen before you commit. Nothing is hidden from you except luck.

Six stats pull against each other: condition, hydration, body heat, stamina, calories, rest. The fire that keeps you warm burns the daylight you needed to find water.

Why it works on a watch specifically: it's turn-based and nothing is running down in real time. Raise your wrist, read one decision, spend the time, put your arm down. A run spans several in-game days but each interaction is a few seconds. It saves wherever you stopped.

Eight scenarios (a canyon that floods a bit more each day, a dry wash at 42°C, a crash site above the treeline at -12°C, a mine 4,000 m up), five difficulty tiers, and an 8 kg gear budget you allocate before you start. A fur wrap is the warmest thing you can carry and it weighs almost two kilos. That one trade-off is the whole game.

Pricing, since the rules ask: freemium. Two scenarios are free and can be played to the end. A single purchase unlocks the other six permanently. No ads, no subscription, no energy timers, no account. The app never makes a network request.

Happy to hand out promo codes for the full unlock if anyone wants to try it, just say so.

It's my first watchOS game. What I'd most like to hear is where it falls apart on the smaller 40/41 mm watches, and whether the tutorial loses you.

https://apps.apple.com/app/id6794646703

u/ScholarBackground836 — 10 days ago

Five ways ruck calorie numbers go wrong — including one that quietly inflates your Apple Activity ring by ~86 kcal/hour

Disclosure first, and I want to be precise about my angle: I build a rucking app, which makes me the person who implements the arithmetic — not a competitive rucker. So this post is about the equations and nothing else; I'm not going to tell you how to train. I'm also deliberately not naming or linking the app, because you can use every one of these traps to audit whatever you're currently trusting, including mine. I hit all five myself, and two of them shipped to real users before I caught them.

1. Generic walking MET models don't survive load.

The easy implementation picks an ACSM walking MET by speed band and scales it linearly by load ratio. That's what I shipped first, and it's wrong in a specific way: the metabolic cost of carrying load isn't a fixed multiplier independent of speed. Carrying 20 kg at 1.0 m/s and at 1.9 m/s do not cost the same proportional premium. The military load-carriage literature exists precisely because generic walking equations don't extend to loaded walking.

2. Gross vs net — this is the one that inflates your Apple Activity ring.

Every published load-carriage equation returns gross metabolic cost: total energy including the resting metabolism you'd have burned sitting on the couch for the same duration.

Apple Health's activeEnergyBurned is defined as net — activity only.

If an app writes its gross number straight into HealthKit, your Activity ring is overstated by your entire resting metabolism for the whole ruck:

net = gross − (1.25 W/kg × body_mass × duration)

For an 80 kg person that's about 86 kcal per hour of rucking, credited to a ring you didn't earn. Ruck an hour a day and that's ~2,600 phantom kcal a month sitting in your Health database — and every other app reading that data inherits the error.

My app did exactly this until the release I put out this week. I'm not confident it's the only one.

3. Pandolf under-predicts heavy loads by a known margin.

Pandolf et al. 1977 is the most-studied equation in this domain and it's genuinely good, but it's documented to under-predict contemporary heavy military load carriage by 12–33%. If an app's accuracy pitch is "we use Pandolf," that's the known ceiling, not a guarantee. LCDA (Looney, Potter et al., Med Sci Sports Exerc 2022;54(4):646-654) was regressed on newer load-carriage datasets and holds up better under heavy loads. It's what I default to now.

4. Terrain coefficients are not portable between formulas.

Both Pandolf and LCDA take a terrain factor η. The values everyone quotes — dirt road 1.1, light brush 1.2, soft sand 2.1 — were calibrated by Soule & Goldman for Pandolf specifically. LCDA publishes its own set, numerically different. Applying Pandolf's η to LCDA is a category error worth up to 1.8× on soft surfaces.

I don't ship a terrain picker at all because of this. Worse UX, honest math. If an app offers you both "LCDA" and a terrain selector, it's worth asking which coefficients it's using.

5. Phone GPS invents grade, and grade multiplies.

Grade matters a lot and looks free to obtain — except phone GPS altitude without a barometer will accumulate 50–150 m of phantom elevation gain on a genuinely flat 8 km route. That becomes a 0.6–1.9% average grade, which inflates the estimate by 5–15%.

Related trap: if you only store total positive elevation gain — one scalar, no time series — you cannot distinguish an out-and-back from a point-to-point climb. Averaging grade over the full distance over-estimates out-and-backs by about 12% at worst. The tempting fix is "assume half up, half down" — don't. Pandolf's grade term is linear in G, so a symmetric assumption cancels it to exactly zero and silently disables grade altogether.


How to audit whatever you're using, in about ten minutes:

  1. Log a ruck. Note the calorie number the app displays.
  2. Open Health → Active Energy and find what that workout actually wrote.
  3. If the two numbers are identical, the app is very likely writing gross into a net field. That's trap 2.
  4. Check whether it ever asked for your body weight. Every one of these models scales with body mass — an app that doesn't know your weight isn't estimating, it's guessing.
  5. If it reports elevation gain far above what the route deserves, trap 5 is feeding your calorie number.

Happy to go deeper on any of the equations — including where mine is still weak — if that's useful to anyone.

reddit.com
u/ScholarBackground836 — 23 days ago

Feedback wanted: Daily Guess Arena — a server-authoritative daily Reddit quiz

Hi! I built Daily Guess Arena for Reddit’s Games with a Hook Hackathon, and I’d love feedback from people who play games on Reddit.

Every subreddit gets the same deterministic five-question challenge each UTC day. Players earn points for accuracy and speed, get one official score per day, and can then practice without affecting the leaderboard. The game also includes answer explanations, daily streaks, rankings, and native sharing.

Play today’s challenge here:

https://www.reddit.com/r/DailyGuessArena/comments/1uscff2/daily_guess_arena_20260710_challenge/

I’m especially looking for feedback on:

  1. Does the start screen explain the game clearly enough?

  2. How does the pacing and question input feel on desktop or mobile?

  3. Would the streak and daily leaderboard give you a reason to return?

  4. Is anything confusing after submitting your answers?

Please avoid posting today’s answers or screenshots that reveal them.

Technical note: it is built with Devvit Web, React, Phaser, Hono, and Redis. Scoring is server-authoritative, correct answers are not sent before submission, and only the first official daily result updates the leaderboard.

reddit.com
u/ScholarBackground836 — 1 month ago