Curse Your Sudden But Inevitable Betrayal

You guys, and girls, you won’t believe this.

So at work, I’m doing a feature that requires sharing a pre-formatted message by the user’s choice of mail, iMessage/SMS, Twitter, or Facebook. So we use the typical iOS compose controllers from the MessageUI framework for the first two, and Social framework for the others. Everything’s fine, until my issue gets returned, saying that the Facebook share sheet has no text.

It’s fine for me when I test it, so I search around for “SLComposeViewController Facebook empty” and discover something.

So, here’s an example of what an SLComposeViewController of type SLServiceTypeFacebook looks like when you don’t have the Facebook app installed:

Screen Shot 2015-08-26 at 4.15.29 PM

Right, got that? Now here’s what the same code does when you do have the Facebook app installed:

Screen Shot 2015-08-26 at 4.23.47 PM

That’s right – having the Facebook app installed wrecks the system-provided share sheet.

Better yet, this is apparently by design. What clued me in was a Stack Overflow question, where the correct answer points to a bug discussion on, which in turn points to a Facebook’s policy on pre-filled posts. In a nutshell, Facebook doesn’t want developers pre-populating posts for users, at all. It’s not good enough to allow the user to edit or delete the post you’ve prepared for them, you can’t offer them post contents at all.

And somehow, they are able to enforce this programmatically.

My boss was gobsmacked when I told him this on Slack and could hardly believe it. Can Facebook seriously hack the iOS frameworks to get this behavior? How is that technically possible, and even if they can, how are they still in the App Store?

Or, does Apple let them do it? One plausible scenario here is that since Facebook and Apple are special friends – enough so to have Facebook deeply integrated into Settings, Contacts, and elsewhere – iOS looks to see if the Facebook app is present, and hands off the compose logic to a controller provided by Facebook if so.

But, seriously, Facebook gets a binding veto over a built-in iOS API? Who died and made them boss?

Anyways, I filed this as a bug, 22443455 in Radar. Honestly, I’d rather have SLComposeViewController.isAvailableForServiceType( SLServiceTypeFacebook) return false than goad me into using a deliberately-crippled share sheet.

But more worringly… how the hell are they getting away with this? You and I can’t mention “Android” in an app description without getting rejected, and Facebook gets to change the behavior of the iOS SDK itself?! That’s appalling.

Comment (1)

  1. ddamico

    Ha! Very interesting to see this as I lost hours and hours a few months back wrestling with the same thing, but instead ran into it via UIActivityViewController. Some users were seeing the pre-populated share sheet, while others were seeing the blank-ified one and eventually the presence or absence of the Facebook app shook out as the thing. Once that was clear the two different presentations seemed perfectly sensible, though maddening –once the app is installed Facebook is free to provide whatever sharing extension they like. In your context, though, that outcome seems 100% maddening and 0% sensible, but makes me wonder if the same mechanism that prevents two Facebook services from appearing in UIActivityViewController has the (intended? unintended?) side-effect of presenting that sharing extension when used through SLComposeViewController. Anyhow thanks for posting this! Misery, company, etc

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.