I was just documenting issues I saw with the code from a maintainability standpoint. The older Tasks & Runnable API is very fragile when it comes to lifecycle

I was just documenting issues I saw with the code from a maintainability standpoint. The older Tasks & Runnable API is very fragile when it comes to lifecycle changes and will cause crashes regularly. This means that you end up building up a ton of patchy code over time to try and do what Kotlin's lifecycle aware coroutines will do for you. So of course he spent all his time patching: His code was fragile to begin with. You don't end up so many 3kLOC files without poor architecture. Look: I've been there. Ripping down fragile monoliths to refactor seems like a waste of time because you'll spend 3 months rewriting code while bugs pile up. It's worth doing though because you'll save 6 months of bug fixes in the future. When it comes to the APIs there's another comment here that explains explicitly the spyware issue (He was scraping emails and sending them to a 3rd party), but for the Android APIs that he was abusing they're recent privacy focused changes that cannot be ignored. Sure your website will run fine but fundamentally HTML is very similar to what it was a decade ago. Android's runtime is constantly evolving as the phones change to new demands. Battery usage is something they're exerting more control over, and I personally find that annoying. Privacy is another thing: I'm all for that. The permissions requests he was doing will literally crash the app for modern Android. You cannot request permissions that way anymore because the API has changed to make it more explicit. It sucks that he didn't care enough to fix it, but here we are. He's done an admirable job limping along the mess of a code base but he hasn't implemented the fixes that were needed for it to work on modern phones.