DEV Community: Feng Chen

Command Reopen: Make Cmd+Tab Bring Back Closed and Minimized Windows on Mac

Feng Chen — Sun, 18 Oct 2026 00:00:00 +0000

Background

A Mac is expensive to switch to, but once you’re used to it, you can’t leave. After graduating in 2020 I used a Mac for the first time. I had to study a Mac “white paper” guide, watch YouTube courses, and have people ahead of me walk me through three-finger drag and four-finger swipe between desktops before I got the hang of it.

macOS has its own design logic; sometimes you can’t tell if it’s careful or just stubborn. If you’re coming over with muscle memory from other operating systems, a few things are bound to trip you up.

Take what happens when you close an app’s window with Cmd+W or minimize it with Cmd+M:

The app doesn’t quit; it still shows up in the Cmd+Tab app switcher.
But because the window was closed or minimized, switching back to that app with Cmd+Tab won’t bring it up.

I went looking for ways to deal with this, and found roughly three answers:

Hide apps with Cmd+H instead of closing or minimizing them. Hidden apps do reopen windows via Cmd+Tab (which completely goes against my habits).
Select the app in Cmd+Tab, hold Option, then release Cmd, and the window appears (I’ve literally never managed to pull this key combo off).
Activate it from the Dock (…)

Eventually I’d had enough and vibe-coded an app to fix it.

How Command Reopen Works

During the days this was driving me crazy, I took a closer look at how Cmd+Tab actually behaves: when you switch to an app with no open windows, macOS actually brings it to the foreground—it just doesn’t open a window.

So the approach behind Command Reopen is pretty straightforward: listen for system foreground app switches, and as soon as an app arrives in the foreground without any visible window, send a “reopen” command to wake it up.

Existing solutions (notably AltTab) often do complex window management — previews, rearranging, even redrawing and covering the native Cmd+Tab UI — and usually need Accessibility permission or even Screen Recording permission.

Command Reopen only fixes this one thing. It doesn’t change system UI or run complex logic — it just adds a window-activation step. For daily use, that’s enough.

Limitations of Going Zero-Permission

Because it refuses sensitive system permissions, the current approach has two hard limits:

1. Lack of Window-Level Control

Window-level control needs Accessibility (AX) permission, so Command Reopen can only wake apps, not individual windows. If an app has multiple minimized windows, it will only bring up the topmost one—you can’t pick a specific window to activate.

2. Reliant on Apps Following Native macOS Window Standards

The mechanism needs the target app to implement macOS window APIs properly so it can answer system activation. If an app’s window management is a non-standard, hand-rolled setup, it may not work.

In testing, a user found that Feishu Meetings (launched from Feishu / Lark) takes its own Dock icon and completely ignores Command Reopen’s activation. There may be other non-standard apps we haven’t found yet.

Still, after half a year of daily use, most mainstream apps are mostly fine.

Pricing & What’s Next

App Store
Website
Yearly $5.99, Lifetime $9.99
GitHub (open source)

The GitHub Releases page offers slightly older direct-distribution builds you can download for free. Alternatively, you can clone the repo and build it yourself. There’s also an experimental build with Accessibility permission that addresses the limitations mentioned above.

After shipping Command Reopen, I wondered whether to make a tiny app for every similar papercut — macOS has so many small things you could polish. I knocked out two more and stopped. You won’t install a hundred apps; bundled tools that fix many papercuts fit this better — like Raycast and Supercharge.

Solve Your Own Problems First (and Only Your Own)

Feng Chen — Mon, 22 Dec 2025 00:00:00 +0000

More than a year into vibe coding, I still haven’t quite figured out how to relate to this new kind of productivity. Whenever the hype flared up, I’d jump in with great excitement and hack away for a bit. But pretty quickly, the lack of practical utility and any real sense of accomplishment would deflate me. It’s been an endless cycle of fizzling out and starting over.

Recently, while building a few small tools to fix UX annoyances in my daily workflow, I realized this may well be the use case that makes the most sense for regular folks vibe coding: solve your own problems, and only your own. A few key traits make this approach work:

Low complexity: AI can knock it out in no time.
Small scope: but because you keep using and tweaking that one specific thing, it gradually gets smoother and better to use over time.
Productized: packaging it into an actual tool makes day-to-day use that much more convenient.

In the end, you only ship the ones you’re genuinely satisfied with. That sidesteps the hollow, aimless feeling of vibe coding and building products without a clear goal in sight.

As a longtime Raycast user, I’ve often wondered: where on earth do they find so many tiny needs to solve? I suspect they did the exact same thing: solve their own problems first, not the users’.

Once you adopt this mindset, you don’t decide whether to build something based on whether it’s already been done before, or whether anyone else will use it. If existing solutions aren’t elegant enough, then I guess I’ll have to build it myself; and because it’s solving my own problem, I couldn’t care less whether anyone else ever uses it.

Perhaps this is the vibe coding playbook that actually works best for regular people.

Another truth that hits home the more I code: someone without real engineering practice will find it very hard to vibe-code a solution that combines taste, solid engineering, and widespread appeal.

The barrier to entry has dropped, but the effort required is still substantial. It’s no place for a half-hearted coder.

Why I Struggle to Build My Own Products: From the Profit Trap Back to the Joy of Creation

Feng Chen — Sun, 27 Jul 2025 00:00:00 +0000

The Problem I Ran Into

I’m a product manager, and ever since I got into the industry, I’ve wanted to build products as an indie dev. Late last year, Cursor gave me just enough coding ability to actually build things. All those ideas that had been sitting in my backlog for ages started turning into reality, one by one. I was having a blast.

Then ambition crept in: making money. Looking through my “product manager” lens, most of my ideas weren’t monetizable. So I turned my gaze toward App Store charts, SEO keywords, and Xiaohongshu (a Chinese lifestyle and recommendation platform). That threw me straight into a vicious loop:

Most ideas felt boring or worthless.
Hunting for ideas by scraping charts and chasing keywords felt inelegant.
I’d scoff at other people’s terrible ideas, while secretly envying their good ones.
Lacking taste and judgment, I became paralyzed by implementation costs and the fear of failure, never daring to commit.

It was a terrible headspace. The harder I hunted for “user needs,” the more anxious I became—endlessly scrolling social feeds, dissecting user behavior, doing competitor analysis and tech stack research, but never getting past that stage.

From a product standpoint, this is a textbook case of struggling to find direction. But I had no fertile soil for genuine ideas to sprout in the first place, and at the same time, I looked down on the playbook of keyword research and leaderboard scraping. I was completely trapped in my own awkward contradiction.

Do I Really Have to Build Products?

When I finally asked myself this, I was surprised to realize I’d never once questioned it. The belief had become almost like a mental seal. On one hand, it carried my longing to escape the 9-to-5 grind and work for myself; on the other hand, building products is genuinely alluring—it scratches the creative itch while creating value for others. But once the demand for income took over, the original intent began to warp.

To put it another way: Is building products really my calling?

Among the ideas of “freedom” I subscribe to, discovering one’s calling is the path that makes the most sense to me. A calling, by definition, should be work that brings lasting joy, provides a decent income, and is worth dedicating a significant chunk of your time to. When the answer isn’t clear yet, the best thing I can do is make exploring possibilities the main focus:

Let curiosity lead the way.
Keep income off the table, and explore everything as an amateur.

Building products, then, definitely isn’t a necessity, nor is making money through them. It’s just one candidate for what a calling might look like.

How to Find New Ideas

The boundaries of product insight mostly depend on the boundaries of the creator. A 30-something adult can hardly empathize with how a 12-year-old thinks; and how can a longtime Apple user design better experiences for Android and Windows users, who make up the majority of the market?

Sure, there are proven methodologies for bridging those gaps. But once I broke free from the obsession with making money and started seeing creation as a journey toward finding my calling, exploring the possibilities within my own world became far more important.

Build Only for Myself

In terms of shipped projects, I’ve launched two:

Obsidian File Ignore: a browser extension built to hide unused files in an Obsidian vault and keep it from slowing down.
Raycast Penflow: an English writing assistant that polishes English phrasing and translates-plus-polishes mixed Chinese-English input.

The ironic part was that even though I was the original user with the problem, I soon stopped using both. The need for the Obsidian plugin disappeared once I changed how I organize files. As for Penflow, the actual use cases turned out to be far rarer than I’d anticipated. When you don’t use your own tool, there are no new itches to scratch, and you simply stop maintaining it.

That made me realize: if this is what happens when building for my own needs, trying to build for strangers is even worse. Choosing to build only things I personally use has significant advantages:

No need to worry about financial returns.
The pain point is relatively clear, and so is the shape of the solution.
It cuts out the mental friction and endless back-and-forth of second-guessing other people’s needs (like the 12-year-old empathy gap mentioned earlier).

Live My Own Life, and Let Ideas Surface Naturally

Instead of daydreaming a problem into existence, it’s better to live life well right now and explore new boundaries.

First, step back from immediate survival pressure and take care of myself. By tuning my sleep and exercise habits, carve out two to three hours a day for quiet thinking. And as long as I don’t hate my day job, I should view it through a positive lens—after all, it’s the domain I’m most deeply engaged in, and it takes up the largest part of my day.

Second, protect and nurture curiosity. I once told Gemini, feeling genuinely down: “I can’t find my curiosity anymore.” But soon enough, once I dropped the obsessions and mental noise, journaled more, and gave myself room to unwind, things improved dramatically. It had only been clouded over; it never actually vanished.

Finally, with curiosity as the foundation, just go play and make creative things. Not only do these projects bring joy and relieve stress, but they also continually test the reach and strength of how curiosity connects you with the world.

So, learn to live, and explore where interests, hobbies, and happiness come from. As Paul Graham wrote on his blog:

When in doubt, optimize for interestingness.

The goal of building products isn’t making money; money is just a byproduct. And good ideas don’t come from racking your brain—they’re the unexpected surprises you bump into while living an interesting life.

I Finally Understand What Static Sites Are

Feng Chen — Wed, 21 May 2025 00:00:00 +0000

Building openflomo with Client-Side Rendering

Back when I first started tinkering with AI coding, I wanted to build a public version of my notes from flomo (a note-taking app). With Claude driving the code, here’s how the workflow played out:

1. Downloading the raw notes: flomo exports in HTML

If all I cared about was making my notes public, simply hosting this export as a static page would have been more than enough. But I couldn’t leave well enough alone—I just had to go and rebuild it to match flomo’s actual web app.

2. Fussing over the details

The raw export was missing two key things: first, tags inside note cards couldn’t be highlighted or filtered; second, it lacked the tag list in the left sidebar.

After plenty of tinkering, here’s what it looked like. I was thrilled, and immediately threw it up on GitHub Pages.

3. The problem: painfully slow loading

I have over 2,000 notes. The raw HTML file was around 700 KB, and both the JS and CSS files clocked in at over 600 lines each. Whenever you opened the page, this is what actually happened:

The browser loaded index.html, which pulled in the raw data file and the JavaScript, while importing CSS as needed.
The JavaScript looped through the entire raw file on the fly—handling tag parsing, text formatting, the list view, URL formatting, and so on.
The CSS was applied, and rendering finally finished.

Since I don’t know how to code, I just obsessively took screenshots of the LCP (Largest Contentful Paint) performance scores, tossed them over to Claude, and told it to fix them. We tried plenty of tricks and saw some improvements, but my gut kept telling me something about this whole setup felt off.

Discovering Hacker News and Buzz

I had just started browsing Hacker News at the time, and I couldn’t understand why its interface looked so dated. After digging around a bit, I realized what its users actually care about:

Only the bare-minimum HTML and CSS, and virtually no JavaScript, so it still works even on terrible connections.
High information density.
Zero visual clutter from bloated CSS, making it easy to stay immersed in the content.

Then I came across Owen’s article on rebuilding Buzz (https://www.owenyoung.com/blog/new-buzzing). That was when it clicked: for what I was trying to do with openflomo, I should be server-side rendering and building a static site, then hosting those static files on GitHub Pages.

Client-Side vs. Server-Side Rendering

At its simplest, a web page can just be a single HTML file: CSS provides styling, and JavaScript adds logic. Without any JavaScript, it’s already a complete page on its own.

More often, though, there’s an intermediate step between your raw data and the final page structure. Take a blog: I write posts in Markdown, and a set of scripts has to convert that Markdown into HTML before it can actually become a web page.

That process is the “Build” step.

When hosting a site, there are three common moments when this build can happen:

Building locally, then deploying the compiled files.
Building on the server when deploying the source files—compiling once on the server, so visitors receive pre-compiled files directly.
The client fetches all the raw assets and compiles everything on the fly—which inevitably leads to slow load and render times.

Rebuilding with Astro

With Cursor doing the coding, I rebuilt the project using Astro. The new workflow looks like this:

Drop in the updated flomo notes.
Commit and push the code. The build script runs on the server—handling tags, lists, and styling to produce the final static assets.
When a visitor lands on the page, they pull down the pre-built static site directly.

Looking at these network requests in DevTools, for the first time I felt that same excitement my former engineer colleagues must feel when they write clean, elegant code.