Seconding sequence diagrams, they are often v useful as they’re very quick and easy to sketch out and very easy to understand. Otherwise, YMMV, but generally no, not useful. You’re more than likely adding complexity, rather than reducing it.
There will be situations where it is useful. I guess you really want the codified high level view that UML gives if it describes how a system works if that system is something that will kill people if it goes wrong. Otherwise, probably not.
First problem here is a map/territory one. For a complex app, using UML means you now have a visual language that people need to understand as well as a programming language. The visual language, to accurately model the structure of the application, has to be quite close to the programming language, otherwise it can’t model it well. But the closer it is, the less point there is to it: you can’t actually test it or do anything useful with it, so why not just use the programming language.
Note it’s not really built primarily for individuals, it’s there for industrial teams. If you’re just using it as a tool yourself, then fair enough, but in teams, using it properly means learning and applying the rules of UML, at which point the above issue comes into play.
This is the second major issue: you don’t generally know in advance everything about an app. What you’re describing is a waterfall process, where you design everything, then move onto the building stage. This generally doesn’t work in practice, and waterfall processes make it super difficult to fix problems (this is why Agile exists, as a reaction to that). This is not to say this approach doesn’t work for everything, just that w/r/t software development it can often lead to serious quality issues.