I have an iPhone in my pocket, an old Android with my home SIM at the family house in another country, and a second Android with an Uzbek SIM I use for marketplace OTPs.
For two years I kept solving the same problem the wrong way. SMS from a bank or a delivery service would arrive on one of those Androids, and I had to either ask someone to read it to me, or VPN into a remote desktop, or worse, ship the SIM back to me.
What I actually wanted was simple: every SMS, on every device I owned, in real time, without moving SIM cards.
The shape of the solution is a multi-device viewer. One Android phone holds the SIM and pushes every incoming SMS to a small backend. Every other device (iPhone, iPad, second Android, browser tab) subscribes to that backend and gets a native push the moment the SMS arrives. The SIM never moves.
This post walks through the architecture, the trade-offs against forwarding to Telegram or email, and a 5-minute setup using SMS Sender 24, the tool I built to scratch this itch.
One availability note before the walkthrough: the Android transmitter and web dashboard are live today. The iOS viewer flow is working in early access while the public App Store listing is being finalized, so if you are reading this before the App Store button is live, use the launch promo at the end and I will send the current access path.
TL;DR
Use a multi-device viewer when the SIM has to stay in one Android phone, but the people reading the SMS are somewhere else.
- Android keeps the SIM and acts as the transmitter.
- iPhone, iPad, Android viewer, and web subscribe as viewers.
- Each viewer can see the whole workspace or only one phone's stream.
- Viewer pairings are unlimited on every plan.
- Telegram/email/webhook still work as channels, but they are not the same thing as per-device access.
| Approach | Best for | Where it breaks |
|---|---|---|
| Multi-device viewer | SMS on iPhone, iPad, Android and web, with per-phone scope | Needs a backend and a paired transmitter |
| Telegram forwarding | One person or one shared group chat | No per-user or per-phone access control |
| Email forwarding | Archival and audit trail | Slow, noisy, no native mobile inbox |
| Tasker or MacroDroid | One local phone, one owner | Hard to manage for teams or multiple devices |
| Custom backend | Total control | You own every edge case |
Why "forward to Telegram" stops working at two people
The classic SMS forwarder ships every incoming SMS to a Telegram chat. That works perfectly until two things happen at once.
First, two people need to see the same SMS stream but you do not want them to see each other's chats. Second, you want one person to see SMS from a specific phone only, not from every phone in your workspace.
A Telegram chat has no per-user filter. You either invite a person to the chat (they see everything), or you do not (they see nothing). For a small family or a one-phone setup this is fine. For a small team that shares a corporate Android, an agency that holds five client SIMs, or a developer who has two personal numbers and one work number, it falls apart.
Email forwarding has the same problem with extra latency. Webhooks let you build whatever you want, but now you maintain a service.
The multi-device viewer approach treats each device as a real subscriber with its own scope.
What "multi-device viewer" means architecturally
Three pieces.
Transmitter. An Android phone with the SIM. Runs a small app that listens for incoming SMS, packs them up, and pushes them to the backend. One transmitter per SIM. You can have many transmitters in one account.
Backend. A multi-tenant pub/sub server. Each incoming SMS triggers two independent fan-outs. The first goes to "channels" (Telegram, email, Slack, Discord, webhook). The second goes to "viewers" via APNs (iOS) or FCM (Android) push.
Viewers. Any device in receive-only mode. iPhone app, iPad app, second Android in viewer mode, a browser tab. Each viewer has its own pairing with three knobs: can_send (almost always false for viewers), can_view (true), and scope.
The same backend can also trigger outgoing SMS from an API or webhook, but I am intentionally keeping that out of this walkthrough. The narrow problem here is viewing SMS from multiple physical phones without moving SIM cards.
The scope is the interesting one.
-
scope = tenant: the viewer sees SMS from every transmitter in the workspace. -
scope = device: the viewer is locked to one transmitter's stream. SMS from any other transmitter is invisible to this viewer.
That second scope is the unlock. It lets you give your accountant a viewer pairing that only sees the corporate SIM, not your personal one. It lets a freelancer hand a single client a viewer pairing that only sees that client's SMS.
Viewer pairings do not count against your device quota. Free plan = 1 transmitter + unlimited viewers. That pricing pattern alone fixes most of the awkward "we share one login" workarounds I see teams using.
Walk-through: 5 minutes to your first SMS on iPhone
This is what I did to set up my own family inbox, replacing the "forward to a Telegram group" hack I had been running.
Step 1: register a workspace. Sign up at smssender24.com with a Google or email account. You get a free plan and an empty workspace.
Step 2: pair the transmitter. Install the Android app on the phone holding the SIM. Open the web dashboard, click "add device", scan the QR code with the Android app. The phone starts forwarding SMS to your workspace within a second.
Step 3: pair the iPhone as a viewer. Install the iOS viewer app if you have access to the current build. Open the web dashboard, click "add device" again, this time pick scope "tenant" (full workspace). Scan the QR with the iOS app camera. Done.
Now send a test SMS to the SIM in the Android transmitter. The iOS app shows the message in real time, and a lock-screen banner pings the iPhone the same way Apple Messages would.
Step 4: pair an iPad. Repeat step 3 with an iPad. The same iOS app, the same workspace, a second QR pair. The iPad starts getting the same push notifications independently of the iPhone.
Step 5 (optional): add a second workspace. Tap the active connection in iOS Settings → Connections, then "add another phone". Scan a QR from a different workspace (a client account, a family-shared account, a side project). The iOS app now holds two workspaces at once. Tap to switch. No re-login, no two apps.
That last step is the one that surprised me the most. I expected to install five copies of the iOS app for five clients. Instead it is one app, five Connections, instant switching.
Advanced: per-phone delegation with scope=device
Say you run a small team. One Android phone holds the corporate SIM. Three managers each need to see SMS from that specific corporate SIM, but you do not want them to see SMS from any other transmitter you might add later (personal numbers, the founder's number, the test SIM).
When you generate the pairing QR for each manager, pick scope "device" and point it at the corporate transmitter. The manager's iOS or Android viewer app gets SMS from that one phone, and only that one phone, even if you add ten more transmitters tomorrow.
Behind the scenes the backend writes a device_filter_id on the viewer's API key, and the push fan-out checks it before sending. Same backend, same workspace, surgical isolation.
This single feature replaced a Google Sheets + Zapier rule I was using to extract OTP codes from a shared inbox. It saved me 40 minutes a week and removed two moving parts.
Where this approach is weaker
I want to be honest about the cases where this is not the right tool.
Single phone, single person, single Telegram chat. Just use one of the free open-source APKs like SMS2Tg. You do not need any of the multi-device machinery. Smaller blast radius, no SaaS dependency.
Regulated environments where SMS cannot leave a controlled network. The backend is a third-party cloud service, even if I never read your SMS. If your compliance policy says zero third-party processing, self-host the open-source forwarders or write a custom Android collector and your own backend.
You want zero data anywhere. SMS Sender 24 stores SMS for a retention window so the viewer apps can show history. Configurable down to 7 days, but not zero. If your bar is zero, this is not the tool.
Pricing note
Free plan: 100 SMS per month, 1 transmitter, unlimited viewer apps. The "unlimited viewers" part is the one I see people miss. If you only need the multi-device viewer angle and your total SMS volume is light, the Free plan is the entire product for you.
Pro and Business plans raise the SMS count and the transmitter count. The viewer count stays unlimited on every plan.
Launch offer: 6 months of Pro for 5 minutes of feedback
I just opened a launch promo: anyone who signs up and takes a 5-question survey gets 6 months of Pro for free. No card, no auto-renewal, no "first N only" limit. That is $54 of value at the Pro rate, mostly because I would rather pay you in product than do my own bug-hunting.
The five questions: what you tried to do, how you used to solve it, what worked, what is missing, what you would have typed into Google to find this. That is the whole deal. The form is anonymous if you want, and Pro extends automatically the moment you submit.
Details: smssender24.com/en/launch-promo.html. Free plan stays free regardless, so even without the survey you can pair an Android and an iPhone and try the multi-device viewer at no cost.
What I am improving next
The next improvement I care about is making important SMS easier to separate from routine ones.
On iOS, that means better push categories and optional time-sensitive notifications for things like OTP codes or server alerts. Apple lets Time Sensitive notifications break through Focus and Notification Summary, but users can turn that behavior off, so I would not treat it as a guaranteed emergency channel.
On the backend, it means better delivery visibility: which viewer devices received the push, which channel failed, and whether a webhook needs to be replayed. Boring logs beat clever abstractions when an SMS code is missing at the worst possible moment.
If you give it a try, I read every email at support@smssender24.com and I am the person who replies. The most useful feedback is "I tried to do X and could not figure out Y". That is the data I cannot get from analytics.
