3

Text messages from my iPhone to my friend's Android phone do not stay in the 160 characters as sent. Sometimes they appear as two or three separate texts when they are received.

Improve this question

2 Answers 2

Reset to default
1

This is normal functionality and has been present on the original iPhone OS on the very first iPhone back in 2007.

What you are seeing is that the iPhone is allowing you to send messages that are longer than the SMS limit, and when you do that it automatically splits the message into the number of SMS messages required to send your message.

If your recipient has an iPhone, they just see the original un-split message as the iPhone puts it back together for the recipient. Other devices, such as your friend's Android device, just show the discrete SMS messages in the order they were sent.

Improve this answer
2
  • 2
    That's not quite correct - you're implying that the iPhone has this functionality, whereas others don't. In fact, Concatenated SMS (en.wikipedia.org/wiki/Concatenated_SMS) has been around since before the iPhone came along. Most modern phones, especially Android phones, implement this too. It's more likely that there are incompatibilities between the sender and receiver's network.
    – Andrew Ferrier
    Dec 23, 2012 at 12:43
  • @AndrewFerrier reading up on this in the past when I worked for a company that sent SMS for a living (via mBlox), its been quite an issue with android phones not in fact receiving SMS in this fashion and only 3rd party apps supporting it correctly. You are also quite right that the different networks encode and send SMS differently so that it could in fact be that as a cause. No way to tell really without further information on Android/Phone versions. Either way I stick by my answer.
    – Stu Wilson
    Dec 24, 2012 at 18:15
1

The problem is someone refusing to support Concatenated SMS, as @Andrew Ferrier noted. in a comment on Stu's answer. The spec makes for very dense, acronym-rich reading.

However, there's a section that's relatively readable, which reads:

3.8.3 Text concatenation
If the concatenation mechanism described in subclause 9.2.3.24.1 is not supported by the transmitting or receiving entity, the following textual concatenation mechanism may be used. The first message is ended with a + sign, and each subsequent message start and end with + signs until the final message which starts with a + sign but does not end with a + sign. 

 <message1>+ 
 +<message2>+ 
 +<message3>

Any header fields placed on the front of an MO or MT message are not added to the second and subsequent messages. This provides a simple mechanism which is completely backward compatible. There is no indication of the number of messages and should a message be lost by the system or arrive out of sequence then the original message cannot be reconstructed. Therefore, wherever possible the concatenation mechanism specified in sub clause 9.2.3.24.1 should be used instead.

Since the '+' characters would be apparent if the receiver didn't support the simple coding but the sender did, it's clear that this simple mechanism is not supported by Apple.

I gave up/lost interest in deciphering the spec before figuring out who supports or doesn't support 9.2.3.24.1 but it doesn't matter too much to me; the blame falls on Apple for not supporting the simple fallback scheme.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .