My current method of detecting if someone is mobile or PC. It seems to work fine but for some people when they reset, the button is no longer visible.
local uis = game:GetService("UserInputService")
local touchEnabled = uis.TouchEnabled
local keyBoardEnabled = uis.KeyboardEnabled
local ismobile = false
if touchEnabled and not keyBoardEnabled then
ismobile = true
elseif keyBoardEnabled then
ismobile = false
end
button.Visible = ismobile
local Button = script.Parent
local UserInput = game:GetService("UserInputService")
if UserInput.TouchEnabled then
Button.Visible = true
else
Button.Visible = false
end
Not a good way. This would give the mobile UI to Touchscreen PC users. It was a nightmare to play on my old touchscreen laptop in 2016 because of this.
local Button = script.Parent
local UserInput = game:GetService("UserInputService")
if UserInput.TouchEnabled and not UserInput.KeyboardEnabled then
Button.Visible = true
else
Button.Visible = false
end
Adding on to this solution, you can also use UserInputService:GetLastInputType() to get either Enum.UserInputType.Keyboard or Enum.UserInputType.Touch. You can also check changes in input type with the event version.
This sounds like it might be a problem with the code, not with getting the input type/device type.
@Forummer That code is the same as mine. I just have it set a bool first so I can more easily use the bool for other purposes.
For testing purposes I simplified my entire script to this.
local uis = game:GetService("UserInputService")
local touchEnabled = uis.TouchEnabled
local keyBoardEnabled = uis.KeyboardEnabled
local ismobile = false
local button = script.Parent
if touchEnabled and not keyBoardEnabled then
ismobile = true
elseif keyBoardEnabled then
ismobile = false
end
button.Visible = ismobile
NOTE: this glitch happens like 1/10 times he reseted
What I circled is the small test UI with the script above
Results:
Before breaking
If you’re looking for code that (in theory) works reliably, this should work:
local uis = game:GetService("UserInputService")
local ismobile = false
local button = script.Parent
local function onInputTypeChanged(inputType)
if inputType == Enum.UserInputType.Touch then
button.Visible = true
else -- Only need button if touch input, controller, keyboard, etc. don't need it
button.Visible = false
end
end
onInputTypeChanged(uis:GetLastInputType())
uis.LastInputTypeChanged:Connect(onInputTypeChanged)
As far as your code, you can factor it down to:
if keyBoardEnabled then
ismobile = false
elseif touchEnabled then
ismobile = true
end
button.Visible = ismobile
The problem probably has to do with using KeyboardEnabled or how your Instances are set up.
Edit:
Refer to buildthomas’s post below. Use the first code block instead of KeyboardEnabled/TouchEnabled 
The only issue with using just touchEnabled is that there are plenty of devices that are a PC but also have touchscreens.
I saw a post a while back, but I can’t find it. However, I have the code they provided saved:
local function getplatform()
if (GuiService:IsTenFootInterface()) then
return "Console"
elseif (UserInputService.TouchEnabled and not UserInputService.MouseEnabled) then
--touchscreen computers now have touchenabled so make sure to check for lack of mouse too
--also, not all phones/tablets have accelerometer and/or gyroscope
local DeviceSize = workspace.CurrentCamera.ViewportSize;
if ( DeviceSize.Y > 600 ) then
return "Mobile (tablet)"
else
return "Mobile (phone)"
end
else
return "Desktop"
end
end
local Platform = getplatform()
(Put in a local script)
It would be best if you return an Enum instead of a string.
It works the same either way. There aren’t enums for different types of mobile devices, so it’s a bit of an unnecessary micro optimization.
Yeah. I’d recommend the first code block, that dynamically responds to different input types.
Why would
UserInputService.TouchEnabled and not UserInputService.MouseEnabled
work and
UserInputService.TouchEnabled and not UserInputService.KeyboardEnabled
not work?
If the mobile device doesn’t have a mouse shouldn’t it also detect to not have a keyboard?
Maybe the on screen keyboard counts?
Seeing some absolutely cursed suggestions in this thread.
Don’t try to detect “platform” and then make your game change based on that.
You should be looking at last used input mode and screen size of the device, and use changed events on the input mode and screen size to react dynamically to the user’s device. You cannot dumb down all possible device configurations and user preferences to a single platform value.
API:
You should never use TouchEnabled, KeyboardEnabled or GamepadEnabled to make static UX decisions on startup. The user can change input modes, connect or disconnect devices, or have a device connected they aren’t currently using, all of which can lead to misprediction if you are checking these values only once on game startup.
These API are noob traps. Refer to the post above.
I just tested by killing my alt while it was on the mobile keyboard typing and the GUIs stayed. This only seems to happen to one of my testers when they die with a 10% chance. Since that I’ve reported this to bug-support. I’ve even made a game to isolate the problem to just that code I posted above and my tester still has the problem.
I also printed it with these results. The second print is when the mobile user dies with the keyboard open.
print(“MOBILE DETECTION”)
print(touchEnabled)
print(keyBoardEnabled)
In the meantime I will use the MouseEnabled instead of the KeyboardEnabled.
Hm that’s weird. I’ve been using local IsMobile = not UserInputService.KeyboardEnabled and I didn’t have any problem at all.
I see, so that dynamic system would be better, but why would using TouchEnabled and KeyboardEnabled all of a sudden not work after a respawn of the player?
I’ll try converting my system to something more dynamic using something like this. I still think there is a slight bug within using TouchedEnabled
and KeyboardEnabled though.
Until someone hooks up a keyboard to a mobile device and then suddenly finds themselves not able to use touch UI in your game, because it’s hidden because you think they’re not on a mobile device. 
You could file a bug report with a clear repro, but IMO, these API should just be deprecated because they’re noob traps. It’s better to steer people towards the dynamic approach.
