However the articles primary complaints (that the pin is retrievable, and that the password database is recoverable) is always true no matter how well implemented it was. The entire concept of the application depends on Android's file permissions to stop other apps looking at the database. Once apps bypass that security, recovering the passwords is an eventual inevitability.
The pin is likely just there to stop friends & family from accessing it. The same way Android's pins and patterns aren't really "security features" as much as to stop friends and family (and casual thieves).
So overall the article isn't wrong, but even if the author fixes all of their complaints (and replaces DES with something actually secure), the app wouldn't actually be much better because the same concepts are the backbone of the security.
This all boils down to the author's decision to use a pin. If a four digit pin is the entire basis for security then it can never be made secure, even if it is hashed, even if it is encrypted, and so on. There's no number of BCrypt factors you can set to make a four digit combination secure.
So for the author to make the app more secure they would have to require the user enters a long password, but I get the sense that isn't their USP looking at their app page. Their USP is the fact it only requires a four digit pin, so therefore that is that.
The author could store the pin in a decent hash, and then encrypt the password database using e.g. AES256 but ultimately a four digit pin is a four digit pin. You cannot really fix that unless there is an actual hardware interlock (e.g. chip that checks the number and burns out after too many bad tries).