Ask if you're good enough for a monorepo

Described problems are not unique to monorepos.

If changes in some component's repo cause this component to break iOS, but you absolutely must use this change right now for Android, you will be left with branching too. Or, maybe, specifying different versions, if you use more complex packaging than git submodules, and only if android and ios apps are not built from single codebase.

Modularity is when APIs are well-defined and there's no unnecessary coupling. For example you don't know where public API of your component ends. Monorepos help here: it can make it clearer because tests will fail sooner when you break API contract because as soon as you make changes to component, these changes will be tested against users of this component.

I regularly have all described issues (except large number of files) without monorepos.

The real stopper is that to introduce monorepo you need advanced build system with dependencies between targets, which include tests (if tests already ran in previous build, and nothing is changed, don't run tests for that piece of code again), and that requires hermeticity. Almost impossible with e.g. Rails app and regular CI.