Why don't companies ship multiple modules within a mobile app? Are there concerns about tight coupling?

Question

Preface: My question does not exclusively pertain to Google and it doesn't exclusively pertain to iOS. I'm only using Google and iOS as examples because they are familiar to many. I could have just as easily used 'Company X', apps 'A', 'B', 'C', 'D', and 'E', and 'Android', but I wanted to keep my question rooted in the real world with a tangible example.

---

In the iOS app store, Google has many apps. At a glance, I can see 'Google Search', 'Google+', 'Google Maps', 'Google Earth', and 'Gmail'.

But I wonder - Why didn't Google simply create a 'Google' app which can provide all of the functionality that these five apps provide? The black menu bar at the top of each Google webpage makes this possible on the web; so why don't they make this possible by way of a menu button at the bottom of one "global" Google app?

• Is Google concerned about tight coupling between the apps?
• Is Google concerned about tight coupling between the teams that develop the apps?
• Is Google concerned about app size?
• Is Google concerned about the memory footprint or CPU load that such a monolithic app might incur when it is loaded?

---

[Not a rant. Merely playing devil's advocate.]

In spite of many advantages, some iOS critics say that multiple pages of apps leave the iPhone and the iPad feeling "cluttered". This is particularly relevant to my question because it seems a bit much to expect a user to know about (and manage) so many Google mobile offerings. From a product standpoint, and arguably a usability standpoint, it seems like it would be wise to ship a single app.

---

---

If you're curious, I own an iPhone and a Nexus 7; so I'm not wedded to either of the two major mobile platforms.

And I have a real problem to solve here - Whether to bundle multiple apps inside of one large app, or to distribute separate bits of functionality in multiple apps.

---

EDIT: In response, to @MichaelT's comment

• While there is indeed a 2GB size limit for apps, the size of your sandbox is only limited by the remaining capacity on the device.

Answer 1

In layman's words:

• Not all users use all of a company's apps
• Different users have different needs
• Why force an user to buy a full package when he/she needs only a part ? (Ok, Google apps are free, but other software maker's aren't.)
• Having those apps separate makes it possible to be updated separately and, most importantly, sold separately.
• The fact that several apps are made by the same company doesn't mean they belong together.
• Imagine having a single "Adobe" app that comprises Photoshop, Lightroom, Reader, Dreanweaver, etc.
• Imagine a single "Apple" app with this modules: iPhoto, iTunes, Aperture, etc.
• This logic applies for both desktop and mobile apps

Edit:

• Mobile apps usually have memory limitations (@AndreF)
• Mobile apps are usually downloaded over-the-air, so a huge file size is not a good idea
• Multi-module apps need more steps to navigate. Mobile users need easier, faster GUIs.

Answer 2

Users expect a mobile app to perform a single task, or a small set of very related tasks.

The mobile platforms that you mention started particularly as phone OS's. Typically users performs many short tasks on their smartphone throughout the day. This is totally different from desktop computers. This short bursted usage pattern has lead to the design of a customizable home screen that gives direct access to single-task apps. Third party developers were also encouraged to focus their app around a single task.

With the arrival of tablets, the mobile device usage patterns have diversified, but the vendors apparently chose to keep the paradigms that were originally optimized for phone users. I suppose because users have become familiar with it.

To go back to your example of Google apps: most people won't need all of them. And even though it is true that the home screen clutter can make it harder to find the right app/task; an app with an extra level of navigation is pretty much the same.

Answer 3

Three words: Separation Of Concerns Do one thing (and do that good). ;-)

And on a sidenote: You can't multitask in a single app without reimplementing either some kind of "window management" or some other crazy logic. Which leads back to my initial statement…

Answer 4

The biggest reason is that smaller teams are more effective at delivering software that customers actually want to use, so you want to use as small a team as possible. You might think "well, why not use small teams for the individual features, and combine them later?" It turns out that combining work from more than one team in a seamless, consistent manner is very difficult. And managing such a product (what features does it need? how do you advertise it? and so on) is also very hairy.

Now some Android apps do actually do this to a limited extent. The Google Maps app has three different entry points: Maps, Navigation, and Local. These look to the user like three separate apps, but you get all three when you install one package, Maps. This makes sense because there are a lot of similar functionality required for all of these, they need the same graphics and icons, and so on. Basically it's taking the choices that would be on the main menu of an "all-in one" map app and "pushing it up" to the launcher rather than making the user answer a question every time they use the app. This feels to the user like one less step since "choosing the function in the app" feels the same as "choosing the app" -- pick an icon in the launcher.

Answer 5

Can't say what Google are concerned about, but what I think:

• Is Google concerned about tight coupling between the apps? - Having the apps together means you can't update them separately. Every minor update in a single (sub)app would result in an update in the app. This means many small updates frequently or few larger updates rarely (which is not good for bug fixes).

• Is Google concerned about tight coupling between the teams that develop the apps? - The teams can work separately but there must be coordination between them. Especially for build and integration of the apps together. A positive side is that fewer build/architecture engineers might be needed as only one app is built (there is no need for such members in each team)

• Is Google concerned about app size? - The size is a valid concern in mobile environment. But I think the app's size itself is not a big issue as it's downloaded once. I am more concerned about the frequent updates, sometimes not desired by the user (if a subapp that he/she's not using is updated). Slow networks and data charges are the main reasons - imagine having to wait for an update that you don't need, because it updates a part of the app you don't use. And you have to pay for it...

• Is Google concerned about the memory footprint or CPU load that such a monolithic app might incur when it is loaded? - Depends on how the app is structured it might not need so much memory/cpu compared to when it's separated. But the size of the app/resources would be bigger. There are various constraints like methods/classes count in an application. It might occupy too much space on the built-in storage.

Answer 6

At the risk of going against all the other posted opinions, I think making a Google mobile app with everything* integrated but out of the way would be a great idea!

A lot of their software can be applicable to a single user account. I personally use Gmail, Google Search, and Google Drive the most. These apps are separate apps but they are integrated together. If I am already on one of those three apps in the browser and need to go to the other one I find the top navigation bar to be the best way to switch between apps.

In Programmatic Thinking & Learning Refactor Your Wetware, Andy Hunt states that multitasking and context switching takes a toll on productivity and this includes switching between apps to get things done.

Do you know what Alt-Tab (or Command-Tab on a Mac) is called? It's a context switch.

Emacs is a good example of a single powerful program with a huge variety of functionality and purposes. Look at its success, it's been around for 37+ years and it is still a very popular editor. From Emacs I can check and send email, edit any file, run shell commands, browse the web, schedule events and todos, etc. I can do all this without switching contexts.

Google, likewise, could mitigate context switching by linking the mobile apps together or they can avoid it completely by making a Google App.

_{*If productivity is not the goal of the app or the apps are completely unrelated then I wouldn't see a good reason to combine apps into a single product. In Google's case a lot of its apps are productivity-oriented.}

Answer 7

they are each separate Programs, having them all running inside the same app would draw a lot of usage on the Device's Processor. having them separate means that the processes can be divided and not all running at the same time on the same thread. doing it this way gives the OS the ability to put the apps on the back burner so that other processes/apps can use the full potential of the processor, you can't use them all at the same time anyway.

they could come as a bundle like Adobe's suite of applications, but that suite is made up of several separate applications so that they don't all have to be running at the same time just to use one of them.