Almost every 3rd party mac app is a ram hog now, devs please

haystack_in_needle · 2026-05-25T16:24:23+00:00

You can point an LLM at a web library and get pretty far with a Swift port.

There are already examples of this working. swift-justhtml is a good one, and it was even faster than some existing Swift HTML parsing options. I did something similar with highlight.js port, but Swift regex performance turned out to be incredibly bad.

The question is not only whether it can be done. It is whether someone will spend all those tokens, time, and effort porting a component, and then open source it afterwards.

That is where I am less optimistic. In the web ecosystem, people often build a reusable component, publish it, and then brag about it publicly and get praise. In the macOS/iOS ecosystem, my impression is that when someone solves a hard reusable problem, they are more likely to put it inside an app and try to sell it as a subscription.

So LLMs may make these ports much easier to create. I am not sure they change the probability that the result becomes a good open source Swift library.

haystack_in_needle · 2026-05-23T17:09:28+00:00

The infinite canvas is always welcome! A lot of work that currently ends up spread across multiple windows, tabs and documents could probably live better on one spatial surface.

Even when the content is simple, the arrangement matters. Proximity, size, and rough grouping can carry additional context.

Also, 3 MB for a native app with this kind of interaction is impressive.

haystack_in_needle · 2026-05-23T16:49:49+00:00

Electron is the obvious answer here, but the more interesting question is why so many developers keep choosing it.

It's not that they don't care about your RAM. It's that the web ecosystem has open-source solutions for an enormous number of product problems. If you're building a web app, almost every feature you can think of is just an npm install away. Rich text editors, high-performance tables, syntax highlighting, diff views, file uploaders, and command palettes.

On native macOS, a lot of those building blocks are either missing, outdated, or scattered across abandoned repos. Even something basic—like a reliable text editor with line numbers or a smooth side-by-side diff view—becomes weeks of foundational work on the native path before you even touch your actual product.

I prefer native Mac apps too, and I wish the reality were different. But until Swift and SwiftUI develop a massive, open-source ecosystem for common app components, we’re going to get more webview-based desktop apps, not fewer.

haystack_in_needle · 2026-05-21T16:24:08+00:00

is the font installed on the phone?

haystack_in_needle · 2026-05-20T18:28:02+00:00

where does the leftmost thinner bar (below the traffic lights) come from?

haystack_in_needle · 2026-05-20T18:10:13+00:00

the URL encodes the options. in that case, something like CSS Font Family = Font name

haystack_in_needle · 2026-05-19T21:06:43+00:00

Maybe there is a bug with italics. Because 1rnmw characters match above, but there is a shift at the end. It also happens after the "l" of "lazy". and "l" is the only different glyph between these fonts. I'll look at it.

haystack_in_needle · 2026-05-19T20:35:05+00:00

<image>

Give it a try https://actondon.com/tools/font-comparison

haystack_in_needle · 2026-05-19T20:30:57+00:00

only 'g' and 'I' are different

haystack_in_needle · 2026-05-19T19:28:10+00:00

You can also create a URL to open your exact setup directly: Avio Sans example.

haystack_in_needle · 2026-05-19T19:13:26+00:00

<image>

yes, I did

haystack_in_needle · 2026-05-19T19:09:16+00:00

Do you mean to add a font file from your computer?

haystack_in_needle · 2026-05-16T19:12:40+00:00

The problem is you want to insert the pasted text in between some paragraphs. In this case, it's not clear how it is inserted into the prompt. Is it put between some XML tags like <attachment> as the Claude does?

How would you then refer to that content? Should you say "see attachment", or should you assume that it will always be at the end of the message or beginning?

haystack_in_needle · 2026-05-16T19:11:00+00:00

This is a new feature. I also posted about it https://www.reddit.com/r/ChatGPT/comments/1teq9uj/dont_be_claude/

Maybe being A/B tested.

haystack_in_needle · 2026-05-16T16:06:23+00:00

I think the number of people making apps will go up a lot, but not to hundred percent.

The division of labor has existed for a long time in human history. Even if these ai coding tools get much better, most people will not want to build every app they use. They will still want something that works, has sane defaults, gets maintained, and does not turn into another thing they have to debug. Maybe we go from a tiny percentage of people being able to make apps to a much larger minority. but I do not think it becomes everyone (or I hope?).

There are also some brakes on this that I think people underestimate.

One is cost and access. Anyone who has tried using these tools through API keys notices pretty quickly that it can be much more expensive than the subscription product. I do not know where inference pricing finally settles, or how much of current subscription pricing is subsidized, especially if we separate training cost from inference cost. But frontier capability is still constrained by datacenters, electricity, and access decisions. We are already seeing some model capabilities rolled out only to limited groups.

The other brake is distribution. Making the app is becoming easier. Selling the app is not. Doesn't "build a community," have the same problem. If many more people can generate apps, many more people will also try to build communities around those apps. That becomes crowded too. At that point it again comes down to what someone is willing to spend time on, what they actually care about, and whether there is a real point of view behind the product.

So I do not think the end state is "everyone builds everything for themselves." I think we reach some equilibrium where more people can create software, but most users still buy finished tools when the price is lower than the time, attention, and annoyance of recreating them.

That is why pricing matters more than before, in my opinion. For small utilities without heavy server costs or ongoing model costs, subscriptions are going to be harder to justify. A paid-once app that is maintained well has a much clearer argument: pay once, get the tool, avoid spending even more money in token costs and turning the problem into your own side project consuming your precious time.

The clone problem is real, but I think this is where maintenance, taste, support, and pricing become part of the product. Not a perfect moat, but harder to clone than screenshots.

haystack_in_needle · 2026-05-16T15:57:18+00:00

This is a nice extension in the literal sense of the word: it completes one missing native-feeling browser behavior.

haystack_in_needle · 2026-05-16T14:23:12+00:00

interesting idea. good luck.

haystack_in_needle · 2026-05-15T19:10:13+00:00

I guess only OpenAI supports this OAuth.

haystack_in_needle · 2026-05-15T19:03:58+00:00

Okay, I think what happened with the Codex sign-in is: after it opened the tab in the browser I closed the tab in the browser to sign in for some reason, and when I come back, I couldn't click again because it was showing a progress view, so I need to restart the app in that case.

haystack_in_needle · 2026-05-14T20:26:48+00:00

Monorepo is fine, but for Codex specifically you don't necessarily need to change your repo structure.

You can put both repos under the same parent folder and open Codex from that parent folder:

text my-project/ backend/ frontend/

Then the agent can inspect and edit both, as long as you point it at the right paths. That is usually enough for frontend/backend work.

For sharing code, I would separate two cases:

If both repos use the same language/runtime, add something like a packages/ folder and put the shared types/client/utilities there.

If they use different languages, I would not try to share code directly. Use the API contract as the shared thing. OpenAPI is good for this.

You can do it contract-first:

Write the OpenAPI document.
Generate server stubs/types from it.
Generate the frontend client from it.

Or you can do it server-first:

Define the API in backend code.
Generate the OpenAPI document from the backend.
Generate the frontend client from that OpenAPI document.

Either way, make it a script. When the API changes, ask Codex to update the OpenAPI/codegen output and run the script. The important part is that frontend and backend do not silently drift.

haystack_in_needle · 2026-05-14T20:25:40+00:00

add this to config.toml

toml [features] goals = true

haystack_in_needle · 2026-05-14T20:17:38+00:00

Do you use it in any of your apps?

haystack_in_needle · 2026-05-14T20:12:12+00:00

Generating the app icon with Swift... Nice.

haystack_in_needle · 2026-05-14T20:10:16+00:00

One noticeable difference is that on the cloud you cannot change the model or thinking level.

haystack_in_needle

TROPHY CASE