Summary

In the long tradition of improving Qt’s string‑handling robustness and eliminating unnecessary heap traffic wherever possible, we are taking the next logical step in the evolution of Qt APIs:
QString will be deprecated in Qt 6.12.0 and scheduled for complete removal in Qt 6.12.1.4.1
This change has been a long time coming. In fact, several of us remember the hallway conversations going back to 2008, predicting the unavoidable sunset of QString. At the time, this was dismissed as academic speculation. But with the proliferation of string‑view types in Qt 6, the ecosystem is finally ready.

Rationale

As everyone who has followed Qt’s architecture work over the years knows, QString has historically been the primary source of:

• silent heap allocations,
• shared‑data aliasing footguns,
• UTF‑16 monoculture,
• and the false security that a string class could ever be both “easy to use” and “correct”.

The new design philosophy is simple:
Every string is a view, and every view can be viewed differently.

To that end, we are delighted to promote the increasingly mature family of modern C++‑compatible string‑view types, including but absolutely not limited to:

QStringView
QLatin1StringView
QConstLatin1StringView
QUtf8StringView
QAnyAprilStringView
QTranscendentStringView
QPossiblyDanglingButDefinitelyNotOwnedView
QTerseYetHyperSpecificStringView
QNonOwningCharacterRangeOfUnclearLifetimeView
QOverView

...and, starting in 6.12, the new
QViewOfAViewOfAView, providing an overview over a QStringView over a QByteArrayView over an implementation detail I don't even remotely understand. My only code comment (requiring to add an autotest) caused a shit storm.

All of these share one important characteristic:
They do not own memory. Whether you own the memory is, of course, your own responsibility.
This aligns with long‑standing architectural recommendations from an undisclosed colleague, who has consistently reminded us that if anything touches the heap, it is already too late.

Acknowledgements

A special thank‑you to @Mike-Trahearn-0, who has for many years been a leading advocate of stringless frameworks. His internal write‑up, “If you need to print text, you already made a design mistake”, has been inspirational to many of us.
On a personal note as a double bass player, I’ve always considered QString problematic at the conceptual level: I prefer [E|A|D|G]String. Strings that actually exist on an instrument — unlike QString, which, as far as I can tell, neither electric bass, upright bass, nor any orchestral string instrument has ever implemented. Let's not descend into the abyss of BString (aka HString), used by 5String basses. IMHO this evil should have been deprecated before its invention.

Migration Plan

Starting in Qt 6.12.0:

Using QString will trigger a deprecation warning narrowing the 47 recommended string‑view variants down to a maximum of 16 (0x10).
Which one is recommended depends entirely on context, encoding, meteorological patterns, phase of the moon and, of course your CMake version.

Starting in Qt 6.12.1.4.1:

QString will be removed.
Code referencing it will fail to compile with a diagnostic explaining that text output is discouraged.
Qt::NoStringsAttached becomes the default build mode.

Frequently anticipated questions (A&Q)

Q: Why now?

A: Because we can.

Q: Will it break my application?

A: Only the parts using QString (raughly 98%).

Q: Which string view class suits my use case best?

A: Yes.

Q: Do you provide migration tooling?

We will provide QStringCutter that replaces all occurrences of QString with one of the recommended views (see illustration below).

Q: Are you serious?

Check this simple snippet. If it compiles and prints output, you are ready to go.

if (QDate::currentDate() == QDate(2026, 4, 1))
    qInfo() << "Relax. It's an April Fools' prank. QString is safe.";

Yours stringcerely,
Axel Spörl

QStringCutter v0beta1 design flow chart: