Facebook Login moves to open beta with one-tap sign-on on Android and web

Meta moved Login with Facebook into open beta on 27 August 2026, bundling three separate authentication changes into one release: a one-tap prompt for returning users on Android and the web, a silent token refresh for Limited Login sessions on iOS, and a default that routes iOS logins through the native Facebook app instead of an in-app browser. PPC Land reported the release, which Meta published on its Meta for Developers blog under the byline of Zoe Lieberman and organised around a promise of "fewer steps and less maintenance". Each of the three features carries its own SDK requirement, and one of them alters how an app behaves automatically after an upgrade.

Facebook Login occupies an unglamorous spot in the marketing stack. The button rarely draws attention in a planning meeting, yet it governs how many people arrive inside an app as authenticated, addressable users rather than anonymous sessions. Changes to its mechanics reach registration rates, first-party data collection, and the measurement signals that feed campaign optimisation. A release filed under developer convenience is worth reading from the marketing side of the room, and this one contains a default that can move a number before anyone notices it moved.

Fast App Switch is the change that can happen without a decision

Fast App Switch sends people into the native Facebook app on iOS to complete a login rather than opening an in-app browser. Integration requires the iOS SDK at version 18.1.0 or later and adding fbauth2 to the app's Info.plist under LSApplicationQueriesSchemes, which is the standard iOS pattern for declaring the URL schemes an app intends to query. So far this reads like any other opt-in feature. The part that matters for a live product sits in the version history: Fast App Switch was opt-in behaviour in SDK 18.0.2 and became active by default from 18.0.3 onward.

The consequence is specific. An app that declares fbauth2 in its Info.plist without setting the appSwitch property explicitly will begin switching eligible logins to the Facebook app after an SDK upgrade, with no code change written by the developer. Nobody chose it, nobody reviewed it, and nothing in the diff shows it. The behaviour arrives attached to a dependency bump that a release note is likely to describe as housekeeping.

Treat that as a release-management problem before treating it as a feature. A login flow change is a conversion-rate event: it changes the number of screens between intent and account, it changes whether the person leaves your app during the flow, and on iOS it introduces a dependency on whether the Facebook app is installed and signed in on that device. Any of those can move registration completion in either direction. Meta published no data comparing the app-switch flow against the in-app browser flow, so there is no external figure to plan against. That makes measurement the only honest way to find out what it did to your product.

A short list of things worth confirming before or immediately after an SDK bump:

• Which Facebook iOS SDK version your current build ships, and whether the next bump crosses 18.0.3.
• Whether Info.plist declares fbauth2 at all. If it does not, the switch cannot occur, and adding it later is the moment the behaviour turns on.
• Whether appSwitch is set explicitly anywhere on the LoginConfiguration object or the FBLoginButton component. Silence now means the default, and the default changed.
• Whether login start and login completion are instrumented as separate events, so a drop-off that appears between them is visible rather than inferred from a lower signup total.
• Whether the release note for that build mentions the login flow. If a dependency upgrade changes user-facing behaviour, it belongs in the note that a product owner and a growth lead actually read.

Teams that prefer the browser-based flow set appSwitch: .disabled on the LoginConfiguration object or on the FBLoginButton component. Either setting is defensible. The point is that it becomes a decision with an owner instead of an inheritance, and that whoever owns the signup funnel knows which flow shipped and on what date.

Single Sign On brings a one-tap prompt to Android and the web

Single Sign On presents a one-tap prompt to people who are already signed in with their Facebook credentials on a device. Instead of completing a full login flow, an eligible user confirms with a single tap, which Meta described in the announcement as "cutting the friction out of returning logins". The feature targets returning users specifically, so its reach depends on how much of your audience already has a signed-in Facebook session on the device they use to reach you.

Adoption differs by platform. On Android the integration requires updating the SDK to version 18.3.0 or later, calling the SSO API, and adding Facebook to the queries block in the app's AndroidManifest.xml. That queries entry is not Meta-specific bureaucracy. It reflects the package visibility rules Android has enforced since version 11, under which an app declares upfront which other packages it intends to detect on a device. Miss the declaration and the detection quietly fails rather than throwing something loud.

On the web, developers update the JavaScript SDK and add fedCM: true to the FB.init() call. One flag, one line, and a different underlying mechanism.

Meta published no lift figure for the one-tap prompt. There is no conversion benchmark, no before-and-after registration rate, and no claim about how many returning users qualify as eligible. Anyone quoting a number for one-tap login improvement is quoting something that did not come from this announcement.

FedCM is the quiet part of the web change

Adding fedCM: true places Facebook's web prompt on FedCM, the Federated Credential Management API through which browsers mediate federated sign-in without third-party cookies. Under that model the browser renders the account prompt itself and contacts the identity provider only after the person consents, which removes the redirects and cookie reads that older federation flows depended on. The specification travels through the W3C's Federated Identity Working Group, and browser support began with Chrome 117.

The API has a track record worth knowing. Google shifted Sign in with Google onto FedCM starting in April 2024, replacing the cookie-based mechanism behind One Tap and Automatic Sign-In. FedCM then outlived most of the machinery it shipped alongside: when Chrome retired the bulk of the Privacy Sandbox advertising APIs on 17 October 2025 after low adoption, FedCM stayed in the browser. With this open beta a second major consumer identity provider moves its web prompt onto the browser-mediated model, one configuration flag at a time.

That is the part with implications past a single button. Social login was one of the quieter dependencies on cross-site cookies, and the direction of travel is that the browser, not the site and not the identity provider, becomes the party that renders the account chooser and holds consent. For anyone maintaining a web sign-up path, it means the login prompt is now governed partly by browser policy rather than entirely by your own front end. The announcement said nothing about which other providers plan to follow, and nothing about timelines beyond the open beta itself.

Limited Login Data Refresh removes a class of support tickets

The third feature answers a constraint created by Apple's privacy architecture, so the timeline matters. Apple released App Tracking Transparency with iOS 14.5 on 26 April 2021, requiring apps to obtain permission before tracking activity across other companies' apps and websites. Facebook began showing consent screens under the framework during 2021, and Meta estimated in the fourth quarter of that year that Apple's changes would cost the company on the order of 10 billion US dollars.

Meta introduced Limited Login in January 2021, building it on the OpenID Connect standard so that the fact a person used Facebook Login inside an iOS app is not applied to ad personalisation or measurement. It gives privacy-constrained users a working path into an app. It also created a maintenance problem, because Limited Login "does not use a long-lived access token", so the profile and authentication token received at login "can grow stale over time". Until this release the only remedy was pushing the user back through a complete re-authentication, which is friction arriving at the moment an app wants none.

Limited Login Data Refresh removes that step. The SDK now silently refreshes the active session as an app returns to the foreground, keeping the Profile.current and AuthenticationToken.current values fresh, and a new refreshLimitedLogin() API triggers the same refresh on demand. Existing integrations keep signing users in through LoginConfiguration with .limited tracking, and the refresh layers on top of the existing session. The requirements are iOS SDK 18.1.0 or later, with iOS 13.0 or later needed for the silent refresh paths.

The staleness symptoms Meta named are small and easy to misfile: a profile picture that no longer matches, a display name lagging behind a change the person made on Facebook, and an authentication token a backend declines to accept. In a support queue those look like three unrelated bugs, and each gets its own ticket, its own reproduction attempt, and its own inconclusive close. They share one mechanism. Keeping the values synchronised without user interaction retires the category rather than any single report, which is why Meta framed the feature as maintenance reduction rather than new capability.

What each feature requires

The three features do not share a single minimum version, so an app can be eligible for one and not another. Requirements as stated in the announcement:

Why a login button is a measurement story

The reason to care about any of this from a media seat is that authenticated users and anonymous sessions are not the same asset. A person who completes a social login gives you a stable identifier, a durable record you can attach behaviour to, and in many cases an email address you can match later. A person who bounces off a login screen gives you a session that ends when the cookie does. The gap between those two outcomes compounds through everything downstream: the size of your first-party audience, the quality of the conversion signal you send back to ad platforms, and how much of your remarketing is built on something more durable than a browser identifier.

That is why a flow change belongs in the same conversation as your Facebook ads reporting rather than in a backlog nobody outside engineering reads. If registration completion moves the week an SDK ships, the effect shows up in your cost per registration long before anyone connects it to a dependency upgrade, and the instinct will be to blame creative or bidding. Keeping a dated log of login-flow changes next to your paid social reporting is a cheap way to avoid diagnosing a platform change as a media problem.

The same applies to analytics configuration. If login start and login completion are not distinct events in your GA4 setup, an app-switch flow that loses people between the two is invisible: you see fewer registrations and no explanation. And on the web side, the FedCM prompt is rendered by the browser, so what your sign-up page controls is everything around the prompt, not the prompt itself. That narrows what design changes can fix and widens what instrumentation has to catch.

What the announcement did not say

Several things a marketer would want are absent from the source, and inventing them is worse than doing without:

• No rollout percentages. Open beta was announced on 27 August 2026 with no statement of how many apps or users are covered.
• No availability detail by country, so whether the one-tap prompt behaves identically in Thailand and elsewhere is not addressed.
• Nothing about whether open beta has a general availability date, or what would move it there.
• No data on conversion impact for any of the three features, in either direction.
• No benchmark or lift claim for one-tap login. None was published, and the absence should be stated rather than filled with a figure borrowed from another platform.

What this means for Thai marketers

Facebook remains a primary front door for consumer apps and commerce in Thailand, which makes social login a larger share of account creation here than a global average would suggest, and makes an iOS default change correspondingly more consequential. There is no public benchmark for Thai social-login completion rates, no reliable local figure for what share of iOS users have the Facebook app installed and signed in, and no Thai-specific data in this announcement. Derive your own numbers instead of borrowing someone else's: pull your last complete month of login starts and completions, split by platform, and treat that as the baseline against which any SDK change is judged.

Two practical implications follow for a Thai product team. First, the Fast App Switch default assumes the native Facebook app is present and signed in. On a device where it is not, the flow falls back, and the experience differs from the one your team tested on a staff phone that always has it installed. Test with a signed-out device and a device without the app before deciding the flow is fine. Second, Limited Login staleness has a visible surface in Thai apps that display a member name or picture: a name that never updates after the person changes it on Facebook reads as a broken account rather than a stale token, and it generates a support conversation in Thai that costs more to resolve than the underlying bug ever did.

Coordination is the cheap part here. The team that upgrades the SDK and the team that reports on cost per registration are usually not the same team, and the login flow is the seam between them. A dated line in a shared change log, naming the SDK version and the date it shipped, is enough to keep a platform default from being misread as a media result for a whole month.

Frequently asked questions

Does the Fast App Switch default affect my app automatically?

Yes, if your app declares fbauth2 in Info.plist and does not set the appSwitch property explicitly, because the feature became active by default from SDK 18.0.3 onward after being opt-in in 18.0.2. In that configuration eligible iOS logins begin routing through the native Facebook app after an SDK upgrade with no code change by the developer. Setting appSwitch: .disabled on the LoginConfiguration object or the FBLoginButton component restores the browser-based flow.

Which SDK versions do the three features need?

Single Sign On needs Android SDK 18.3.0 or later, while Limited Login Data Refresh and Fast App Switch both need iOS SDK 18.1.0 or later, with iOS 13.0 or later required for the silent refresh paths. The web side of Single Sign On has no version number attached in the announcement beyond updating the JavaScript SDK and adding fedCM: true to the FB.init() call. Because the minimums differ, an app can qualify for one feature and not another.

What is FedCM and why does it matter for the web prompt?

FedCM is the Federated Credential Management API, through which browsers mediate federated sign-in without third-party cookies, with the browser rendering the account prompt itself and contacting the identity provider only after the person consents. Support began with Chrome 117, the specification travels through the W3C's Federated Identity Working Group, and Google moved Sign in with Google onto it starting April 2024. When Chrome retired most Privacy Sandbox advertising APIs on 17 October 2025, FedCM remained in the browser.

Did Meta publish any conversion data for one-tap login?

No. The announcement carried no rollout percentages, no country-level availability detail, no general availability date for the open beta, and no conversion figures for Single Sign On, Limited Login Data Refresh or Fast App Switch. Any lift number attached to this release did not come from the source, so the only reliable measurement is your own before-and-after on your own registration funnel.

Does Limited Login Data Refresh change what data an app receives?

No. It refreshes the session that already exists, keeping Profile.current and AuthenticationToken.current current as the app returns to the foreground, and existing integrations continue signing users in through LoginConfiguration with .limited tracking. Limited Login itself is unchanged: it is built on OpenID Connect and was introduced in January 2021 so that use of Facebook Login inside an iOS app is not applied to ad personalisation or measurement.

If your app or site uses Facebook Login and your last SDK upgrade went in without a note about the login flow, that is the first thing to check this week. If you want a second pair of eyes on how login changes are landing in your registration and campaign reporting, the team is happy to take a look.