There is no "one-size-fits-all" solution to this, it all boils down to the question what exactly
in some way connected to the main one
means. If both applications, especially from the viewpoint of their use cases, are tightly coupled and interwoven, with an interface between them which changes frequently, then it may be better not to separate them. If they, however, can be separated in a meaningful manner, maybe with a decoupled release management, then two applications maybe the better choice. But let me comment on some of your pros and cons:
all application with the same UI
depends on what you mean by this: if you mean "similar looking UI", this is quite independent from the decision for one or two applications. If you mean "just one UI for both", then this might be an indication the use cases are so entangled that one application will be better.
"single login" vs "implement a single sign on system between all the app"
is indeed a little bit more effort when creating separated applications, but should IMHO not be the driving factor behind the decision.
one big git project
is not necessarily a bad thing, managing too many git projects can actually become a downside (but of course, when creating separate apps you will still be free to use just one git repo). Separate git repos are favorable if there are different teams for each application, and there are no common, reusable libs in the repository, but if there is only one team, I can imagine one repo might be the better decision - for both approaches.
Then you wrote
more difficulties to manage and release updates
on the con-side for "one application" - that can be actually true, or it can be false, it depends. If there are stable interfaces between the two applications, so you can mix different version of app#1 and app#2 almost arbitrarily, then releasing a newer version of just either app#1 or app#2 will be easiy. If there are no stable interfaces, and there will be only specific version combinations of app#1 and app#2 compatible with each other, then managing and releasing updates for separated application will increase your configuration management costs, and it will probably be easier for a single application.
duplicated libraries and common files
When you have two applications with common libraries, those libraries should not be duplicated, they should be reused from both applications. If you mean "duplicated on the production server": space for typical libs is cheap, and the deployments should be automated by some scripts, so deploying the same lib twice should not make any problems. And "common files": if there are things in these files which will need to be maintained in both applications in parallel, try to move the commonalities into a common library and reuse it.
TLDR; this depends heavily on the requirements of your individual case, functional as well as non-functional ones.