Case 1: I have two oracle APEX apps in a single workspace connected to schema A, which has granted access to data stored in schema X.
Case 2: I have two oracle APEX apps in a single workspace connected to schema A, which has granted access to data stored in schema X and Y, where the apps store their data separately.
Case 3: I have two oracle APEX apps in separate workspaces. Where app 1's workspace connects to schema A, which has granted access to data stored in schema X. And app 2's workspace connects to schema B, which has granted access to data stored in schema Y.
The two apps also communicates and share a little data between them.
Are there any pros, cons or best practice related to structuring the oracle APEX apps, their workspaces and underlying schemas as mentioned above?
I'd say it is you who should decide.
When HTMLDB was released (and then came Apex itself), we ("we" is our IT department) used [1 schema - 1 workspace - 1 application].
Then, as we grew older, we found out that this isn't the best option. Why? Because there's stuff we'd like to share (trivial example: workspace images), so - why would we import them into ALL workspaces and - basically - duplicate things? Nowadays, it is [n schemas - 1 workspace - n applications].
(OK, not really - there are different workspaces when we think that we'd rather separate one group of jobs from another, but it definitely isn't 1:1:1 any more).
As of schemas exchanging data: it works, no problem; grant required privileges, create synonmys (or not) and you're good to go. Lately, on one project, lead developer meant to split one application to 2 schemas/applications (so we'd have [2 schemas - 1 workspace - 2 applications] for that project). After discussion, we decided to keep everything in same schema (to avoid grants/synonmys issues), one workspace and 2 (or more) applications, all based on same schema.
So - it is up to you. Oracle talks about modularization, but - perhaps we shouldn't overmodularize things. Instead of making things simpler, they might actually become more complex than they should be.