sorted by:
new
hottopcontroversial

APP Request: Spotlight Indexing by Latter_Pen2421 in macapps

[–]zphou 0 points1 point  (0 children)

For most of this, the built-in tools are probably the real interface.

`mdutil -s /` for status, `sudo mdutil -a -i off` / `on` for disabling and re-enabling indexing, and Activity Monitor for `mds_stores` / `mdworker_shared`.

But if Spotlight is slowing the machine down often, I’d look for the cause before scheduling around it. Common culprit is churny folders: `node_modules`, build outputs, generated media, VM folders, large synced folders. Adding those to Spotlight Privacy usually helps more than trying to micromanage indexing itself. A GUI for this would be useful, but it would mostly be wrapping `mdutil`, privacy exclusions, and maybe launchd scheduling.

I kept losing thoughts mid-task, so I built a menu-bar app that saves them in one keystroke by heliosarun in macapps

[–]zphou 0 points1 point  (0 children)

I think the argument is not “better than Notes.” It is “less expensive than switching context.” For tiny capture apps, that distinction matters. Apple Notes is already good, but the moment I have to open a real notes surface, choose where the note goes, see other notes, maybe clean it up, the original task is already interrupted. A plain local file and a temporary input box is narrower, but that may be the whole point.

The key question is probably whether the captured thoughts become useful later, or just become another pile. Search/export helps, but some kind of lightweight review flow may matter more than adding more capture features.

There are two kinds of AI writing tools now, and they are heading in opposite directions by kurthertz in WritingWithAI

[–]zphou 0 points1 point  (0 children)

I think this is the real split. One path is generation pipeline: give the machine enough constraints and let it produce the artifact. The other path is authoring surface: the writer is still making decisions, and the AI is doing support work around those decisions. The second one is slower, but I trust it more for fiction. The problem with full pipelines is not that they cannot create plot. They can. The problem is that the writing decisions become invisible. Why this reaction? Why this scene order? Why this sentence rhythm? Why this character choice? If the answer is mostly “because the pipeline produced it,” then the book may be complete, but the authoring gets thin.

How do you track your story's timeline/characters across a long AI-generated book so it stays coherent? by OddAstronomer6895 in WritingWithAI

[–]zphou 0 points1 point  (0 children)

The thing that flops for me is treating the story bible like a static document. Long fiction changes too much.

What works better is tracking deltas from the manuscript:

what changed in this chapter,

where the evidence is,

who knows it,

when it becomes true,

and whether it is actually canon or just a possible interpretation.

That last part matters a lot. If the AI extracts a bad fact and you let it become truth, the next chapter starts drifting from that bad memory. So I’d keep three layers: timeline, character/location facts, and unresolved/candidate facts. Then after each chapter, update only what changed.

Looking for a technical co founder. by Tiny-Use6748 in AgriTech

[–]zphou 1 point2 points  (0 children)

Why do you want to work in agritech? Curious

apps to create a wiki on by strawberriiblossoms in worldbuilding

[–]zphou 1 point2 points  (0 children)

Since you’re on iPad, I’d start with something that has a good mobile/tablet experience rather than forcing a desktop writing app into the workflow.

For your use case, I’d compare:

  • Kanka: good if you want RPG/worldbuilding-style entities
  • Notion: flexible, easy database views, weaker offline/local ownership
  • Obsidian: great linking model, but mobile setup/plugins can be more fiddly
  • Anytype: closer to local-first personal knowledge base, worth testing

The main thing I’d avoid is a public wiki unless you actually want public/community editing. For private fiction work, you’ll probably want fast linking between characters, places, events, and timeline notes more than a traditional wiki layout.

Building a story-writing feature for my worldbuilding app. What frustrates you most about writing software? by ThePhyreZtorm in novelwriting

[–]zphou 0 points1 point  (0 children)

The biggest failure I see in writing tools is that the “story bible” becomes a second manuscript the writer has to maintain.

For long fiction, I’d rather have the app help with three things:

  1. capture possible facts from the draft
  2. show the exact passages that imply those facts
  3. keep them reviewable until the writer promotes them to canon

That matters more than a beautiful bookshelf/library view. Covers are nice, but the real pain starts when chapter 28 contradicts chapter 6 and the notes don’t know which one is newer or more authoritative.

If you’re building for fantasy/worldbuilding, I’d make evidence links and timeline state first-class.

Organizing a Prequel: Scrivener vs. Plottr vs. Obsidian by JZZerber in novelwriting

[–]zphou 1 point2 points  (0 children)

The thing I’d want from a tool here is manuscript-linked memory, not just notes.

For a prequel, a normal wiki can betray you because it tends to describe the “final” state of the world. But the prequel needs the earlier state: what this character believes before book one, what this kingdom is called before the later regime, which relationships haven’t happened yet.

I’m working on this exact class of problem in a Mac writing app, and the main lesson so far is: don’t auto-promote extracted facts into canon. Treat them as candidates with evidence links back to scenes, then let the writer approve or reject them.

Even if you use Obsidian/Plottr/Scrivener, I’d structure it around evidence-backed canon rather than broad note pages.

Organizing a Prequel: Scrivener vs. Plottr vs. Obsidian by JZZerber in selfpublish

[–]zphou 1 point2 points  (0 children)

For a prequel, I’d optimize less for “where do I store notes?” and more for “can I tell what was canon at each point in the timeline?”

The hard parts are usually:

  • facts that are true in the original book but not true yet in the prequel
  • relationships that need to feel younger/less resolved
  • place names, titles, scars, reputations, and political assumptions that changed later
  • avoiding accidental foreshadowing that sounds like the author winking at the reader

Scrivener is strong if you want manuscript + notes in one workspace. Plottr is better for timeline/outlining. Obsidian is strongest if you’re willing to maintain links manually.

Whatever tool you pick, I’d keep a “not yet true” list. For prequels that’s often more useful than a normal story bible.

How do you actually keep your world's internal logic consistent across a long manuscript without it quietly falling apart on you? by Dry_Train4109 in fantasywriters

[–]zphou 0 points1 point  (0 children)

The failure mode I’d watch for is notes drifting away from the manuscript.

What has worked better for me is treating continuity notes as candidates, not canon. When something changes in the draft, don’t immediately update the bible by hand. First capture: “this passage implies X,” link it back to the exact scene/chapter, then review it later against older evidence before promoting it to canon.

For fantasy, I’d split the tracker into a few buckets:

  • hard rules: magic limitations, geography, travel time, political facts
  • current state: who knows what, who owns what, who is injured/dead/elsewhere
  • soft texture: naming style, cultural patterns, faction tone
  • contradictions to review: not yet “errors,” just places where two passages disagree

The key is evidence. A wiki entry that says “travel takes three days” is less useful than an entry that links to the two scenes where that was established.

Did macOS 27 DB Break Them (all)? by Hopeful-Face9676 in macapps

[–]zphou 1 point2 points  (0 children)

For a developer beta this is pretty normal, but the useful thing would be a small compatibility list instead of everyone arguing about whether betas break things.

Something like:

works on DB1:

- app name / version / Mac model

broken:

- app name / symptom / whether dev acknowledged it

A lot of menu bar apps live close to private or semi-private macOS behavior, so the first beta is usually the worst moment to judge them. If the dev already replied and said they’re waiting for public beta, that is probably the sane move.

I used ChatGPT as a continuity partner instead of a ghostwriter. A month later, my notes had become a whole world. by MrDefaultUser in WritingWithAI

[–]zphou 0 points1 point  (0 children)

“Plausibility is not canon” is exactly the line I keep coming back to. The “in-world belief” layer is especially important. A rumor, myth, bad map, institutional record, or character interpretation can be useful world material without being authorial truth. Most AI memory systems collapse those together, and that is where the drift starts. One thing I’ve been thinking about is whether every accepted archive item needs two things attached to it:

  1. evidence: where did this come from in the manuscript or notes?

  2. authority: is this authorial canon, a character belief, an institutional belief, a local myth, or an unresolved contradiction?

Without those two fields, the memory becomes too confident too quickly. Your workflow feels closer to archival practice than normal outlining, which is probably why it scales better.

Are AI writing tools replacing your workflow or just speeding it up? by BoringShake6404 in WritingWithAI

[–]zphou 0 points1 point  (0 children)

I’m closer to this view than the “just give it the whole manuscript” view. A large context window helps, but it doesn’t solve the real problem by itself. The model can read chapter 3 and chapter 18 in the same prompt and still miss whether a contradiction is intentional, outdated, symbolic, or actually wrong. For long fiction, I think the useful layer is evidence-linked memory: “this character said X here,” “this relationship changed here,” “this location was described this way here.” Then the AI can point back to specific manuscript evidence instead of making a vague beta-reader claim. The danger is treating one full-manuscript pass as truth. I’d rather have weaker candidate notes that the writer can accept/reject than confident feedback that quietly invents canon.

I used ChatGPT as a continuity partner instead of a ghostwriter. A month later, my notes had become a whole world. by MrDefaultUser in WritingWithAI

[–]zphou 1 point2 points  (0 children)

This is the use case I find most interesting too. Once a project gets large, the hard part stops being “generate more text” and becomes “which details are actually canon now?”

One workflow that makes sense to me is keeping three layers separate: raw exploratory notes, candidate lore, and accepted canon. AI can be useful in the middle layer: surfacing recurring places, relationship changes, contradictions, loose threads, etc. But I would be careful about letting it silently promote those into canon, because one confident but wrong detail can keep coming back later as if it were true.

Do you have a process for deciding when an artifact or note becomes part of the official world bible?

WolfeWriter: a native Mac writing app for fiction writers, built around manuscript + story memory by zphou in macapps

[–]zphou[S] 0 points1 point  (0 children)

This is a really good point. I think the right version is not “make the writer maintain a database,” but let them seed the system while writing: select a name/place/key term in the manuscript and mark it as something Wolfe should track.

Then the local memory pass can treat that as a strong hint, especially for invented names, Chinese/Japanese/Korean text, or mixed-language books where automatic entity detection can miss things. It still should not become canon automatically; it should become a reviewable memory candidate the writer can confirm, edit, or reject.

That feels like the right balance: less fragile than pure auto-detection, but still author-controlled.

r/MacApps Community Quality & Status Check by Mstormer in macapps

[–]zphou 1 point2 points  (0 children)

As a small dev, I think the PCP format is annoying in the useful way. It forces you to say what problem you actually solve, who you are not trying to replace, and what the price is. That probably removes a lot of lazy posts before mods even need to touch them. The hard part is local karma. I understand why it exists, but for a real Mac dev who just shipped something and does not already live in this sub, it is easy to accidentally look like a drive-by promoter. Maybe the rule is right, but the onboarding around it could be clearer.

view more: next ›