Lettera: New file behaviour is very incorrect and broken

Lettera Lettera feedback
1

So if Lettera’s mission statement is to be a standalone Markdown file editor, its New File behaviour should be considered very broken.

In the macOS document model (whether you use autosave or manual save), New File should always create a new Untitled file with an undetermined location until that file is closed / saved. Every well behaved Mac app that considers itself a document editor uses this model: TextEdit, Pixelmator, Pages, even Panda.

But Lettera does NOT do this. It instead creates a new document with the explicit title Untitled and saves it in the explicit location of its iCloud storage. This also assumes that every new file should belong to some kind of default project, which is NOT what a document editor in macOS is supposed to do.

Hitting Cmd+N a bunch of times results in this:

This is understandable if Lettera is an app like Bear, where everything is not a document, but rather items in an internally managed project. But Lettera’s purpose is to be a standalone Markdown editor, and thus this kind of behaviour should be considered both incorrect and broken.

2 Likes
2

Most people like and expect that behavior. Let’s assume, in the sense of a definition, that you are right. But then the question arises: Why shouldn’t it be incorrect and broken? As it is, it is just useful.

What exactly is the point of your criticism? Does this behavior disrupt your workflow or are you trying to determine, based on your very own definition of what an editor is, whether Lettera fulfills that definition?

For me Bear is a document or text editor like Lettera. I have many documents saved in Bear :slightly_smiling_face:

3

Not at all. This is about the app behaving like a good macOS citizen. Anything that uses the document model on macOS has standardised behaviour. Users expect this standardised behaviour for myriad reasons, each with their own valid use cases.

2 Likes
4

I agree with Somnesis. I find it especially jarring that Lettera is creating a new file in my iCloud. I don’t want anything going to iCloud without me explicitly asking.

I think Panda does it correctly. I’m not sure why the developers changed it!

1 Like
5

Use „New Window“ instead of „New“ if you like that behaviour. It is already implemented. Or use Shift-Command-N

6

You’re right that plain ⌘N departs from the standard document model, and that’s a deliberate choice. Let me explain the thinking, because I think there’s a misunderstanding about what’s actually happening.

The ability to work inside folders changes things a little. ⌘N creates a new file in the currently selected folder (standard behaviour), OR (if no folder is open) it reopens the default iCloud folder and creates the file there. That second case is the non-standard one, I’ll own that. The reasoning is speed of capture: once we let you redefine the default folder, it lets you go from “new file” to “typing” without the “Save as…” → pick-a-location dance every time. It’s a trade-off, and I understand it won’t be everyone’s preference.

But the standard behaviour you’re describing absolutely exists too: it’s on ⌘⇧N, which creates a temporary untitled document with no fixed location you have to choose. And worth noting: this is closer to the system apps than it might seem. The moment you type into an untitled TextEdit document, autosave writes it to a real location rather than keeping it purely in memory, and with iCloud Desktop & Documents enabled, that location is inside iCloud. Lettera’s untitled documents work the same way. So the model you want isn’t missing; it’s on a different shortcut, and it behaves much like TextEdit does.

Given that, “broken” feels a bit strong, both behaviours are there, and it’s really a question of which one lives on ⌘N by default. That’s a fair thing to disagree on, and it’s almost certainly something we’ll make configurable, since you’re clearly not the only one who’d expect the standard mapping.

Thanks for the detailed write-up, this is exactly the kind of feedback that helps :slight_smile:

7

Is that intended behavior?

What confuses me:

  1. The name of a new window considers the names of untitled files in the workspace
  2. The name of a new window temporarily appears in the sidebar of the workspace

Edit: That behavior is always related to Lettere’s iCloud folder, no matter if it is open or not

Edit: Sorry folks! :man_facepalming: I’ve been using a MacBook Air since 2015, but I’ve never used iCloud. This behavior (at least point 1) seems to be normal, as a look at how Pages behaves has shown.

8

Yes, everything is correct here.

Yes, the default macOS autosave place is iCloud (not our choice, it’s the system) so the name of the file need to unique in that folder.

Same as last point :slight_smile:

1 Like
9

Thank you matteo!

Sorry the language was perhaps stronger than intended. It completely broke my Panda workflows AND it was non-standard macOS behaviour. So there was a bit of knee jerk there. I’m sure these were design decisions that were carefully thought through, so I’m sorry about my wording. It was not meant to be incendiary :slight_smile:

That being said, I do think my point still stands. Even if this was an intentional “quick capture” design decision, I do still believe it is incorrect. I think the crux of this has to do with the question “What is Lettera?” You know the answer to that question certainly better than I. But based on what I read on your website (and based on the fact that you have another existing app Bear), I would surmise this:

  1. Lettera is NOT Bear.
  2. Lettera is NOT trying to be Apple Notes.
  3. Lettera is NOT trying to be Drafts / Obsidian / Notion / etc.
  4. Lettera IS meant to be a standalone DOCUMENT editor, in the same vein as TextEdit, Pages, Panda, etc.
  5. Lettera ALSO supports a project / folder oriented workflow.

So to me the key issue is point number 4. If it IS trying to be a standalone macOS document editor, it SHOULD use the standard macOS document model in order to behave like a good macOS citizen. I can point to any number of Electron apps that are terrible macOS citizens, but based on how well Bear and Panda are designed, my assumption is that the good folks at Shiny Frog care about being good macOS citizens and are the kinds of Mac users that appreciate Mac-assed Mac apps. It is because you care that I raise this issue :slight_smile:

Now based on my use case, number 4 by far trumps numbers 1-3 in the “Quick Capture” use case because Lettera is not SUPPOSED to be any of those apps. But my view might be incorrect. I truly hope not though because you guys already have an existing app, Bear, that is meant to be that app that is 1-3. As such, I don’t believe the “quick capture” is a valid reason for incorrect and non-standard behaviour. And even if it is, then I believe this is something that developers and users should give feedback to Apple about, and NOT take it into their own hands to implement incorrect and non-standard behaviour. There are of course examples of developers who DO take things into their own hands. Take Chrome’s Hold Cmd+Q to quit for example, which “fixes” accidental quitting on macOS. But that, among many things, makes Chrome a terrible macOS citizen, and Google of course cares nothing about making their apps more Mac-assed.

So my argument remains that the Cmd+N behaviour should be what Cmd+Shift+N currently does. (As an aside “New Window” is an extremely confusing label for what would be the correct “New File” behaviour… so much so that I didn’t even try it. Now that I have, I’m thankful I have this workaround until the behaviour is correctly fixed.)

When it comes to your TextEdit example, I’m well aware of how macOS saves files to disk that are “unsaved” and hanging out in the ether. It’s actually precisely this feature that I and many other users rely on (whether they know the underlying implementation or not) when working with documents. To give a bit of insight into why I feel so strongly about this in the first place, I can describe my use case a bit. The macOS document and autosave model allows a user to hit Cmd+N and work on a document without having it “saved” anywhere knowing that if the power cord to the Mac gets pulled, nothing is destroyed. And the key thing that this allows is exactly the kind of quick capture / quick doodle / quick photo that you’ve advocated for. BUT you are able to do this WITHOUT explicitly saving the document into any user chosen folder. This allows the user to rapid fire new notes / drawings / ideas without worrying about where to file them. And this default behaviour is perfect for quick capture, and in my opinion better than the current behaviour because it allows you to do the quick capture BUT the moment you close the window / tab, it FORCES you to either save or discard the quick capture. This last part is critical, as it allows me to only KEEP the quick captured notes / drawings / etc. that I actually want and discard the rest. It also forces me to make this decision at one point, which is a good thing, as you are not allowed to close the tab / window without addressing the issue of where to save / discard. The second reason why this is better is that these transient documents are ALLOWED to be transient, which the current behaviour does not allow. Under the current behaviour, when I make a New File that I do some doodles on, that file is forced to be saved within the user facing file system, and this generates a ton of trash Untitled files that I never wanted to be there in the first place. These files then need to be manually deleted, as opposed to automatically discarded when closing the window under the Document model. At the end of the day, this is simply my use case, and others will have myriad of their own. But the bottom line is that these use cases and workflows have been built around standard macOS behaviour that has existed for a long time and any Mac-assed Mac app should respect that.

Lastly, coming to number 5… things get more interesting. To be fair, I don’t think macOS has a standardised way on how projects should be treated. So you’re right in trying to define good behaviour when working with projects. BUT I think it is misguided to try force every single use case into a project-oriented workflow by forcing all new documents into a “default folder”, even if you let the user pick what the default folder is. This is simply non-standard behaviour for a document based Mac app. Other apps do manage to solve this elegantly though. TextMate 2, despite its age, handles this pretty well: All documents (new or opened) are treated correctly as documents, but if you open a folder instead, that window where the folder is opened to will be in “project mode”. I’m sure there’s other examples to look at. Point being that I think you can still have an app that has a “project mode” that correctly respects how document behaviour works in macOS.

10

That’s not quite correct. Even if you don’t have iCloud Desktop & Documents enabled, TextEdit’s default save location is in its iCloud Drive folder and new files show up there even before you save them and name them.

I’m not sure that this model works with all apps any more. I just opened a new Numbers document, and, while it wasn’t saved, it was written to the Numbers folder in my iCloud Drive. iA Writer doesn’t write new files to disk, nor does BBEdit. As for “the power cord to the Mac being pulled,” I’m not sure all apps have the ability to save the files without saving them.

I do think, however, that having File > New and File > New Document is very confusing; I can’t think of any app that has two ways of creating new files, without it being obvious to users what the difference is.

11

iA Writer has these two ways as an option. The default way is to create a new file inside the library. As in Lettera.

Screenshot 2026-06-30 at 11.05.44
Screenshot 2026-06-30 at 11.05.441890×1588 297 KB

12

It’s more than that, and it ties into your point 5. Lettera can’t be just a document editor, so it can’t behave exactly like one.

We’re ambitious, I’ll own that, we’re mixing a document-based model with projects in a single app. There aren’t many examples of that, and macOS doesn’t hand us a standard.

On ⌘N specifically: I don’t think it can work quite the way you’re describing. If you’re focused on a project, would you really expect ⌘N to drop that context and spawn a new file in a new window? I’d think most users wouldn’t. And having ⌘N behave differently depending on context is its own UX problem as muscle memory stops being reliable.

So our take is:

⌘N → new file in the current context (or the default), more like a “project” app
⌘⇧N → new file in a new window, behaving like a standard document app

⌘⇧N is the discardable-untitled flow you’re after. It mostly follows that standard autosave-and-discard model. If you want a temporary document you can throw away on close rather than something that lands as a stray Untitled file, that’s ⌘⇧N.

So the behaviour you want isn’t missing; we’ve put it on the shortcut that doesn’t disrupt the project context.

We can also add settings to tweak the default behaviour down the line, but those will come in a later update.

We’re very open to keeping this conversation going, we just want to only commit to things that are easy to reason about and genuinely good UX :slight_smile:

13

I don’t see any practical difference between the first two, which is even more confusing. They are both in the library, and I don’t see anything different if I choose one or the other. And the third option is Command-Option-N, for New. That creates a new standalone document, which isn’t saved to the library.

I always use Command-T, which creates a new document in a new tab - so a fourth possibility - because I often work with multiple documents.

15

With apps that save to iCloud by default, like Pages or Numbers, I’m just aware that they’re saving to that location, and If I want to put the file somewhere else I use the File > Move To command. It makes a lot more sense to be clear in the menus and not have multiple options. Apple has clearly decided that that behavior - new file to iCloud, if the user is signed in - is the default, and the Move To command allows users to put documents anywhere they want.

Also, in Lettera, the Move To command is not available.

16

It is for single file, not when you’re opening a folder.

17

It’s not available when I select a single file.

image
image1180×856 91.6 KB

18

You’re in a open folder there, I was talking about a single file window :slight_smile:

But I’ll see if I can enable it also for the folder case, it shoulnd’t be an issue.

19

I’m in the main iCloud > Lettera folder. Are you saying that by default you weren’t planning on having an option to move files out of iCloud?

20

I’m in the main iCloud > Lettera folder. Are you saying that by default you weren’t planning on having an option to move files out of iCloud?

Ah, I think there might be a small misunderstanding! Your files aren’t locked into iCloud at all.

Lettera is just an editor for your files; it doesn’t hide them or keep them anywhere you can’t reach. You can drag and drop a file straight from the sidebar into Finder to move it elsewhere, or just move it in Finder directly.

The “Move To…” command exists mainly for single-file windows, where the file is harder to get at (no sidebar, so you’d need the proxy icon or know the location on disk). But when you’re working in a folder, the sidebar already gives you full access to the files, so a “Move To…” there felt redundant.

21

Okay… That’s not really the way a lot of people work, but you’re the boss.