Sigh.
Memory leaks do not cause memory corruptions - exceeding buffer length or coding errors do. Memory leaks do not mess up any other process but the one causing it (a process can only access its own private address space…) - and most times do not even mess up the process creating them. It is no longer required to regularly re-boot your computer on a regular basis - Windows/iOS/Android are mature operations systems, with millions of users, and the vast majority does not reboot regularly or re-install the OS in order to keep it functioning correctly (Microsoft/Apple/Google invest millions of $$$ in order to make sure the OS is stable and reliable). Memory leaks are not RAM errors, and will not cause installation to fail (Alpha particles will corrupt memory and processors, but this is rare to the point of being anecdotal, on earth at least.) Programmers in Software companies test their code/product to ensure all memory is tracked, and some programming languages take care of such issue themselves (such “testing” is the function of QA department or the programmer itself - no software is simply “released”, though not all S/W hold to the same standards in that regard.)
Most times, installation is performed by the installer removing past installation and creating a new one, keeping required bits and pieces (files). In this case nothing is overwritten - the old file is removed, and the new file is instantiated in his stead. An installation method of modifying existing files (“patching”) exists, but that code is thoroughly tested to avoid errors and make sure the end result is valid - for example, by checking the cryptographic signature of these file matches. File-rot is mostly non-existant with modern disks: disk blocks are CRC checked by the disk hardware itself, making file-rot extremely unlikely, to the point of non-existant (and disk-block corruption will result in a completely corrupt program, one that would not run…)
Software companies do not (usually…) re-invent the wheel. They use third-party products to build their own. Zwift does not write Windows/iOS/Android, does not write the compilers used to create Zwift code (Microsoft and Apple do…), does not write device drivers (Intel/AMD/others do - and they test everything thoroughly). The cost and complexity of developing a product like Zwift is limited to Zwift application - not third party software. A Software developer generally assumes the environment and tools are sound.
So, while there is (was) something is what you’ve written, software and computers are not like this anymore, if they ever had been (even in the “old days”.)
Problem is, technology FUD has spread to the point of people not trusting technology, taking unnecessary steps to use it, associate magical powers to computers and software, generally distancing themselves from technology to avoid it’s evil, or reverting to some perceived low complexity method of applying technology in general - and explaining it all using technical language.
In this case, all this boils down to “reinstall”.
And no, it is so rarely necessary (taking the 0.00000001% where it is), that it should not even be mentioned as a “solution” to any issue.
What actually happens is sometimes developers or software companies take shortcuts with QA, development best-paractices, or ignore user’s feedback and issue reports: bugs will always be there, and they need to be fixed, not swept under the carpet.