Twitter Digits Is Gone: Phone-Number Sign-In for Mobile Apps in 2026

Twitter Digits, the free "sign in with your phone number" SDK, shut down on September 30, 2017, and Firebase phone authentication took its place. In 2026, adding SMS sign-in to a mobile app is still straightforward, but it's never free and it attracts fraud. Firebase is the closest successor and the simplest option for Flutter, iOS and Android. Twilio Verify suits apps that want a dedicated verification service. Whatever you choose, limit which countries you send codes to before you launch.

This page replaces the Digits pages and Fabric docs that older tutorials still link to. Digits dates come from its own blog and Twitter's, read through the Wayback Machine. Prices come from each vendor's pricing page and were checked on October 17, 2026.

Disclosure: App369 is my studio, and I build most apps with Flutter and Firebase, which appear below. No vendor on this page paid for a mention.

What happened to Digits, and when

Some Digits features didn't carry over to Firebase, including delivering the code by voice call and the optional account PIN, according to Fabric's migration guide.

What the old addresses do today

Checked on October 17, 2026:

• get.digits.com and its blog no longer resolve. The Wayback Machine has copies.
• digits.com now belongs to an unrelated accounting software company, so old "Digits" links send readers somewhere confusing.
• docs.fabric.io/apple/digits/ redirects to the Firebase home page.

The 2026 options compared

Prices were checked on October 17, 2026. SMS prices vary by destination country, so check your own markets.

Firebase is also rolling out Phone Number Verification, which confirms the number with the mobile carrier instead of sending an SMS. Its documentation currently covers Android only and carrier coverage is partial, so treat it as an addition to SMS rather than a replacement for now.

SMS pumping: the cost nobody budgets for

SMS pumping, also called toll fraud, is when bots hit your "send code" endpoint with numbers in countries where SMS is expensive, and someone shares the revenue from that traffic. Twilio's guide describes it plainly: both attacks inflate traffic "with the intent to make money". It can run up a large bill overnight on an app with no real users.

What the vendors recommend, in order of impact:

1. Allow only the countries you serve. In Firebase, set the SMS region policy. In Twilio, set geo permissions. In AWS, use the sandbox until you go live, then SMS Protect.
2. Verify the app or the person before sending. Firebase does this with Play Integrity, silent push and reCAPTCHA. Supabase supports CAPTCHA. On your own backend, add a CAPTCHA before the send call.
3. Rate-limit per IP address, per phone number and per device, with growing delays between retries. Twilio notes that rate limits slow attackers rather than stop them, so combine them with the steps above.
4. Watch codes sent versus codes verified. A sudden drop in the verified share, or traffic from a country you don't serve, is the alarm. Google's pricing page suggests blocking regions with very low verification rates.
5. Set a billing alert. Google Cloud (which handles Firebase billing), AWS and Twilio all offer spend alerts, for example Twilio usage triggers. Put one in place before launch.

How to choose

1. You're building with Flutter or Firebase already. Use Firebase phone auth. It's the direct successor to Digits, and the Flutter guide covers the full flow. Upgrade to Blaze, set the region policy, and add test numbers for development.
2. Your backend isn't Firebase and you want one bill for verification. Twilio Verify. The per-verification price includes fraud protection, and you only pay the $0.05 fee when a code is confirmed (the per-SMS fee is billed on every send).
3. Your app runs on Supabase. Use its phone login with Twilio or another supported provider, and turn on CAPTCHA before launch.
4. You're on AWS already. Cognito with End User Messaging, plus SMS Protect.
5. Your users can receive email or use passkeys. Consider making SMS optional. Email magic links work in Firebase and Supabase, passkeys are standard on Apple and Google devices, and Supabase's passkey support is still marked experimental. Fewer SMS sends means less cost and less fraud.

Migration checklist for an app still built around Digits

1. Find the old SDK. Search the project for Digits, Fabric and TwitterKit. If they're still there, sign-in has been broken since 2017 or the code is dead weight.
2. Pick the new provider from the table above, and create a test project first.
3. Map existing users. If your backend stored Digits user IDs, match accounts by phone number instead, and make sure the number is stored in E.164 format (+15615551234).
4. Set the fraud controls before launch: a country allow list, rate limits, app verification and a billing alert.
5. Add test numbers so development and app review don't send real SMS.
6. Write the consent text. Tell meers an SMS may be sent and that standard rates apply. Firebase's docs also ask you to tell users their number is sent to Google for spam and abuse prevention.
7. Test on real devices, including a phone without Google Play services and a slow network, before you release.

Need a hand?

If phone sign-in is stuck on one bug, such as codes that never arrive, a reCAPTCHA loop or a verification that fails on iOS only, the App Fix Ticket is a fixed-price option. The Diagnosis is $450 in 3 business days and the Fix is $1,200 in 5 business days. It covers Flutter, Swift, Kotlin and Firebase among others, and it doesn't cover rewrites. For a full sign-in rebuild, get in touch and I'll scope it.