| Mobile developer here, who published several apps on the stores. Do not worry about the size of your app. Managing decoupled apps is way more annoying then conciseley written ones. And by the phrasing of your question I assume you are projecting the complexity of the codebase to the capabilities of the app. My piece of advice is the following: When developing for mobile modularize the functionalities by screens and aim for a strong coupling within them. Even when the functionalities are growing (proportional to the success of the app, that is), you will not often see too many similiarities between them and the redundancy is factored out easily. Only when starting to develop a larger app which shares multiple screens across it could make sense to bundle differently. In this case, you want to structure the codebase by your tests.
Most of the time, reusing a screen creates plenty pitfalls, which can simply be avoided by not reusing. Due to grouping the functionalities by screens, issues will mostlikely not be related to eachother.
Also, in my experience, libraries introduce more issues then solving, so trying to keep the app barebone will often result in a smaller download size and a more robust app. When applying these thoughts properly a larger app could look like the telegram client!
https://telegram.org/apps#sourcecode |