A panel + video component + mobile extension works on desktop and has never once appeared in the Twitch Android app. What makes this hard to debug is that there is no failure anywhere: our asset server logs no request from the phone, so the app is not fetching the mobile view and failing. It is not asking.
Setup
Extension declares Panel, Video Component and Mobile.
Mobile Viewer Path is mobile.html. The file exists, loads Twitch’s helper, and renders standalone.
Tested in Local Test (assets over an HTTPS tunnel, publicly reachable) and then in Hosted Test (zip uploaded, Twitch serving the assets).
Icons uploaded on the version: 24x24, 100x100, 300x200 discovery image, and the 1024x768 screenshot.
Device: Google Pixel, Android, the Twitch app (not mobile web).
What we have tried
Activated as a Video Component: works on desktop, nothing on mobile.
Activated as a Panel: works on desktop, nothing on mobile. (An extension can only occupy one slot at a time, so these were tried separately.)
Force-closed and reopened the app after every change.
Deactivated and re-activated the extension on the channel.
Moved Local Test → Hosted Test and re-uploaded.
The evidence that the app never asks:
In Local Test our asset server served 76 requests while testing, every one of them from the desktop browser. Not a single request from any mobile user agent, at any point, for mobile.html or anything else. The same is true of the backend.
Questions
Is there anything besides the Mobile type, the mobile viewer path and the version’s icon assets that gates whether an extension appears on mobile?
Does the slot an extension is activated in affect mobile visibility? We have seen it stated that extensions only surface as panels on mobile, but a panel activation made no difference here.
Is there a propagation delay after enabling Mobile on a version that is longer than an app restart?
Happy to provide the version configuration or logs.
Solved, and it was ours rather than anything on Twitch’s side. Writing it up properly because the symptom is so misleading.
The phone was signed in to a different Twitch account from the desktop browser. The desktop was the account that owns the extension, which can see it in test by default. The phone was a personal viewing account, which was not on the Access tab’s testing allowlist. So the app did exactly the right thing: showed nothing, requested nothing, said nothing.
What makes this hard to spot is that “correctly hidden” and “broken” are indistinguishable from outside. There is no error, and the asset server logs no request either way which is precisely the evidence I opened this thread with, and I had read it as proof that something was failing.
The thing that gave it away was your last question: whether extensions not created by me loaded on the device. They did but every one of them was a released extension on someone else’s channel. Released means visible to everyone; in test it is the developer’s own account plus whatever is on the Access tab. Once that asymmetry was the question, the answer took two minutes.
Confirmed working now on the Android app and on an iPad, in Local Test over a tunnel, rendering as a panel that replaces chat exactly as you described.
Two corrections to things I had written down as fact, in case anyone else has them from the same forum threads I did:
Local Test reaches mobile perfectly well. I had it noted that it might not.
An extension does not need to be activated in a panel slot to appear on mobile. It is the desktop slot plus mobile, and on mobile it renders panel-style whatever slot it occupies. Ours is a video component on desktop.
For anyone finding this later: the allowlist is Extensions console → the extension → Manage → access, and it takes numeric user ids, not names.
This may also be what the unresolved thread at /t/64814 ran into: same symptom, same states, and released extensions visible on the same phone throughout.
The icon was not showing at all. No icon above chat, nothing to tap, no blank page. Which is why the asset log was so misleading: there was nothing to white page, because the app never had reason to ask for anything.
And you are right about the Access tab. I wrote “it takes numeric user ids, not names” in my last post and that is simply wrong. Typing a name autocompletes against accounts, stores the id and shows the name back, exactly as you said; typing an id resolves to the same name. Either works.