If you have ever been frustrated by blurry videos, broken group chats, or the infamous “green bubbles” when texting between iPhone and Android, the landscape is finally changing.
With Apple officially supporting RCS in iOS 18, cross-platform messaging is entering a new era that goes far beyond simple SMS compatibility. High‑resolution media sharing, typing indicators, read receipts, and modern group management are now possible between the world’s two dominant mobile ecosystems.
However, the transition is not as simple as flipping a switch. Carrier policies, security limitations around end‑to‑end encryption, satellite integration, and even billing structures—especially in Japan’s uniquely structured telecom market—create a complex but fascinating picture. In this article, you will gain a deep, data‑driven understanding of how RCS works on iPhone, how it differs from iMessage and SMS, what it means for privacy and business messaging, and why the Japanese market offers one of the most intriguing case studies in global mobile evolution.
- From SMS to RCS: The Evolution of Mobile Messaging Infrastructure
- Why Apple Adopted RCS in iOS 18: Regulation, Market Pressure, and Ecosystem Strategy
- Understanding GSMA Universal Profile and How RCS Actually Works
- Green Bubbles Reimagined: What Really Changes Between iPhone and Android
- Feature-by-Feature Comparison: SMS vs MMS vs iMessage vs RCS
- Japan as a Case Study: Carrier Strategies and the Second RCS Wave
- KDDI’s Aggressive Expansion and Satellite-Integrated RCS
- NTT Docomo’s Pricing Complexity and the +Message Factor
- SoftBank, Rakuten Mobile, and the MVNO Ripple Effect
- Step-by-Step: How to Enable RCS on iPhone and Avoid Hidden Charges
- Security Reality Check: The Current Encryption Gap Between iOS and Android
- MLS and the Future of End-to-End Encryption for RCS
- RCS Business Messaging (RBM): The Next Battlefield Against OTT Apps
- What This Means for Global Users: Practical Recommendations and Future Outlook
- 参考文献
From SMS to RCS: The Evolution of Mobile Messaging Infrastructure
Mobile messaging infrastructure has undergone a profound transformation over the past three decades. What began as a minimal signaling feature inside cellular networks has evolved into a data-driven, IP-based communication layer that now competes with full-fledged internet platforms. Understanding this shift from SMS to RCS is essential if you want to grasp why today’s smartphone ecosystem is changing so dramatically.
SMS (Short Message Service), introduced in the early 1990s, was never designed as a rich communication tool. It used spare capacity in the signaling channel of circuit-switched networks and allowed only 160 half-width characters per message. There was no concept of typing indicators, read receipts, or large media sharing. Yet its universality—tied directly to phone numbers—made it a global default.
MMS attempted to extend SMS by enabling images and audio attachments. However, strict carrier-imposed size limits, often between 300KB and 2MB, severely restricted usability in the smartphone era. High-resolution photos and HD videos were routinely compressed into barely recognizable files.
| Standard | Network Basis | Media Capability | Interactivity |
|---|---|---|---|
| SMS | Circuit-switched signaling | Text only (160 chars) | None |
| MMS | Carrier gateway | Low-size images/audio | Limited |
| RCS | IP-based (IMS) | High-resolution media | Read receipts, typing indicators |
The real disruption came from OTT messaging platforms such as LINE and WhatsApp, which leveraged mobile data networks instead of carrier-controlled infrastructure. These services delivered group management, large file sharing, and end-to-end encryption, redefining user expectations. According to GSMA, RCS was designed specifically to bring similar richness back to carrier-native messaging while preserving the universal phone-number identity.
RCS (Rich Communication Services) represents a structural break from the past. Built on IP and standardized through the GSMA Universal Profile, it enables session-based messaging over IMS (IP Multimedia Subsystem). This means conversations are persistent and interactive rather than isolated message packets.
The importance of this shift became even more visible when Apple announced RCS support in iOS 18. For years, messaging between iPhone and Android devices defaulted to SMS/MMS, creating quality gaps and the well-known “green bubble” divide. With RCS adoption, media quality and interaction parity significantly improve across platforms, even though visual distinctions remain.
Industry observers such as ITmedia and Apple-focused technical forums have pointed out that this move is not merely cosmetic. It signals the gradual retirement of circuit-switched legacy messaging and the consolidation of communication around all-IP networks. In infrastructure terms, messaging is no longer a fallback utility—it is becoming a core data service integrated into modern network architecture.
This evolution from SMS to RCS therefore reflects more than feature expansion. It marks the transition of mobile messaging from a constrained carrier add-on to a scalable, interoperable digital communication layer designed for high-resolution media, real-time presence, and global compatibility.
Why Apple Adopted RCS in iOS 18: Regulation, Market Pressure, and Ecosystem Strategy

For years, Apple resisted adopting RCS, even as Google and carriers promoted it as the successor to SMS. The turning point was not a sudden change of heart, but a convergence of regulatory pressure, market dynamics, and long-term ecosystem strategy. iOS 18’s RCS support is a calculated response to structural shifts in the global mobile industry.
Regulatory Pressure: The EU’s Digital Markets Act
The most decisive external force was the European Union’s Digital Markets Act (DMA). The DMA designates large platforms as “gatekeepers” and requires greater interoperability between services. Messaging interoperability became a central issue, and Apple’s historically closed iMessage environment inevitably came under scrutiny.
According to reporting by ITmedia and analysis from Infobip, the DMA’s interoperability requirements created a new compliance landscape in which maintaining a fully closed messaging silo carried legal and reputational risk. Adopting GSMA’s Universal Profile for RCS allowed Apple to improve cross-platform compatibility without opening iMessage itself.
| Factor | Impact on Apple | Strategic Response |
|---|---|---|
| EU Digital Markets Act | Interoperability obligations | Support RCS Universal Profile |
| Public scrutiny of “green bubbles” | Brand perception pressure | Improve Android messaging quality |
| Carrier ecosystem alignment | Global standardization momentum | Adopt GSMA-backed framework |
Market Pressure: The “Green Bubble” Narrative
Beyond regulation, market psychology played a major role. The so-called “green bubble problem” became a cultural phenomenon, especially in North America. When iPhone users texted Android users, conversations degraded to SMS or MMS, resulting in low-resolution media and no read receipts. Google’s long-running “Get the Message” campaign amplified this gap in public discourse.
While Apple never officially framed its decision as a response to Google, the reputational cost of appearing anti-interoperable grew. Industry observers noted that younger demographics increasingly value seamless cross-platform communication. Improving message quality between iPhone and Android users reduced friction without sacrificing Apple’s blue-bubble differentiation.
Ecosystem Strategy: Controlled Openness
Crucially, Apple did not merge iMessage and RCS. Instead, it implemented RCS within the existing Messages app while maintaining visual separation between blue (iMessage) and green (RCS/SMS) bubbles. This design choice reflects a deeper strategic principle: openness at the protocol layer, differentiation at the experience layer.
By adopting GSMA Universal Profile 2.4 or later, Apple aligned with a carrier-backed global standard. According to GSMA documentation and industry analysis, this ensures interoperability across operators and device manufacturers. However, Apple retains control over advanced features, privacy architecture, and ecosystem integration.
There is also a forward-looking dimension. Discussions around Messaging Layer Security (MLS) within the IETF suggest a pathway toward standardized end-to-end encryption for RCS in the future. By supporting the Universal Profile rather than Google’s proprietary E2EE extension, Apple positions itself to influence the next phase of secure messaging standards.
In essence, Apple adopted RCS not because it lost strategic leverage, but because the environment changed. Regulation demanded interoperability, public perception demanded better cross-platform experiences, and long-term ecosystem strategy demanded participation in global standards. iOS 18’s RCS support is therefore best understood as a strategic adaptation to a multipolar mobile ecosystem.
Understanding GSMA Universal Profile and How RCS Actually Works
To truly understand RCS, you need to start with the GSMA Universal Profile. RCS itself is not a single app or proprietary service. It is a carrier-driven messaging standard defined by the GSM Association, designed to replace SMS and MMS with an IP-based architecture built on the IMS core network.
In its early years, RCS suffered from fragmentation because each carrier implemented slightly different specifications. To solve this, the GSMA introduced the Universal Profile, a unified technical baseline that ensures interoperability across operators, devices, and countries. iOS 18 adopts Universal Profile 2.4 or later, which is critical for cross-platform consistency.
Universal Profile is the interoperability layer that makes RCS function globally, not just within a single carrier ecosystem.
At a technical level, RCS shifts messaging from circuit-switched signaling channels to packet-switched IP communication. Instead of sending a tiny payload through legacy SMS control channels, devices establish a session over mobile data or Wi-Fi. This enables real-time state synchronization, richer media handling, and dynamic capability negotiation between devices.
Capability negotiation is one of the most important mechanisms in RCS. When two devices initiate a conversation, they exchange information about supported features such as file size limits, read receipts, typing indicators, and group management. The system then selects the highest mutually supported feature set.
| Layer | SMS/MMS | RCS (Universal Profile) |
|---|---|---|
| Transport | Circuit-switched signaling | IP over IMS |
| Session | Stateless | Session-based |
| Media Handling | Embedded, heavily compressed | HTTP file transfer with larger limits |
| Status Updates | Delivery only (limited) | Delivered, displayed, typing indicators |
Unlike MMS, which embeds media directly into the message with strict size caps often in the low megabytes, RCS typically uploads media to a content server using HTTP or HTTPS. The recipient receives metadata and retrieves the file separately. This architectural shift is why image and video quality improves so dramatically under RCS.
Session management is powered by SIP extensions within the IMS framework. When a user starts typing, a composing event is transmitted in near real time. When a message is opened, a displayed status can be sent back to the sender. According to coverage by ITmedia and technical discussions cited by Apple-focused communities, these behaviors mirror modern OTT messaging apps but operate within the carrier-native stack.
It is also important to understand what Universal Profile does not yet standardize. End-to-end encryption between iOS and Android is not part of the current baseline specification. Messages are encrypted in transit via TLS, but server-side handling may differ depending on carrier implementation. This limitation is tied to the ongoing standardization of Messaging Layer Security at the IETF level.
In practical terms, RCS works by combining carrier authentication via phone numbers with IP-native session logic, enabling feature parity with internet messaging apps while remaining deeply integrated into the mobile network.
For gadget enthusiasts, the key takeaway is architectural: RCS is not “SMS with upgrades.” It is a fundamentally different protocol stack that leverages IMS, SIP signaling, HTTP file transport, and standardized capability exchange under the GSMA Universal Profile. That combination is what allows an iPhone and an Android device, on different carriers, in different countries, to negotiate a shared rich messaging experience in real time.
Green Bubbles Reimagined: What Really Changes Between iPhone and Android

For years, the “green bubble” has symbolized more than just a different device. It has represented compressed photos, broken group chats, and a subtle social divide between iPhone and Android users. With Apple’s adoption of RCS in iOS 18, that symbolism remains visually intact—but technically, the experience has changed in meaningful ways.
The color stays green, but the technology behind it is no longer stuck in the SMS era. According to Apple’s announcement and coverage by ITmedia and ケータイ Watch, iOS 18 supports GSMA Universal Profile–based RCS, fundamentally upgrading cross‑platform messaging while preserving the blue-versus-green distinction.
| Feature | Before (SMS/MMS) | Now (RCS on iOS 18) |
|---|---|---|
| Photo/Video Quality | Heavily compressed (KB–few MB) | High resolution, large files (carrier dependent) |
| Read Receipts | Not supported | Supported |
| Typing Indicators | No | Yes |
| Group Management | Limited, fragmented threads | Modern group controls |
The most dramatic shift is media quality. Under MMS, a 4K video sent from an iPhone to Android would often arrive as a blurry, artifact‑ridden clip. RCS changes the transport mechanism itself, using IP-based file transfer rather than legacy carrier gateways. As industry analyses note, this allows substantially larger file sizes and preserves far more detail.
Equally transformative is real-time presence. Cross‑platform chats now show typing indicators and delivery status. This may sound incremental, but it reshapes conversational rhythm. The delay and uncertainty that once defined green-bubble exchanges are largely gone.
Group chats are another quiet revolution. Previously, adding or removing participants in mixed iPhone–Android threads was messy or impossible. With Universal Profile standards, group naming, member management, and synchronized updates become part of the protocol itself.
What does not change is encryption parity. iMessage conversations remain end‑to‑end encrypted by Apple’s proprietary system. Cross‑platform RCS between iPhone and Android, however, does not yet include standardized end‑to‑end encryption under the current Universal Profile specification.
This security distinction is critical. While RCS messages are encrypted in transit via TLS, they may be processed by carrier infrastructure. As discussions in technical forums and reporting on Apple’s MLS roadmap indicate, full cross‑platform E2EE depends on future adoption of Messaging Layer Security standards.
In other words, the green bubble is no longer technologically inferior in media richness or interactivity—but it still signals a different trust model. For gadget enthusiasts, this nuance matters.
The reimagined green bubble is less about exclusion and more about convergence. The wall between ecosystems has thinned, even if it has not disappeared. What changes most is not the color on your screen, but the underlying protocol shaping how billions communicate every day.
Feature-by-Feature Comparison: SMS vs MMS vs iMessage vs RCS
When comparing SMS, MMS, iMessage, and RCS feature by feature, the differences become far more strategic than they first appear. Each protocol reflects a different technological era, from circuit-switched signaling channels to fully IP-based multimedia sessions.
According to the GSMA, RCS was designed to modernize carrier messaging by bringing OTT-level functionality to phone-number-based communication. That goal becomes clear when you line up the core capabilities side by side.
| Feature | SMS / MMS | iMessage | RCS (Universal Profile) |
|---|---|---|---|
| Transport | Cellular signaling / MMS gateway | Apple IP servers | IMS-based IP network |
| Media Quality | Heavily compressed (KB–few MB) | High resolution | High resolution (carrier dependent) |
| Read Receipts | No | Yes (E2EE) | Yes |
| Cross-Platform | Yes | No (Apple only) | Yes |
SMS remains the most universal but also the most limited. With a practical ceiling of 160 characters per message and no native media support, it was never built for modern multimedia communication. MMS extended this with image and audio attachments, yet strict file size limits—often under a few megabytes—result in aggressive compression and inconsistent delivery.
iMessage, by contrast, represents a vertically integrated ecosystem. It offers high-quality media transfer, typing indicators, read receipts, and end-to-end encryption by default. However, its functionality collapses the moment a non-Apple device enters the conversation. The “blue bubble” advantage is therefore technically powerful but platform-bound.
RCS sits in a unique middle position. It preserves phone-number interoperability like SMS while introducing session-based messaging, presence indicators, and large file transfers through IP infrastructure. As reported by ITmedia and Apple’s own implementation notes, iOS 18 supports GSMA Universal Profile standards, enabling high-resolution image and video exchange between iPhone and Android devices.
The most meaningful distinction today is not visual, but architectural. SMS and MMS rely on legacy carrier gateways, iMessage operates within Apple’s closed servers, while RCS negotiates capabilities dynamically between devices over IMS networks.
Security is another differentiator. iMessage uses Apple-managed end-to-end encryption. Standard RCS between iOS and Android currently relies on transport-level encryption rather than universal E2EE, a limitation acknowledged in industry discussions surrounding Universal Profile evolution. For privacy-sensitive users, this nuance matters.
In practical terms, the choice is situational. SMS guarantees reach. iMessage guarantees encryption and ecosystem depth. RCS delivers cross-platform richness without requiring third-party apps. For gadget enthusiasts and power users, understanding these architectural and functional trade-offs is what turns everyday messaging into a deliberate technology choice.
Japan as a Case Study: Carrier Strategies and the Second RCS Wave
Japan offers one of the most revealing case studies for understanding how RCS evolves when carrier strategy, regulation, and platform politics intersect.
Unlike many markets where RCS started slowly, Japan already experienced a first wave in 2018 with the launch of “+Message,” a carrier-led implementation based on GSMA standards. Now, with iOS 18 officially supporting RCS Universal Profile, the country is entering what can reasonably be described as a second RCS wave.
The difference this time is structural: Apple is no longer outside the ecosystem.
From “+Message” to Native iOS RCS
| Phase | Main Driver | Limitation |
|---|---|---|
| 2018 First Wave | Carrier app (+Message) | App install required |
| 2025 Second Wave | iOS native support | Carrier policy differences |
In the first wave, adoption depended heavily on users downloading and actively using the +Message app. Even though NTT Docomo, KDDI, and SoftBank backed it, fragmentation remained. Cross-platform friction persisted because iPhone users stayed inside iMessage.
According to KDDI’s business materials, the expansion of RCS to iOS 18.4 and later versions represents a major ecosystem shift, especially as sub-brands such as UQ mobile and povo are included. This broad inclusion strategy signals that KDDI sees RCS not as an optional feature but as infrastructure.
The second wave differs because it removes the behavioral barrier of app switching.
Carrier Differentiation Becomes the Battlefield
With Apple now supporting GSMA Universal Profile, competitive advantage in Japan shifts from “whether RCS exists” to “how it is packaged and monetized.”
KDDI’s integration of RCS with au Starlink Direct is particularly strategic. By linking satellite connectivity with next-generation messaging, KDDI reframes RCS as a resilience tool, not just a chat upgrade. In rural and disaster-prone regions of Japan, this positioning resonates strongly.
Meanwhile, Docomo’s complexity around billing structures introduces friction. As industry reporting from AI CROSS notes, RCS may be treated as packet communication in many cases, yet certain legacy plans could trigger per-message charges similar to SMS. In a market sensitive to micro-charges, even small ambiguity affects trust.
SoftBank’s approach appears more operational than promotional, guiding users to confirm usage details through My SoftBank. This indicates a lower emphasis on RCS branding and a stronger reliance on ecosystem services such as LINE, where SoftBank maintains strategic ties.
Why Japan Matters Globally
Japan’s smartphone penetration is high, iPhone market share is among the world’s strongest, and carrier branding remains influential. When RCS succeeds under these conditions, it validates the model for other mature markets.
Industry analysis from ITmedia highlights that iOS 18’s RCS support eliminates a long-standing interoperability gap between iPhone and Android. In Japan, where mixed-device households are common, this has immediate network effects.
The second RCS wave in Japan is less about technology adoption and more about ecosystem normalization.
Carriers are no longer evangelizing a new messaging concept. Instead, they are optimizing around pricing clarity, satellite integration, MVNO inclusion, and cross-brand rollout speed. That strategic pivot marks Japan not just as an early adopter, but as a live laboratory for how carrier-native messaging competes in an OTT-dominated era.
For global observers, Japan demonstrates that once Apple joins the standard, RCS stops being experimental and starts becoming default infrastructure.
KDDI’s Aggressive Expansion and Satellite-Integrated RCS
KDDI has taken the most aggressive stance in Japan regarding RCS expansion on iPhone. Following Apple’s support for RCS in iOS 18, KDDI quickly clarified its roadmap for au, UQ mobile, and povo, signaling that it intends to lead—not follow—the transition to IP-based messaging.
According to KDDI’s official disclosures, full-scale support on its main and sub-brands aligns with iOS 18.4 and later, with rollout extending beyond flagship au to online-focused povo and even major MVNO partners using KDDI infrastructure. This multi-brand deployment strategy is particularly notable in a market where MVNO support often lags behind MNO implementation.
KDDI is not treating RCS as a feature update, but as infrastructure. By synchronizing rollout across au, UQ mobile, povo, and KDDI-backed MVNOs, it is accelerating ecosystem-wide adoption rather than limiting benefits to premium users.
The most distinctive element of KDDI’s strategy, however, is the integration of satellite connectivity through “au Starlink Direct.” Unlike conventional RCS, which depends entirely on terrestrial mobile data networks, this approach extends messaging capability beyond coverage areas.
| Feature | Conventional RCS | KDDI + Starlink Integration |
|---|---|---|
| Network Dependency | Mobile data (LTE/5G) | Mobile data + Satellite fallback |
| Coverage | Within cellular area | Mountain, sea, remote zones |
| Use Case Evolution | Urban communication | Everywhere communication |
With compatible models such as iPhone 14 and later, users can send and receive messages even when outside traditional coverage, as long as a clear view of the sky is available. Previously, satellite communication was largely limited to emergency SOS or extremely short text payloads. KDDI’s move signals an ambition to make satellite-assisted messaging part of everyday communication.
This shift has important implications for both disaster resilience and lifestyle mobility. Japan’s geography—prone to earthquakes, typhoons, and mountainous terrain—makes terrestrial network disruption a realistic risk. By integrating RCS with satellite backhaul, KDDI effectively adds a redundancy layer to consumer messaging. For outdoor enthusiasts, maritime workers, or rural residents, this transforms RCS from a convenience feature into a reliability asset.
From a monetization perspective, KDDI’s approach is equally strategic. au users are positioned to access satellite-linked messaging without immediate additional cost, while users from other carriers can subscribe to a dedicated plan reportedly priced at 1,650 yen per month. This dual model simultaneously strengthens customer loyalty and creates a premium connectivity tier.
Industry observers have pointed out that while Apple’s RCS adoption resolves cross-platform fragmentation, it does not by itself solve coverage gaps. KDDI is leveraging RCS as a foundation for geographic expansion, not merely platform interoperability. That distinction matters. It reframes messaging from an app-layer upgrade to a network-layer innovation.
In practical terms, this means KDDI customers are not just gaining higher-quality media exchange with Android users. They are gaining a pathway toward near-ubiquitous reachability. As messaging continues to replace voice calls in everyday communication, the ability to remain connected beyond cellular boundaries could become a decisive competitive differentiator in Japan’s carrier market.
NTT Docomo’s Pricing Complexity and the +Message Factor
NTT Docomo’s RCS rollout sits at the intersection of legacy billing structures and its long-running +Message strategy, and that intersection is not always simple. For power users who closely track carrier behavior, this complexity is more than a minor inconvenience—it directly affects cost predictability and user experience.
Unlike many global carriers that treat RCS purely as packet data, Docomo’s pricing can vary depending on the subscriber’s contract type. According to AI CROSS and Docomo’s own published SMS fee tables, certain plans may apply per-message charges similar to SMS, typically starting from around 3 yen per message, particularly outside standard data-flat environments.
This creates a structural contrast between “RCS as data” and “RCS as message unit,” and users must understand which side of that boundary their contract falls on.
| Usage Context | Billing Treatment | User Risk |
|---|---|---|
| Standard data plan (eximo/ahamo) | Packet data | Low if within data cap |
| Legacy or specific contracts | Possible per-message fee | Unexpected micro-charges |
| +Message app usage | Packet data only | Clearer cost structure |
The +Message factor makes the situation even more nuanced. Launched in 2018 as a carrier-driven RCS implementation, +Message already built a substantial domestic user base before Apple adopted RCS in iOS 18. Docomo clearly defines +Message as free of monthly fees, with only packet communication charges applying, which gives it a perception of transparency.
However, with iOS now supporting GSMA Universal Profile natively, users face a dual-path environment: the default iOS Messages app or the dedicated +Message app. From a technical standpoint, both rely on RCS principles, yet their billing clarity and feature roadmaps differ.
This dual ecosystem can lead to user confusion about which app is generating traffic and how that traffic is billed.
Industry observers, including coverage from ITmedia and carrier documentation, point out that Docomo must balance three priorities: protecting existing +Message investment, complying with global RCS standards, and avoiding customer backlash over billing ambiguity. That balancing act is delicate.
For gadget enthusiasts and heavy communicators, the takeaway is strategic rather than emotional. If you prioritize cost transparency under Docomo, verifying your plan category and understanding whether your RCS traffic is treated purely as data is essential. In some cases, continuing to use +Message may provide clearer expectations, while in others, the native iOS implementation integrates more seamlessly with cross-platform conversations.
Docomo’s complexity is not accidental; it reflects a transitional phase from carrier-controlled messaging to globally standardized interoperability. But during that transition, informed users gain the advantage.
SoftBank, Rakuten Mobile, and the MVNO Ripple Effect
SoftBank and Rakuten Mobile are taking notably different paths in the RCS era, and that contrast is reshaping the MVNO landscape. While both carriers support RCS on iOS 18, their legacy strategies in messaging continue to influence how aggressively they position the standard.
SoftBank has long maintained a flexible messaging stance, partly due to its capital relationship with LINE. Rather than framing RCS as a disruptive shift, the company integrates it quietly into existing billing and support structures. According to SoftBank’s official guidance, users are encouraged to verify how RCS-related data appears in My SoftBank, as charges may be categorized differently depending on the plan.
| Carrier | Messaging Strategy | User Focus |
|---|---|---|
| SoftBank | Plan-based integration | Billing transparency |
| Rakuten Mobile | App-centric ecosystem | Service differentiation |
This operational approach reflects a key reality: for SoftBank, RCS is an infrastructure enhancement rather than a brand centerpiece. The emphasis lies on ensuring that data usage is predictable within existing mobile plans, particularly across SoftBank, Y!mobile, and LINEMO. For tech-savvy users, checking detailed monthly statements remains essential to avoid confusion between SMS fallback charges and packet-based RCS traffic.
Rakuten Mobile, by contrast, built its mobile identity around Rakuten Link, a proprietary super-app offering free domestic calls and messaging. With iOS 18 enabling standard RCS in Apple’s default Messages app, Rakuten users now gain an additional communication layer. As reported by ITmedia and industry observers, Rakuten SIM profiles themselves support GSMA-aligned RCS, even though Rakuten Link operates outside the Universal Profile framework.
This coexistence model is strategically significant. Rakuten no longer needs to rely exclusively on app lock-in to deliver rich messaging between iPhone and Android users. Instead, it can position Rakuten Link for value-added features while allowing native RCS to handle cross-platform chats. For gadget enthusiasts, this means fewer forced app installs and smoother interoperability.
The ripple effect becomes most visible in the MVNO sector. Because MVNOs depend on host MNO carrier bundles, RCS availability typically lags behind primary brands. Community reports surrounding au-based MVNOs such as mineo indicate that access expands only after KDDI formally opens the capability. The same structural dependency applies to SoftBank- and docomo-based MVNOs, where carrier setting updates determine activation timing.
RCS therefore becomes a competitive differentiator not just among major carriers, but across the entire value chain. Early enablement signals technical maturity and ecosystem alignment. Delayed rollout, on the other hand, risks frustrating power users who actively check “RCS Message” status in their input field.
In practical terms, the SoftBank and Rakuten strategies illustrate two contrasting philosophies: incremental integration versus ecosystem-driven expansion. For consumers deeply interested in mobile tech, understanding these nuances clarifies why the same iPhone running iOS 18 can deliver subtly different experiences depending on the SIM inserted. That insight is where the real competitive ripple begins.
Step-by-Step: How to Enable RCS on iPhone and Avoid Hidden Charges
Enabling RCS on your iPhone is not just a toggle—it is a process that depends on your iOS version, carrier profile, and billing structure. If you want the full benefit of high‑quality media and read receipts without unexpected SMS charges, following the correct order matters.
According to KDDI and ITmedia’s coverage of iOS 18, RCS support requires both OS-level compatibility and a carrier configuration update. Skipping either step may cause silent fallback to SMS, which can trigger per-message fees.
Step 1: Confirm iOS Version
Go to Settings → General → About and check your iOS version. You need iOS 18.0 or later. For some Japanese carriers such as au, iOS 18.4 or later is recommended for stable operation.
If your device is not updated, go to Settings → General → Software Update and install the latest available version before proceeding.
Step 2: Update Carrier Settings
Open Settings → General → About. If a “Carrier Settings Update” pop-up appears, tap Update. This step installs the RCS connection profile provided by your carrier.
Without the correct carrier bundle, the RCS toggle may not appear at all. MVNO users should be especially careful, as rollout timing may differ from major carriers.
Step 3: Turn On RCS Messaging
Navigate to Settings → Apps → Messages. In iOS 18, app-specific settings are grouped under “Apps.”
Find “RCS Messaging” and switch it ON (green). If the option is missing, your SIM or carrier may not yet support RCS.
| Checklist | Required Condition |
|---|---|
| iOS Version | iOS 18.0 or later |
| Carrier Update | Latest carrier bundle installed |
| RCS Toggle | Enabled in Messages settings |
Step 4: Verify RCS Status Before Sending
Open a conversation with an Android user. In the message input field, look at the label.
If it says “RCS Message” or “Chat,” RCS is active. If it says “SMS” or “MMS,” your message will be billed under traditional SMS/MMS rules.
Always check this label when roaming internationally. As NTT Docomo’s published SMS pricing shows, SMS can cost several yen domestically and over 100 yen per message abroad.
Step 5: Disable Automatic SMS Fallback
Go to Settings → Apps → Messages and find “Send as SMS.” This option is often enabled by default.
If RCS fails due to weak data connectivity, the iPhone may automatically resend the message as SMS. Turning this option OFF prevents unintended charges and forces the message to fail instead of switching protocols.
Finally, review your monthly billing through your carrier app such as My SoftBank or equivalent account portals. RCS traffic is typically counted as data usage, not per-message billing, but plan exceptions exist—especially on older or corporate contracts.
By completing these steps carefully, you ensure that your RCS experience delivers high-resolution media and real-time features without surprise fees.
Security Reality Check: The Current Encryption Gap Between iOS and Android
The biggest misconception about RCS on iPhone is that it instantly brings iMessage-level security to cross-platform chats. In reality, there is still a meaningful encryption gap between iOS and Android when messages travel over RCS. Understanding this gap is essential if you care about privacy as much as performance.
Today, three different security models coexist across mobile messaging ecosystems. Each offers a different level of protection, and the differences are not cosmetic—they directly affect who can theoretically access your messages.
| Communication Type | Encryption Model | Server Access to Content |
|---|---|---|
| iMessage (iOS ⇄ iOS) | Apple end-to-end encryption | No (Apple cannot read content) |
| Google Messages (Android ⇄ Android) | Signal-based end-to-end encryption | No (when E2EE is enabled) |
| RCS (iOS ⇄ Android) | Transport encryption (TLS) | Potentially yes (at server level) |
The critical distinction lies in the third row. As of the initial iOS 18 rollout and into early 2026, the GSMA Universal Profile specification does not mandate end-to-end encryption. This means that while messages are encrypted in transit between your device and the carrier’s server, they may be decrypted and processed at the server level.
This is not the same as end-to-end encryption. With true E2EE, only the sender and recipient hold the keys necessary to read the message. With transport encryption, intermediaries that operate the servers may technically access message content under certain legal or technical conditions.
Security researchers and industry observers have repeatedly pointed out this distinction. Discussions cited by Apple-focused communities and technical analysts highlight that cross-platform RCS currently does not match the cryptographic guarantees of iMessage or Signal-based Android chats.
Why does this matter in practice? Consider two realistic scenarios. First, lawful interception: because carrier servers may temporarily process readable content, court-authorized requests could potentially access message data. Second, server-side breaches: if a carrier’s infrastructure were compromised, unencrypted-at-rest content could theoretically be exposed.
By contrast, Apple’s iMessage architecture is designed so that even Apple states it cannot decrypt user conversations. Similarly, Google implemented end-to-end encryption in its Messages app for Android-to-Android chats using the Signal protocol, insulating content from server-side visibility.
Apple has publicly aligned itself with the IETF’s Messaging Layer Security (MLS) standard rather than adopting Google’s proprietary Signal-based RCS extension. MLS is designed to support scalable, secure group messaging without vendor lock-in. However, until MLS becomes part of the official Universal Profile and is deployed across both ecosystems, the encryption gap remains.
Bottom line: iOS-to-Android RCS chats today are more modern and feature-rich than SMS, but they are not yet cryptographically equivalent to iMessage or fully encrypted Android chats.
For privacy-conscious users, this creates a practical hierarchy. Highly sensitive information—financial credentials, authentication codes, confidential business data—should still be shared via iMessage (if both parties use iPhone) or dedicated end-to-end encrypted apps such as Signal or WhatsApp.
The good news is that the industry is moving toward standardized encryption rather than fragmented solutions. The bad news is that we are in a transitional phase. And in cybersecurity, transitional phases are where assumptions become vulnerabilities.
If you are a gadget enthusiast who values both cutting-edge features and digital privacy, recognizing this encryption reality is not paranoia—it is informed usage. RCS closes the experience gap between iOS and Android. It does not yet close the encryption gap.
MLS and the Future of End-to-End Encryption for RCS
The most critical unresolved issue in cross-platform RCS is end-to-end encryption. While iMessage uses Apple’s proprietary E2EE and Google Messages applies a Signal-based protocol for Android-to-Android chats, RCS between iPhone and Android currently does not provide standardized end-to-end encryption under the GSMA Universal Profile.
According to reporting from AppleInsider discussions and industry analyses cited by Infobip, messages are encrypted in transit via TLS, but may be processed in readable form on carrier servers. This creates a temporary trust gap that privacy advocates have repeatedly highlighted.
Apple has made it clear it will not adopt Google’s proprietary Signal-based extension for RCS. Instead, it is backing MLS, or Messaging Layer Security, a protocol being standardized by the IETF. This strategic decision is not merely technical but structural: MLS is vendor-neutral and designed for scalable group key management.
MLS introduces advanced cryptographic techniques such as tree-based key derivation to efficiently manage encryption in large, dynamic groups. This matters because RCS is not limited to one-to-one chats. Enterprise messaging, family groups, and community threads may include dozens or even thousands of participants.
| Protocol | Standard Body | Group Scalability | Vendor Neutrality |
|---|---|---|---|
| Signal (Google RCS) | Open source (Signal Foundation) | Moderate | Limited to Google implementation |
| MLS | IETF | High (tree-based key structure) | Fully open standard |
Security researchers have noted that MLS is particularly efficient for asynchronous group messaging, reducing the computational overhead that grows rapidly in traditional pairwise encryption models. For a global standard like RCS, that efficiency is essential.
The GSMA and major ecosystem players are working toward integrating MLS into future versions of the Universal Profile. Once adopted, iPhone-to-Android chats could achieve cryptographic parity with iMessage and encrypted Google Messages.
However, deployment is not instantaneous. Both operating systems, carrier infrastructure, and client applications must support the same MLS specification. Until that alignment occurs, users should assume that highly sensitive data is better transmitted through fully E2EE-confirmed platforms.
The transition to MLS represents more than a patch. It signals a shift toward a globally interoperable, cryptographically modern messaging layer. If successfully implemented, RCS could evolve from a compatibility bridge into a secure universal standard, redefining cross-platform privacy expectations for the next decade.
RCS Business Messaging (RBM): The Next Battlefield Against OTT Apps
RCS Business Messaging (RBM) is emerging as the most strategic front in the fight against OTT messaging platforms. While apps like LINE and WhatsApp have dominated brand-to-consumer communication, RBM brings rich, interactive messaging directly into the native messaging app on iOS and Android.
According to Infobip, Apple’s support for RCS in iOS 18 significantly expands the reachable audience for RBM, because brands can now deliver enhanced messages to both Android and iPhone users without requiring app installation.
RBM transforms the default messaging app into a marketing and customer experience channel—no downloads, no logins, just phone-number-based reach.
Unlike traditional SMS, RBM supports structured and interactive content. Businesses can send rich cards with images and descriptions, carousel formats that allow horizontal browsing, and suggested action buttons such as “Visit Website” or “Call Now.” This enables conversion-oriented communication within a single message thread.
The functional difference between SMS and RBM is not incremental but architectural.
| Feature | SMS | RBM (RCS) |
|---|---|---|
| Media Quality | Highly compressed | High-resolution images & video |
| Interactivity | Text only | Buttons, carousels, rich cards |
| Brand Verification | No | Verified sender identity |
| Analytics | Limited delivery info | Read & engagement tracking |
Verified sender profiles are particularly important. RBM allows businesses to display official brand names and logos, reducing phishing risk and increasing trust. This is a structural advantage over SMS, where spoofing remains a persistent issue.
In Japan, the competitive landscape is unique because LINE has long served as the default business messaging platform. However, RBM offers two decisive advantages: universal reach via phone numbers and zero dependency on third-party app ecosystems.
For transactional messaging—such as OTP authentication codes, delivery updates, and reservation reminders—RBM can replace SMS while offering richer UX. AI CROSS notes that pricing structures may vary by carrier, but when treated as data communication, RBM avoids per-message SMS fees under flat-rate plans.
Strategically, this shifts bargaining power. Brands no longer need to rely solely on closed platforms with algorithmic timelines or subscription-based official accounts. Instead, they can engage users inside the operating system’s native interface.
The real battlefield is not feature parity—it is ownership of customer touchpoints. With iOS 18 enabling RCS support, RBM gains immediate scale across previously fragmented ecosystems.
If MLS-based end-to-end encryption becomes standardized in future RCS updates, RBM could also strengthen its position in sectors requiring higher trust, such as finance and healthcare. Until then, its strongest use cases remain marketing campaigns, commerce interactions, and service notifications.
RBM is no longer an experimental extension of SMS. It is positioning itself as a carrier-backed alternative to OTT dominance, leveraging native reach, verified identity, and interactive design to compete where it matters most—inside the default messaging experience.
What This Means for Global Users: Practical Recommendations and Future Outlook
The adoption of RCS on iPhone is not just a technical update; it directly reshapes how global users should think about everyday messaging. For the first time, cross-platform communication between iOS and Android delivers high-resolution media, typing indicators, and modern group management without relying on third-party apps.
According to reporting by ITmedia and coverage of Apple’s iOS 18 rollout, this shift effectively removes the long-standing quality gap that defined SMS/MMS exchanges. That change has practical consequences for travelers, remote teams, families, and businesses operating across borders.
From a practical standpoint, users should evaluate three dimensions: compatibility, cost control, and privacy posture. Each varies depending on carrier policies and regional implementation, especially in markets like Japan where carrier-led RCS services such as +Message coexist with Apple’s standard Messages app.
| Scenario | Recommended Action | Why It Matters |
|---|---|---|
| Frequent iOS–Android media sharing | Enable RCS and confirm carrier update | Preserves high-resolution photos and videos |
| International travel | Disable “Send as SMS” fallback | Avoid unexpected roaming SMS charges |
| Sensitive conversations | Use iMessage or Signal instead | Current cross-platform RCS lacks E2EE |
Cost management is especially critical. As carrier documentation from NTT Docomo and SoftBank indicates, RCS is generally treated as data traffic, but SMS fallback may incur per-message fees. In roaming situations, those fees can increase significantly. Disabling automatic SMS fallback prevents silent downgrades that trigger billing surprises.
Privacy expectations also need recalibration. While iMessage remains end-to-end encrypted and Google’s Android-to-Android RCS uses its own encryption layer, cross-platform RCS under the current GSMA Universal Profile does not yet provide standardized E2EE. Discussions around MLS at the IETF level suggest progress, but until broad implementation occurs, users should avoid transmitting financial credentials or confidential documents over iOS–Android RCS threads.
Looking ahead, the integration of RCS with satellite services—such as KDDI’s Starlink Direct initiative—signals a future where messaging resilience improves even in off-grid environments. As networks evolve toward 5G Standalone and eventually 6G architectures, messaging will increasingly operate as an IP-native, globally interoperable layer rather than a carrier-fragmented utility.
For global users, the strategic takeaway is clear: treat RCS as the new default bridge between ecosystems, but remain intentional about security settings and carrier details. The messaging landscape is converging, yet informed configuration still determines whether you gain seamless convenience—or hidden friction.
参考文献
- KDDI Business:What is RCS? How to Use It on iPhone and Android
- ITmedia PC USER:iOS 18 Adds RCS Support to the Messages App
- au:RCS | Services and Features
- NTT Docomo:+Message (Plus Message) | Services and Features
- Infobip:Apple Supports RCS on iOS 18
- Michael Tsai Blog:RCS in iOS 18
