No, not necessarily. Various Smalltalks have a wide range of different approaches to UI and IO more generally. This (their "operating system aspect" https://eighty-twenty.org/2019/01/13/why-learn-smalltalk) is the area in which they're most diverse, in fact. For instance, GNU Smalltalk has, by default, only a REPL, while Smalltalk 80 has a bitmapped GUI.
It can already kind-of do a REPL, so it'd be about making sure access to that functionality was robust, and then it's a matter of removing packages from the system until it's as small as you'd like. Assuming a subtractive approach, of course. There are other interesting subtractive approaches like Craig Latta's "Context" (nee Spoon) http://www.netjam.org/spoon/ which does something a bit like a page cache, marking used methods, classes, etc and eventually garbage-collecting those not used. In Craig's system, there's an upstream over the network from which missing classes/methods/etc can be faulted in, so this isn't as scary as it sounds. Then there are the additive approaches, which I've kind of lost track of, but there are several on the go, for compiling a fresh image from scratch from sources.
Normally they do, but some implementations (notably GNU SmallTalk) are so afraid of the SmallTalk way of doing things that they use source files instead, which IMO removes a large part of the attraction of using SmallTalk at all.
The image-based nature of Smalltalk-80 is both a positive and a negative. Inability to interoperate seamlessly with a "standard" developer workflow (editors, revision control, deployment) has, I'm pretty sure, hampered adoption.
I know there are tools and workarounds, and I'm quite familiar with how things are done there, and I used to be a huge advocate of the Smalltalk style approach. But over time, I've come to see two sides to this discussion.
"Smalltalk VM Written in Zig with methods stored as type-annotated ASTs"