Millions of development hours have been wasted reinventing the wheel or at least reattaching it. Take sharing, for instance; there are thousands of ways to share content. Some of these have content length restrictions. Some have image size requirements. Some require a specific set of metadata. There is not one simple standard because all these services have slightly different purposes.
Android solved this problem by use of the “Intent,” an object that signifies the intent to do something, and the data within it hints as to what. The beauty of this system is that it allows individual apps to decide whether they can handle a given Intent. The set of apps that handle Intents with images is different from the group of apps that handle plain text. The really cool part of this approach is that with very little effort, the developer of a new app can support sharing via apps that wouldn’t be thought of as typical sharing candidates and even apps that don’t even exist yet. The developer does not have to reinvent the wheel, and yet more is gained than from integrating with a few select services.
Unfortunately, this is one of the cases in which branding can get in the way. Product owners decide that having a tweet say “via mysupercool app” is more important than letting the user use his or her favorite Twitter app. They decide that users leaving the app is scary, so they have the developers spend a week or more coding support for two, three, maybe four services, each of which has to be thoroughly tested and might require additional special handling (e.g., shortening of links, handling of error cases) as well as dependencies on third-party SDKs and APIs. In the end, the app gets a limited interface for services A, B, and C, but loses rich interaction with those services as well as with services D through Z, not to mention the costs of developing these features means that other features might be cut or a future feature might get dropped because the app has to be updated to support a third-party API change.
But hey, now we have better “branding” because all these services say, “via mysupercool app,” and that’s worth something, right? Sure. Of course letting the users actually use their favorite apps would have meant more total reach for the product with greater benefit for the users and less effort for the developers. But, why would you want users to be able to share via thousands of apps, text your content to friends, save it for reading later, or keep your app supporting the latest services when you could just limit your users to Twitter and Facebook?
To be clear, sharing isn’t the only way in which the branding excuse ultimately harms users. Branding is also often used as a reason for limiting a color palette or even creating an icon that doesn’t conform with the standards of a given platform. It’s used as a reason to ignore usability and gobble up screen space. It’s used as an excuse to make an app worse and make it stand out as an awkward, unintuitive app on a given platform.
Breaking all platform conventions in the name of branding is like being a guest in someone’s home, slamming all their doors, and screaming, “Hey! Look at me! I’m important!” If you want to get invited back, being a jerk usually isn’t the best way to make that happen. If you instead let users use your app how they want and provide the best possible experience you can, you give users a reason to use your app. You get users excited about your app. You get users telling their friends about your app.
And word of mouth is far better for a brand than origin text on a crippled tweet.