This couldn’t have come at a better time for me. I needed to support UTF-8 characters so this really saves me from the complications of that.
If you’re looking to update the article on animating text, could I ask that a delta time approach is taken. Using wait() can be severely inaccurate, as I have previously encountered.
Sick! Now everyone who does typewriter the terrible non-accessible way (set text per grapheme and everything shifts back and forth all the time, making it impossible to read while printed) has no excuse anymore. 
This definitely would help save time, as well as bugs that occur when having type writer effects. Its a bit confusing for me to process how it works, but its better than scripting a type writer that can bug out all the time.
Nice, I’m not exactly sure what else I can use this for but I’ll definitely look for an area I can implement it in.
This seems pretty good! I’m planning on making a dialogue system for my game, and this will definitely be helpful, even more so because it handles the rich text formatting and all that, so players won’t see stuff like <b>text</ when the text is showing bolded text.
Would it be reasonable to make it possible to achieve this affect backwards to hide graphemes at the beginning of the label? Perhaps this feature could instead be implemented as a rich text tag that hides graphemes, so that any grapheme can be hidden regardless of whether it’s at the end. My use would be to offset the start position of a TextLabel so that multiple TextLabels can line up easily, although rich text could likely solve this for me.
I should probably just switch to rich text for chat messages, but I’m already manually calculating TextWrapped for my game’s chat due to this shortcoming:
Screen space on small mobile devices is valuable, and it’s disappointing to see messages use unneeded lines.
This is great, this takes out so many annoying processes that discouraged me from making stuff like this! Thank you for helping out and adding such an amazing feature!
Nice! Love to see these kinds of things get implemented into Studio.
It’s gonna help a lot. The other methods of achieving this effect are somewhat unreliable
For once a type writing effect doesn’t have to be so broken with localization, the text shifting slightly, or the text changing size a bit. This update was most definitely needed.
At this point you’re literally writing my game for me 
I can finally incorporate typewriting effect with custom colored words and no flickering.
Thanks!!
To be honest this is a bit of a non necessity considering its something that you can readily and easily do by just writing some simple code to do it. Instead of adding utilities like a typewriter effect i feel people would get much more utility out of something like being able to import your own fonts. But i digress, now if i want to i dont have to write my own version of this feature, so there are positives.
This also proves useful to ignore things that string will ignore. I hope that we can see graphemes being used for effectively and more use cases to come.
Wow man, this is so cool 
!
Will there be some API available for the beta?
They won’t always be the same, try: utf8.len("👍🏾"), that’s one grapheme but two characters (thumbs-up + dark skin tone modifier).
This is an excellent addition! Finally a built-in method to create typewriting text effects, long overdue.
Thank for the suggestion. I will update the example there.
Amazing! I honestly will use this so much.
This is a super good update for people who do UI work and this also helps with emphasizing things that are dramatic or bold in games like story or actions based games. Keep up the great work Roblox! 
Hell yeah! Something that a lot of developers including myself wanted to get added.
Hi!
I just want to add in; I really hope this is added to TextBox (i.e. entry field) objects too! Specifically, their actual input text field, not only the placeholder.
Currently, I can’t find an easy way to limit the amount of characters a player can input, so I just limit their final entered text’s length using string.sub, and give them an appropriate feedback message.
With this property, I can set the maximum visible characters to the max string length; although the player will still be able to enter (invisible) text past the limit, it will give them instant feedback of what their final text would be.
While in the future I’d love to be able to outright limit the input size of strings, this is a nice bandaid.
Thanks!
I second this–TextBoxes are one of the most neglected UI elements to date. We’ve been needing MaxLength, Type (e.g. ‘number’), and Max/Min properties for years, but are still forced to use expensive listeners for post-input modification. We also have no access to numeric keyboards on touchscreen devices.