You are talking about applications but this is just your own definition and segmentation of a single OBIEE instance, these applications doesn't reflect on the server as independent things.
That's why the BAR will contains your full OBIEE and when you import it you import the full OBIEE (ok, you can import only some layers of the BAR but still no "silos" approach taking only HR content or Finance content etc.).
As the concept of applications doesn't exist you can't then say "please generate a BAR with only the HR reports and that precise dashboard for finance and these 3 analysis there for the other guys".
Have a look at what rmoff presented few days ago at Tech16 UKOUG: https://speakerdeck.com/rmoff/source-control-code-deployment-and-concurrent-development-for-obiee-12c
You will probably find there inside some answers on why it can't be done and what else you can do to make it works better for your needs.
PS: yours is more a problem of concurrent development (even not many developers you have multiple objects at various stages of development)
It sounds like Sudheep Divakar is talking -perhaps inadvertently- about the idea of pluggable BI. This has been on Oracle's roadmap slides for a year or so now, the idea that as Gianni Ceresa says, you can take just a "HR" 'application' and deploy it alongside other 'applications'.
So far as I'm aware, it is only that though -- slideware.
For the here and now, OBIEE 12.2.1, you can only work with BAR files at the grain of the entire service instance, i.e. the complete RPD/Catalog/Security model. You use WLST export/importServiceInstance commands to work with these bar files.
As well as the presentation that Gianni Ceresa mentions, I have just published a blog that is relevant here: https://www.rittmanmead.com/blog/2016/12/source-control-and-automated-code-deployment-options-for-obiee/