Home/ Questions/Q 8488107
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T21:26:22+00:00

I am using TWTweetComposeViewController, when available, to send tweets from inside my iOS app.

  • 0

I am using TWTweetComposeViewController, when available, to send tweets from inside my iOS app. I pre-populate the view controller with boilerplate text, then let the user modify and send at their discretion. It works great for the most part. Distilled down, it looks like this (with body pointing at a valid NSString):

if (NSClassFromString(@"TWTweetComposeViewController"))  {
    TWTweetComposeViewController *iOS5twitter = [[TWTweetComposeViewController alloc] init];
    [iOS5twitter setInitialText:body];
    iOS5twitter.completionHandler = ^(TWTweetComposeViewControllerResult result) 
    {
        [self.viewController dismissViewControllerAnimated:YES completion:nil];
    };   
    [self.viewController presentViewController:iOS5twitter animated:YES completion:nil];
    [iOS5twitter release];
}
else {
    /* Do something else when the framework is missing */
}

Now if body is too long, i.e., more than 140 characters, the resulting tweet view is empty of any text at all, character countdown set to 140. I might have expected truncation in this case, although it does not appear to be documented in the Class Reference one way or the other what happens when the initial text is too long, but I can accept that I have to do the truncation to maximum tweet length before passing to setInitialText.

What I don’t understand is that certain messages which are shorter than 140 characters also produce the empty tweet view.

Initially I saw what seemed to be a perfectly valid string with 139 characters failing. I noticed that shortening the string made it work. But after a great deal of experimenting, I also noticed that replacing a URL which happened to appear inside the text with random text of the same length made it work. In other words, the URL itself is causing a problem.

So I thought maybe there was something weird about the URL I was using, but I distilled it down to this. This one works:

NSString *body = @"............................................................................................................................................";

while this does not

NSString *body = @"............http://a........................................................................................................................";

Observations:

  • They are both 140 characters long (and report that way in the console with [body length]). The only difference is the presence of something vaguely URL-like embedded in the middle of the second one.
  • The position of the URL within the string does not seem to matter, but if I change any one of those non-period characters to a period (thus making it not like a URL anymore), it ceases to be broken.
  • If I shorten the broken one, shaving 14 periods off the end, it works. That is, this particular URL embedded in periods for a total length of 126 characters is fine. 127 or larger is broken. Not clear how, or if, this relates to the length of the URL itself.

Anybody ever seen something like this? Any idea what is going on? Am I doing something wrong, or is the iOS Twitter Framework just broken?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I have run into the exact same problem. It is a known bug in the Twitter framework and is being tracked.

    Please see this discussion on dev.twitter.com https://dev.twitter.com/discussions/5024

    (I would have posted that as a comment rather than an answer if I could, but I don’t have sufficient SO credibility so thought I’d add the below observations as well in case they are of interest).

    When just adding text without URLs, the character count works as expected.
    Adding a URL with the addURL: method causes 21 characters of the tweet to be used (20 for URL plus a space). Adding the URL in the initial text causes 20 chars to be used for the URL.
    When including a single URL (using either method) the framework fails when the total character count exceeds 138 (e.g. 20 for URL + space + 117 chars of initial text) thus losing 2 characters. With just one URL the order of setting the initial text and then adding the URL with addURL: does not make a difference.

    When adding 2 URls, it fails when the total character count exceeds 113 this losing 27 characters!
    However, with 2 or more, if you add the URLs BEFORE setting the initial text, it fails with a total count of 136. So 2 chars are lost per URL again.

    Summary/Workaround – if just including 1 URL then adding it in the initial text will give you one extra character than using the addURL: method, but you will still be short 2 characters overall. If adding 2 or more URLs using addURL: then add them before the initial text, but until the bug is fixed, you will still lose 2 chars per URL.

    I have filed a radar, but according to this Can I browse other people's (Apple) bug reports?, the more times a bug is reported the higher priority it is given, so it is worth others filing it as well to increase it’s priority.

    • 0