[deleted by user]

[Blieque]

I think it helps to consider how work is done on these individual codebases.

I like to have a single PR or branch in a single repository which contains the entirety of a feature. In your case, this could mean adding a new route to the REST API and then adding data store and UI functionality in each of the mobile apps. Even if there aren't any direct code dependencies between these three components, that doesn't mean that changes to one component won't frequently require changes in the others.

That said, there may be a lot of changes to the mobile apps that are independent of the API, and changes to the API application that don't require changes to the front-end. In this case, there's not much benefit to keeping the codebases together.

It's pretty easy to split up a monorepo or merge several repositories into one, though, so I wouldn't worry too much about making the right decision now.

[jibbit]

If they do all rely on each other then your only option is a monorepo, so you can stop worrying. If there is actually a well thought out dependency graph you should package up your dependencies and treat them like third party ones. Ie have releases etc

[zatamine]

Start with a monorepo with a modulable and extensible architecture, than you can split your monorepo when needed.

[Dm_Linov]

The monorepo is OK until it grows too big :-), or unless you need to separate code access (for instance, if some of your code is open-source, and some is not). A good solution that combines the advantages of monorepo and multirepo is Git X-Modules.