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.

Google's Black Menu Bar

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

  • 2
    There is a hard limit of 2GB for an app on iOS, and apps larger than 50 mb can't be downloaded over the air (must be attached to wifi). See stackoverflow.com/questions/4753100/…
    – user40980
    Commented Jul 11, 2013 at 20:47
  • Could be relativley simplistic, in that they 'could', be using these multiple apps to determine which app has higher priority on the end user. I.e How many people have downloaded Google Maps relative to Gmail and vice versa. I mean google is all about analtyics.
    – user97093
    Commented Jul 18, 2013 at 20:38

7 Answers 7


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


  • 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.
  • 4
    +1 I hate downloading a whole bunch of apps I don't need just because I need a specific feature.
    – Andres F.
    Commented Jul 12, 2013 at 14:20
  • 1
    @AndresF. ... especially because mobile apps usually have memory limitation.
    – k3b
    Commented Jul 14, 2013 at 8:13
  • @AndresF. Thanx, I edited the answer. Commented Jul 14, 2013 at 14:54
  • These arguments apply just as well to desktop software. Yet mobile apps are significantly finer grained. The memory limitation is a false argument too, easily overcome with proper engineering. Commented Jul 14, 2013 at 20:33
  • 1
    It would also have a very large disclaimer
    – ViSu
    Commented Jul 16, 2013 at 6:58

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.


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…


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.

  • That would be terribly developer centric. Google would put the user first, not some convenience for the programmers. Commented Jul 17, 2013 at 6:04
  • There's a balance to be struck. If development is too costly, the product simply won't exist, and that's not good for the user either. In any case, Android, like all platforms, has plenty of conveniences for the developer that aren't so good for the user, such as the fact that most apps are developed in Java and so require more powerful hardware to get decent performance than if they were native apps. This means hardware is more costly and batteries don't last as long as in native-app phones.
    – kindall
    Commented Jul 17, 2013 at 15:08
  • Amen to that last comment :-) Commented Jul 17, 2013 at 18:41

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.


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.

  • On the other hand, there is some criticism about Emacs for having "everything and the kitchen sink". It seems to run contrary to the Unix philosophy of small & separate tools, each accomplishing a small task. A joke about Emacs is that it's more of an Operating System than an editor/IDE.
    – Andres F.
    Commented Jul 17, 2013 at 16:29
  • Having everything bundled together also goes against end user choice. What if I want Gmail but I use a separate Chat app? Why am I forced to download Google Talk if I'm never going to use it? And what if I don't know or don't care what 'Google Drive' is?
    – Andres F.
    Commented Jul 17, 2013 at 16:30
  • @AndresF. IMO, the end user choice should be to use chat from gmail if I want and if I don't want be able to, then I should be able to hide that feature or use a different chat from mail. Wait.. I think I'm beginning to describe Emacs Commented Jul 17, 2013 at 18:00
  • I understand you, but I'd rather not download crap I'm not going to use. I tend to dislike 'suites' of apps for exactly this reason. And no, I don't use Emacs. At work I use Eclipse (which is bloated enough), and I shudder at the thought of every plugin being mandatorily bundled... In my view, user choice trumps everything else.
    – Andres F.
    Commented Jul 17, 2013 at 18:55
  • In any case, carriers seem to agree with you. Bought an Android phone lately? They come with all sorts of crapware you cannot uninstall. Yes, some of it you can hide, but it irritates the hell out of me just knowing it's there against my will :) A lot of people agree with me, which is why there exists custom firmware removing the unneeded apps for almost every Android phone out there.
    – Andres F.
    Commented Jul 17, 2013 at 18:57

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.