Given the reduction to a single key, the traditional GUI rule is that Enter in a multiline/multi-paragraph input doesn’t submit like it does in other contexts, but inserts a line break (or paragraph break), while Ctrl+Enter submits.
Chat apps, where single-paragraph content is the typical case, tend to reverse this. Good apps make this configurable.
It’s turtles all the way down.
But if you click an arrow on the top of the text box, it expands to more than half of the height of the window, and now Enter does a line break and Shift-Enter sends. Which makes a lot of sense because now you're in "message composer" / "word processor" mode.
If you turn on Markdown formatting, shift+enter adds a new line, unless you’re in a multi-line code block started with three backticks, and then enter adds a new line and shift+enter sends the message.
I can see why someone thought this was a good idea, but it’s just not.
It even works inside bullet points to add separate lines as part of the same bullet.
Infuriatingly, some apps try to be smart — only one line, return submits; more than one line, return is a new line, and command-return submits; but command-return on just one line beeps an error.
Years of muscle memory are useless, so now I’m reaching for the mouse when I need to be clear about my intent
So much is solved when developers just use the provided UI controls, so much well-studied and carefully implemented behavior comes for free
Then make it easier for users to learn that they can enter more quickly with control+enter which you can advertise via tooltip or adjacent text.
Better that 100% find it trivially usable even if only 75% learn they can do it faster
The difference I’m referring to is that Ctrl+Enter is arguably acceptable on the desktop, but has no equivalent on touch keyboards on mobile.
Regarding the UI button, the way many people chat they would consider it too much friction to have to tap a button above the keyboard for every send — more friction than Ctrl+Enter is on the desktop,
Mobile doesn't necessarily have this issue because it can show the send button and the newline button at the same time and they're equally accessible.
Regarding your edit:
> they would consider it too much friction to have to tap a button above the keyboard for every send
My finger travels almost the same distance from the home row to hit the send button above the upper right corner of the keyboard as the newline button on the lower right. I've been doing this for ages.
Regarding on mobile, I’m familiar with chat apps that require a UI button press to send, and consider it unnecessary friction. It’s a larger mental leap to have to leave the keyboard.
I find this interesting! I've never considered myself "leaving the keyboard" on the phone as if I were task switching. When I'm done typing I flow directly to the send button and let the keyboard go. The fact that the button is above the keyboard makes no difference to me as long as it stays accessible.