Understand platform behavior differences
RCS feature support and rendering behavior varies across Android and iOS devices, carriers, and regions. This page explains platform-specific rendering differences so you can design messages that work across Android and iOS. For design guidelines, see Follow RCS best practices. For known issues and workarounds, see Troubleshoot Android and iOS issues.
Platform-specific behavior summary
| Feature | Android | iOS |
|---|---|---|
| URL clickability in rich card descriptions | Plain text only | Plain text only |
| Privacy policy in agent preview | Visible | Not visible |
| Agent banner | Visible | Not visible |
| Multiuse label | Visible | Not visible |
| Card height variations | Supported | Single height only |
| GIFs in rich cards | Animated | Static images |
| Agent contact details | All contacts visible (multiple phone numbers, emails, websites) | Only first contact per type visible (by list order) |
Agent contact details
When an RCS agent has multiple contact entries (phone numbers, email addresses, or websites), the visibility of these contacts depends on the platform.
Android: All contact entries are visible in agent details. If the agent has two phone numbers or two email addresses, all entries are displayed.
iOS: Only the first contact per type is visible, based on the order set during agent creation. For details and recommendations, see Agent contact details.
Hyperlinks
Hyperlinks on iOS
Use one hyperlink per message and place it as the last element in the message text.
To display a link preview, include the og:image meta tag on the target page. For specifications, refer to the Open Graph protocol.
Place hyperlinks in a suggested action (OpenURL) or a button for the most reliable behavior.
Placing a hyperlink before other text in the message can prevent the link preview from rendering. On iOS, the link may not be clickable if followed by additional text.
When the hyperlink is the last element in the message text, iOS replaces the visible URL with a link preview. The end user must tap the preview to load the content.
Multiple hyperlinks in a single message do not generate link previews. Each link appears as clickable hyperlinked text. If automatic link loading is turned off in the device settings, the end user must tap each link to load it.
Hyperlinks in rich cards and carousels
Android and iOS: URLs in rich card and carousel descriptions are not clickable and appear as plain text. Use suggested actions with OPEN_URL (Browser or WebView mode) type instead. See URLs in rich cards and carousels for details.
Rich cards
Vertical orientation:
- Best for: Single-column layouts with prominent media
- Recommendation: Use vertical tall height for consistent display across platforms
- iOS consideration: iOS renders all vertical heights identically. Choose "tall" to maximize image area for Android users; iOS users will see the same single height regardless of your selection. See Media preview - vertical card orientation for details.
Horizontal orientation:
- Android: Displays correctly with image on left or right
- iOS: Causes image truncation and video display issues
- Recommendation: Use vertical tall setup for cross-platform compatibility
Media cropping with large text
iOS prioritizes rendering title and action elements over description text and media. This can result in image cropping when users have large text sizes enabled.
Prevention:
- Limit titles and descriptions to 3 lines maximum
- Use single CTAs
- Limit suggested replies to 3
- Use medium media dimensions
Suggested actions
Android:
- Rich card buttons remain visible after clicking
- Suggested actions (outside rich cards) disappear after clicking
- Both button types work as expected
iOS:
- Rich card buttons and suggested actions outside rich cards remain visible after clicking
- Suggested replies may appear in incorrect order
- Suggested actions inside and outside cards may combine into a single group
Recommendations:
- Design for both persistent and disappearing button behaviors
- Test action sequences on both platforms
- Provide clear visual feedback after clicks
Carrier verification models
The Verified by... badge displayed in the agent information on iOS depends on the carrier verification model used in the region. The badge is determined by the carrier network, not by Infobip or the agent configuration.
The following badge values are possible:
| Status | When it appears |
|---|---|
| Verified by Google | The agent is launched on a Google-managed carrier, where Google oversees brand verification and the launch process. This label is visible only on devices registered on that specific carrier. |
| Verified by [Carrier Name] | The agent is launched on a carrier-managed network, where the carrier verifies agents through the RBM Carrier Console or Operations API. How the carrier name is determined depends on the regional model. See the table below. |
| Verified by Trusted Partner | Some carriers prefer not to be named as the verifier for legal reasons. In such cases, Google approves the use of a generic Trusted Partner label with a generic logo. This option requires individual approval from Google. |
Regional verification models
The carrier name displayed in the Verified by [Carrier Name] badge depends on the verification model used in the region.
| Model | Region | How the badge is determined |
|---|---|---|
| Home carrier model | Global (outside India) | The badge reflects the end user's active carrier network. For example, an agent launched on both T-Mobile and AT&T displays "Verified by T-Mobile" to T-Mobile users and "Verified by AT&T" to AT&T users. |
| Interconnect model | India | A single primary carrier manages verification for specific agents. The badge displays the primary carrier's name (for example, VI or Jio) for all users within the interconnect. The badge does not change based on the end user's carrier. |
The Apple RCS implementation controls how the verification badge is displayed within the iMessages application.