Perhaps not the whole app, but some parts of it could be "utmost safe" while still being useful.
The list of "utmost safe" things (things that do not require calling unsafe blocks / C/C++, etc):
- bool operations
- bit shifts
- arithmetics (modulo arithmetic is "trap safe" as well)
- math ops like sin, sqrt, abs, ln could be implemented "utmost safely" (not sure if the current implementation does)
- comparison operations (unless overridden unsafely - †)
- hashing could be implemented "utmost safely"
- accessing struct fields / tuple elements / enum elements and enum element payloads
- accessing variables / constants (global, local, parameters)
- optional unwrapping
- calling a function - ††
- functions only calling utmost safe operations are in turn utmost safe
† - operation overrides that change from safe to unsafe is the whole new pandora box in its own... we'd need to somehow protect against it.
†† - stack overflow issue aside which (if considered) makes function calls not memory safe to begin with.
I am pretty sure it is possible to implement, say, a tic tac toe algorithm using only utmost safe operations. Or the "life app" algorithm. The chess algorithm. Even the multilayer machine learning training with back propagation, etc - the above list is more than enough for these mentioned tasks and many others.
As for the I/O.... some time ago I implemented a toy app to see what's possible to do without using standard library. That app doesn't use any unsafe operation at all, yet being able doing some sort of "I/O" (video / audio / keyboard/mouse input & output). Granted that environment is quite limited and the app makes some brave and ungrounded assumptions about memory address stability – something swift doesn't guarantee – so take that particular example with a grain of salt.