DEV Community: Jamie Folsom

Why I Shipped a Linux Desktop App as an AppImage (and Skipped Snap/Flatpak)

Jamie Folsom — Sat, 21 Mar 2026 08:40:12 +0000

Linux packaging is where good desktop apps go to die.
If you’ve shipped a Linux desktop application, you already know the pain: you can build something solid, fast, and stable… and then lose days (or weeks) fighting packaging quirks across distros, runtimes, sandboxes, portals, GLIBC mismatches, and “works on my machine” dependency landmines.
I’m building OpenChat for Linux, a lightweight ChatGPT desktop client built with Tauri (Rust). Early on, I decided to focus on one distribution format that would actually let Linux users install it easily without creating a maintenance nightmare for me: AppImage.
This post is the reasoning behind that decision, what went wrong with other formats, and what I learned.
The goal: one build that works across distros
When you’re distributing a desktop app to Linux users, you’re really targeting:
different distros (Ubuntu, Fedora, Arch, etc.)
different package managers
different libc/runtime realities
different desktop environments and portal behaviors
different expectations about sandboxing and filesystem access
For a small team (or one person), the biggest risk is not that you can’t build packages—it’s that you spend more time keeping packages alive than improving the app.
So the goal became:
Make installation stupid-simple across distros and minimize maintenance.
Why AppImage “just works” (most of the time)
AppImage has a few properties that make it extremely pragmatic:
No distro-specific repo required
Runs on most distros with minimal friction
One artifact to ship (great for fast iteration)
Users can download, mark executable, and run
Updates are straightforward: ship a new file (and optionally use AppImageUpdate later)
In practice, AppImage is the least “ecosystem heavy” option. It doesn’t ask you to become an expert in every distro’s packaging norms.
For my use case—getting a stable Linux desktop client into people’s hands quickly—this mattered more than ideological purity.
Why Snap became a time sink for me
Snap isn’t “bad,” but it can become expensive in time.
The big issues I ran into were runtime and sandbox friction—things like:
portal behaviors
sandboxing assumptions that don’t match how your app needs to access resources
dependency/runtime differences that are hard to predict
the “it launches, but key features fail” class of bugs
Even when you get it packaged, you can burn hours chasing down problems that don’t exist in your core app at all—they only exist in the packaging environment.
At some point you have to ask:
Is this helping users, or just dragging development velocity down?
For me, Snap was pulling too much time away from improving the product.
Why Flatpak failed for a more “boring” reason: GLIBC mismatch
Flatpak has a lot going for it: consistent runtimes, sandboxing, and a strong ecosystem.
But the reality is: if your build target and runtime don’t line up perfectly, you can hit hard failures.
In my case, I hit a GLIBC mismatch issue (e.g., runtime missing a required GLIBC version). That’s the kind of problem that isn’t solved by “try harder”—it’s solved by rebuilding under the correct runtime constraints and aligning everything.
If you’re a larger project with time to invest, that’s totally doable.
But if your priority is shipping and reducing maintenance, it’s easy for Flatpak to turn into an engineering project on its own.
So I paused Flatpak and kept the focus where it had the best ROI.
A practical distribution strategy that actually scales
Here’s the strategy I landed on:
AppImage as the primary distribution
Provide .deb / tarball for users who prefer them
Only invest in Snap/Flatpak again when:
there’s clear demand
the ecosystem value outweighs the maintenance
the build pipeline is ready to support it sustainably
That’s not anti-Snap or anti-Flatpak. It’s pro-shipping.
Bonus: performance matters as much as packaging
Packaging isn’t the only Linux pain point.
A lot of chat clients (and some desktop wrappers) can bog down during long sessions. OpenChat uses a technique I call message windowing:
keep an active slice of the chat rendered
load older messages only as you scroll
avoid long-thread memory growth and UI slowdown
It’s a simple idea that makes a big difference: long conversations stay responsive instead of turning into a laggy mess.
What I’m hoping to learn from the Linux community
If you’ve shipped desktop apps on Linux, I’d genuinely like feedback on:
whether AppImage is still the “lowest friction” path for most users
where Snap/Flatpak provide real value today (not just in theory)
what install experience you personally prefer
what breaks most often for you across distros
Shipping on Linux is worth it—but the packaging ecosystem can punish you if you try to do everything at once.
Link (if you want to check it out)
OpenChat for Linux:
https://snippetsupply.com/product/openchat-for-linux-openai-chat-by-snippetsupply-com-2?utm_source=lemmy&utm_medium=community&utm_campaign=openchat_launch&utm_content=appimage_article

Building a Hotjar-Class Analytics Platform in PHP: Heatmaps, Replays, Funnels, and Feedback

Jamie Folsom — Thu, 05 Mar 2026 09:19:35 +0000

Most analytics tools answer what happened.

Behavior analytics answers why:

Where users clicked

How far they scrolled

Where they got stuck in forms

Where they dropped off in funnels

What they said (surveys/feedback) alongside what they did

I built Spyglass360, a Hotjar-style behavior analytics + CRO platform, using a stack a lot of people overlook:

PHP

MySQL

Vanilla JavaScript

Bootstrap

Square for subscriptions

This post is the engineering breakdown: the event model, storage strategy, and the “gotchas” you hit when you ship a real tracker.

The install contract: one snippet, stable URL

If install takes more than one snippet, you’ve already lost half your users.

Your tracker needs a stable public endpoint (don’t leak internal file paths):

(function(){
var s = document.createElement("script");
s.src = "https://spyglass360.com/track.js?api=YOUR_API_KEY";
s.async = true;
document.head.appendChild(s);
})();

What is this?

Rule: /track.js should remain stable even if you refactor your internal /assets/... paths later.

Event design: collect the minimum data that enables the most features

A lot of tracking systems fail because they capture too much (privacy risk, storage cost), or too little (can’t compute anything useful).

A workable base event model:

pageview (url, referrer, viewport)

click (normalized x/y + element hint)

scroll (depth percent)

form_focus, form_blur, form_submit (never raw values)

custom_event (for funnels/goals)

Example payload:

{
"apiKey": "…",
"siteId": 123,
"visitorId": "v_abc",
"sessionId": "s_xyz",
"type": "click",
"url": "https://example.com/pricing",
"ts": 1710000000000,
"viewport": { "w": 1440, "h": 900 },
"event": { "x": 0.62, "y": 0.41, "selector": "button#start" }
}

Normalization matters: store coordinates as percentages so heatmaps work across screen sizes.

Storage strategy: raw events + aggregates

PHP can handle ingestion just fine. The real problem is query shape.

The common pattern:

Write all events to an append-only raw store

Maintain aggregate tables for dashboard queries

Raw table (append-only)

fast inserts

flexible schema via JSON payload

used for replay + deep analysis

Aggregate tables (fast reads)

daily/site stats

funnels summary

form dropoff stats

heatmap bins per page

This lets you keep MySQL without instantly needing ClickHouse/BigQuery.

Heatmaps: bins + rendering

Heatmaps are basically “count points and draw a gradient”.

Implementation approach:

Normalize x,y

Convert to bins (e.g., 100×100 grid)

Increment bin counters

Render bins as an overlay in the dashboard

Why bins:

you avoid storing every pixel as its own row

you can pre-aggregate quickly

rendering becomes predictable

Session replay: not video, a timeline

Replay looks like video, but it’s really:

an initial snapshot

a stream of events

a player that reconstructs the session

An MVP replay can start with:

click trail + scroll positions + page navigation timeline

Then evolve into:

DOM snapshots

mutations

masking rules

Big rule:

Mask and sanitize by default. Replay must never leak passwords, credit cards, or sensitive fields.

Funnels: pay attention to correlation, not just counts

Funnels work when you can answer:

“Did this same session reach step 1 → 2 → 3?”

“How long between steps?”

“Where is the dropoff?”

Implementation:

define funnel steps by URL patterns and/or event names

compute step completion per session

aggregate dropoffs

Funnels are one of the highest paid-value features because they directly tie to revenue.

Form analytics: capture friction without capturing values

Form tools get creepy fast. Don’t collect raw input.

Instead track:

field focus/blur

time-in-field

submit attempt

validation errors (optional)

Output:

“field X is where 60% abandon”

“average time spent here is 12s”

“users rage-click submit then bounce”

Feedback widgets + surveys: the “why” layer

Behavior tells you what. Feedback tells you why.

What matters is targeting:

show surveys based on pages, events, or user segments

connect responses to session context (without exposing identity)

Once you can connect:

“users rage click here”
with

“the pricing is confusing”
you get actionable insight.

Experiments (A/B testing): integrated beats bolted-on

Once you have:

visitors/sessions

conversion goals (events)

segmentation

…experiments become much easier:

assign variant consistently per visitor

measure goal completion

break results down by segment

The win isn’t “A/B testing exists”, it’s:

“Testing is integrated with behavior + funnels + feedback.”

Billing gotchas: Square subscription plan variation IDs

If you use Square subscriptions, here’s the sharp edge:

Subscription enrollment requires the SUBSCRIPTION_PLAN_VARIATION ID, not the plan ID.

If you pass the wrong one, you’ll see errors like:

Object does not have type SUBSCRIPTION_PLAN_VARIATION

Fix:

create the plan AND variation in your admin tooling

store both IDs

always enroll by variation ID

Launch gotcha: never grant access before payment success

The classic SaaS bug:

user picks paid plan

you create account and log them in immediately

payment never completes

they still get access

Fix with a proper state machine:

pending_payment

active

failed/canceled

Gate the dashboard/API based on active.

What I’d recommend if you build something like this

Start with funnels + form analytics (they sell)

Heatmaps are easy value

Replay is hardest (build in layers)

Lock down privacy early

Keep /track.js stable forever

Add “install verification” UX so users know it’s working

Wrapping up

Building behavior analytics is less about “writing a tracker” and more about:

event design

storage strategy

privacy discipline

and turning data into actionable UX

If you’re building something similar, I’d love to hear:

what feature is hardest for you?

what you wish Hotjar-style tools did better?

(If you want to try Spyglass360, it’s at spyglass360.com.)