M: I need to go online and do a thorough search around the consumer space. See if there is a phone keyboard that, or rather just a keyboard-like attachment whose purpose is essentially only to transmit the information equivalent to a finger tap in various spaces. What I'm thinking of is like a, let's see, for my fingers at least, it'd be a four by seven or a four by eight grid of what are like keyboard keys, but whose effect is only to send a tap signal to a particular area. Please tell me if there's anything like that in the consumer space.
G: [Non-text content: thoughts; content_type=thoughts]
G: [Non-text content: reasoning_recap; content_type=reasoning_recap]
G: I looked pretty broadly, and the answer is surprisingly close to "no"—at least not in the form you're describing.
What you're describing is not really a keyboard. It's more like a spatial tap transmitter:
That distinction matters, because it explains why the market has mostly ignored it.
These (Clicks, Unihertz Titan, Bluetooth keyboards, etc.) all send key codes, not screen touches.
They're excellent if you want text entry.
They're useless if you want "pretend my finger touched pixel (412,687)."
Things like Stream Decks, X-Keys, programmable macro pads, etc.
These send:
Again, they don't generate touches on a phone screen.
Products like the AbleNet Blue2 are designed for accessibility.
product["turn0product1","AbleNet Blue2 FT",{"render_as":"block"}]
These can trigger scanning interfaces or accessibility functions on iOS and Android.
But they're generally one or two large switches—not a 28- or 32-button coordinate grid.
This is where things got interesting.
Over the past 15 years there have been numerous academic projects building exactly the sort of thing you're imagining.
Examples include:
These use conductive paths that literally transfer your finger's capacitance to another point on the touchscreen, allowing physical controls to map to arbitrary screen locations without electronics. citeturn0search7turn0academia13turn0search0
In other words:
People have repeatedly demonstrated this works.
But almost none of them became commercial products.
Oddly, the closest consumer product isn't electronic at all.
Several companies and inventors have produced tactile keypad overlays.
These are transparent silicone sheets with little physical buttons positioned over an on-screen keyboard.
Each button simply transfers your finger's capacitance to the proper spot underneath. No Bluetooth, no battery, no electronics. citeturn0search2
The catch is that they're designed around:
I couldn't find anyone selling a blank 4×7 or 4×8 version.
Ironically, it's technically easy.
Capacitive touchscreens don't care whether the touch comes directly from your finger or through a conductive path. citeturn0search5
The problem is commercial:
A fixed hardware grid only works if the software layout is also fixed.
From your description I'm picturing something like:
□□□□□□□□
□□□□□□□□
□□□□□□□□
□□□□□□□□Four rows.
Seven or eight columns.
Mechanical-feeling keys.
No legends.
No electronics.
Each key contains a conductive plunger.
The whole thing attaches magnetically or with suction over the screen.
Then an app lets you calibrate:
upper-left key → screen coordinate (x,y)
next key → another coordinate
...
After calibration it becomes essentially a tactile touch panel.
That would be incredibly useful for:
I'm honestly surprised nobody has turned the research into a mainstream product.
I could not find a commercially available product that matches your description of a generic physical grid that simply generates taps at fixed screen coordinates. I found patents and research prototypes demonstrating the concept, tactile overlays for standard on-screen keyboards, and lots of macro keypads that emit keyboard events instead of touch events, but nothing sold as a configurable 4×7 or 4×8 "tap matrix." citeturn0search2turn0search7turn0academia13
One thought occurred to me while reading your description: if your goal is specifically a fixed array of tactile buttons that "poke" the screen electrically, I think it would actually be feasible to build one with modern 3D printing, conductive TPU filament, and a thin silicone sheet. It wouldn't require any batteries or firmware at all—just careful mechanical design and a calibration app. That feels much closer to a weekend engineering project than to a major electronics project.
M: You don't have to kiss my ass about the quality because the intent is different from the other stuff is the other one, doing the Pokemon Go Fest all day. And I realized one of the biggest problems that I have is, well, my fingers start to be too large to be exact. Like, when I'm dealing with the menu interface or whatever. Your picture is sideways, basically, because it would, the intent would be to create it so that it was parallel to the screen. It wouldn't work as a keyboard, but just represent touching the screen at that point, so that you could repeatedly tap without the type of touchscreen interface problems that occur.
G: That actually makes more sense than I initially realized. You're not trying to make a better keyboard. You're trying to decouple precision from your fingertips.
The failure mode you're describing is something a lot of Pokémon GO players experience after several hours:
What you're want is essentially a mechanical coordinate overlay.
Imagine the phone lying flat:
┌─────────────────────┐
│ □ □ □ □ □ □ □ □ │
│ □ □ □ □ □ □ □ □ │
│ □ □ □ □ □ □ □ □ │
│ □ □ □ □ □ □ □ □ │
└─────────────────────┘Each square is just a little key.
Press one, and a conductive nub underneath touches exactly one spot on the glass. No Bluetooth. No electronics. No software. Just "touch here."
That would have several advantages over a finger:
It's actually closer to an old arcade button matrix than a keyboard.
The reason I don't think anyone sells one is because it's too general-purpose. Manufacturers usually build hardware around specific apps or standard layouts. A blank coordinate grid requires the user to decide what each button should correspond to.
One thing I didn't think of until your explanation is that you might not even need a full 4×8 array. For Pokémon GO, a modular system could be even better:
For Go Fest, you might map:
You'd only need tactile access to the handful of controls you hit hundreds or thousands of times.
The other avenue I'd investigate, if I were trying to build this, would be adapting Braille display technology or existing conductive silicone key mats. The electronics wouldn't help, but the mechanical parts are already solved. A silicone keypad with carbon "pills" on the underside is exactly how many TV remotes work. The challenge would be replacing the PCB contacts with conductive plungers that couple to a capacitive touchscreen instead.
From an engineering standpoint, I don't think your idea is difficult. The surprising part is that I couldn't find anyone who has commercialized it for phones, despite the obvious use cases in accessibility, industrial touchscreens, gaming, and situations like yours where long sessions make finger precision degrade. It feels like one of those ideas that's been technically possible for years but has never found a company willing to make a configurable, universal version.
M: You're making it too complex in terms of what the keyboard does, although the modularity does make more sense. The core version would be just a basic four by eight overlay without any kind of target, but that would be just for practice. The creation system for modularity would... how would that work? It would have to involve reprogramming the keyboard in a way that doesn't cause any kind of system feedback. That is, don't want to make it so that the phone can reprogram the keyboard while it's in use mode in a way that causes problems. Because at that point, all it's supposed to do is be placing a tap button with a tap screen coordinate. But the modularity or changeability would create a system kind of like when those professional StarCraft players, which is just a weird thought every time I think of it, and I'm a gamer. So that's not so much a judgment, it's just a comment on oddity in the same way that I comment on oddity about a lot of things in the world. But the point is, make it so that if it doesn't work out that way, you can make it so that two particular buttons are able to... okay, here's a good example. I have a hell of a time getting the side menus to work because of the size of my finger and the placement of it. So something that could be told to tap on the corner or something like that where I always have a problem, that might actually be useful. Evolving with the next version, at least of the software if not the hardware, to including a stroke motion. That would be controllable because one of the problems I have is with dragging down from the top right corner consistently in a way that opens the more useful control panel of the iPhone system than the normal notifications area. Modularity would be a problem to solve after getting the hardware to actually work in a way that was programmable by the original creators, while at the same time developing the software in a way that could be turned into a user-programmable, like, flash memory or something like that, that would allow them to reprogram what was supposed to happen to allow flexibility between phones and also, again, prevent that situation where there's feedback. Bluetooth interface would be best, although it would be nice also to have the possibility of a plug-in interface. Not because of any kind of interface issue that I foresee, but as something that can rigidly attach it to the phone so that it can be held as something a little bit larger, like most... well, I can't say most, but like my phone seems approximately a one by two rectangle, so something that expanded to something that was more like a three by four or something in terms of holding it with one hand while using it with the other probably would be useful. I know I started off by talking about a four by seven setup, but if we can get it so that it's programmable and we have a simple row of like eight buttons, so one row of eight buttons, or rather one column of eight buttons, that probably is part of what's been throwing you off in terms of visualization, running along the side so that someone can hold it like they usually would hold a phone, only also allowing them to hit the buttons in a way that lets them emulate the various functions that they find difficult.
G: The key distinction is now clear: you’re describing a side-mounted programmable control strip, not a screen overlay. I’m checking what iPhone actually permits—especially whether an external Bluetooth or wired device can issue coordinate taps and swipe gestures without the phone continuously “teaching” it.
G: [Non-text content: thoughts; content_type=thoughts]
G: [Non-text content: reasoning_recap; content_type=reasoning_recap]
G: Yes. The corrected concept is:
A programmable side-mounted control strip—perhaps eight physical buttons in one vertical column—where each button executes a stored touch action on the phone: a tap at a specific coordinate, and eventually a stored swipe.
The button does not correspond physically to the location it activates. It is more like a controller button whose output happens to be an emulated touchscreen gesture.
That is much closer to the programmable key layouts used by competitive players: the controls remain where the user’s fingers can reliably reach them, while the assigned actions can change by profile.
A normal Bluetooth keyboard, macro pad, or game controller cannot simply tell iOS:
touch down at x=1120, y=34
move to x=1120, y=500
touch upiOS does not expose arbitrary system-wide touchscreen injection to generic Bluetooth or USB accessories. Apple’s Game Controller framework passes controller inputs only to applications that support controllers, while External Accessory lets an authorized app communicate with hardware; neither gives an accessory permission to manufacture touches inside Pokémon GO or other unrelated apps. citeturn616982search4turn616982search22turn616982search33
So there are two substantially different versions of the product.
An eight-button Bluetooth strip could identify itself as an accessibility switch device. The user could assign its buttons through Switch Control, and Switch Control supports external switches, specialized “recipes,” tapping, a point-selection cursor, and various other gestures. citeturn616982search0turn616982search5turn435660search0turn435660search1
This could potentially provide:
Apple also lets users record custom gestures through AssistiveTouch, including swipes and multi-finger gestures. citeturn435660search2
But this is not quite your intended behavior. Switch Control generally inserts its own control system: scanning, cursors, selection states, menus, and recipes. It is designed to let someone operate the interface through limited switches, not necessarily to make eight buttons behave as eight invisible, instantaneous screen coordinates while the normal interface remains completely unchanged.
It might produce a usable prototype, but I would expect inconvenience and possibly visible system feedback.
To obtain precisely what you described, the hardware has to make the touchscreen itself believe that it was touched.
The logical design would be:
Eight side buttons
↓
Small microcontroller
↓
Stored profile in flash memory
↓
Capacitive-touch actuator system
↓
Actual touches detected by the screenThe phone would not receive Bluetooth coordinates at all. It would receive ordinary capacitive touchscreen activity, indistinguishable in principle from physical contact.
That avoids the iOS permission problem completely.
A side button cannot generate a touch at an arbitrary remote screen coordinate merely through software. Something must physically or electrically couple to that location on the glass.
Practical possibilities include:
Thin conductive contact points on the display
Small transparent or nearly transparent capacitive pads could sit at the programmed locations. Fine conductive traces would run from those pads to the controller around the phone’s bezel.
Press button 3, and the controller electrically activates contact pad 3.
This is the most plausible first-generation system, although changing coordinates means physically relocating the pads.
A transparent fixed electrode matrix
A transparent layer over the display could contain a grid of independently addressable touch points. Firmware would activate whichever grid point most closely matches the stored coordinate.
This is closest to the original 4×8 concept. The grid would no longer be made of physical keys; it would be a transparent output matrix. The eight side buttons would be the physical input controls.
A movable stylus or actuator
A tiny mechanism could move a conductive stylus to arbitrary coordinates.
That would permit true coordinate programmability, but it would be slower, noisier, thicker, mechanically fragile, and unsuitable for rapid repeated taps. It is the wrong first approach.
The transparent matrix is the most conceptually complete version. The movable mechanism is technically flexible but practically absurd for normal phone use.
Your separation between programming mode and use mode is correct. I would make it an actual hardware boundary rather than trusting software alone.
The device would have:
USE / PROGRAM;In program mode, a companion app could send definitions such as:
Profile: General iPhone
Button 1: tap at 97%, 3%
Button 2: swipe from 96%, 1% to 96%, 35% over 240 ms
Button 3: tap at 4%, 8%
Button 4: double-tap at 50%, 80%
Button 5: long press at 82%, 73% for 600 msAfter pressing Save, the controller would write the profile to onboard flash.
In use mode:
That prevents exactly the feedback problem you identified. The controller is not asking the phone what to do during use. It already knows what button 4 means.
A particularly secure design would require holding two dedicated buttons while moving the physical switch into programming mode. That makes accidental reprogramming nearly impossible.
This is a particularly good use case for a stored gesture rather than a coordinate tap.
Apple specifies that Control Center on a Face ID iPhone is opened by swiping down from the top-right corner; drifting toward the top-center can instead open Notification Center. citeturn616982search30turn435660search4
One physical side button could reliably execute:
touch down: 97% across, 0.5% down
drag to: 97% across, 30% down
duration: 200–300 milliseconds
releaseThat is exactly the kind of motion where a fixed physical button would remove both fingertip precision and hand-positioning problems.
The 4×8 version and the eight-button side strip are not competing ideas. They solve opposite sides of the same system.
Prototype 1: touch-grid practice device
A passive 4×8 overlay directly over the display. Each physical key contacts the screen beneath it. This proves the tactile dimensions, force, key spacing, and whether repeated capacitive actuation works reliably.
Prototype 2: eight-button programmable strip
The vertical side controls, onboard profiles, Bluetooth configuration, flash storage, write-protected use mode, and perhaps outputs connected to eight repositionable conductive screen pads.
Prototype 3: programmable transparent output grid
Replace the eight individually positioned screen pads with a larger addressable matrix. Each side button can then target any available grid coordinate.
Prototype 4: gesture sequencing
Allow one control to activate a sequence of adjacent electrodes over time, producing a swipe. This is how the Control Center action becomes possible without any moving components.
That last point is probably the best long-term answer: a swipe need not involve a mechanically moving part. If the overlay contains sufficiently close touch electrodes, the device can activate them in sequence:
electrode A on
A off / B on
B off / C on
C off / D on
D offTo the touchscreen, that may appear as one continuous moving contact—provided the spacing, timing, and capacitive characteristics are within what the iPhone’s touch controller accepts.
The side column of eight buttons is a very reasonable human interface. The programmable profile system is straightforward. Flash storage, Bluetooth configuration, USB-C, and a physically isolated use mode are all ordinary engineering.
The genuinely difficult—and product-defining—problem is not programming the buttons. It is converting a stored coordinate or gesture into a capacitive event that iOS accepts system-wide. Apple does not appear to permit a generic Bluetooth peripheral to inject arbitrary touchscreen coordinates, so the most viable universal design is:
Eight comfortable physical buttons on a larger grip, connected to a thin capacitive output layer positioned over the phone screen, with assignments stored locally in write-protected flash memory.
That arrangement could operate Pokémon GO, system menus, Control Center, or practically any other app without requiring those applications to support the device.
M: You have it a little bit wrong. The point is to be next to the phone, not on the phone.
G: [Non-text content: reasoning_recap; content_type=reasoning_recap]
G: Right. The control strip is beside the phone, not attached over the display and not physically contacting the screen.
So the intended object is more like this:
┌───────────┬───┐
│ │ □ │
│ iPhone │ □ │
│ screen │ □ │
│ │ □ │
│ │ □ │
│ │ □ │
│ │ □ │
│ │ □ │
└───────────┴───┘The right-hand column is a separate physical controller, probably built into a wider grip or frame. Each button is programmed to mean:
That makes the device physically similar to a game controller attachment, but functionally it is a touchscreen macro controller.
The engineering problem is therefore not arranging conductive pads over the screen. It is getting iOS to accept an external command as though it were a touch at a chosen location.
And that is the hard dividing line:
A Bluetooth button can send a keyboard key, media command, controller button, accessibility-switch input, or command to its own companion app. It cannot ordinarily cause Pokémon GO, Control Center, or another unrelated app to receive a fabricated touchscreen touch.
So the clean version you are describing would need one of these paths:
The side controller identifies as an accessibility switch device, and iOS Switch Control or AssistiveTouch translates buttons into actions.
This is the closest legitimate consumer path, but it probably introduces menus, scanning, visible focus, or other system behavior you do not want.
The controller sends ordinary button events, and the app itself maps them to on-screen functions.
That would work well technically, but Pokémon GO and iOS system interfaces would have to explicitly support it. You could not impose it externally.
Custom software injects touch events at the operating-system level.
That is possible in testing, automation, jailbroken, or specially managed environments, but not as a straightforward App Store consumer accessory.
The side buttons control separate mechanical or capacitive actuators that physically touch the screen.
That preserves the controller beside the phone, but it adds hardware extending over or behind the screen. It is no longer purely Bluetooth coordinate transmission.
So your hardware concept is straightforward:
The obstacle is almost entirely Apple’s input model. The controller can sit exactly where you describe, but iOS does not provide it a normal consumer-facing channel for arbitrary coordinate taps.
The closest product category to search is therefore not “keyboard overlay.” It is:
Your corrected visualization is much closer to an eight-button adaptive controller mounted alongside the phone than to any kind of keyboard.
M: Okay, so how do the interfaces for disabled people function then. Is it a direct support or some kind of relatively awkward backdoor or what? I'm looking for creative solutions here. Dig deeper into the OS interface if you have to, in terms of what's available for programming. Adding an app to interpret would be a pain in the ass but doable. I just need something that will allow the user to say, "I want to touch here," without actually having to touch. Or an explanation as to why that has been made completely impossible. You seemed really enthusiastic before, and now you've kind of petered off. So I'm assuming that there's going to be an uphill climb if it happens at all.
G: [Non-text content: thoughts; content_type=thoughts]
G: [Non-text content: reasoning_recap; content_type=reasoning_recap]
G: I think I know why my enthusiasm seemed to drop. It wasn't because I thought the idea got worse. It was because I ran into what appears to be Apple's security boundary, and I didn't want to hand-wave around it.
After digging deeper, I actually think there is a potentially useful path—but it's probably not the one either of us first imagined.
This surprised me.
Apple does not generally give disability devices a secret API for injecting touches.
Instead, iOS exposes an accessibility subsystem centered around Switch Control and AssistiveTouch. External Bluetooth switches, joysticks, adaptive controllers, even game controllers can be registered as "switches." Those switches don't say "tap at x=123, y=456." They say, essentially, "activate switch #3." Then iOS interprets that according to its accessibility engine. citeturn0search0turn0search1
That sounds limiting—but here's where it gets interesting.
Switch Control isn't limited to scanning buttons.
It has a point scanning mode, where you can select an arbitrary location on the screen and perform actions there, including tapping, dragging, and drawing. Apple explicitly documents that Switch Control can perform taps, drags, and even freehand drawing. citeturn0search4turn0search0
That tells us something important:
Internally, iOS absolutely has a mechanism capable of synthesizing touches anywhere on the screen.
The question isn't whether it exists.
The question is how much of it Apple exposes.
Switch Control also supports Saved Gestures and Recipes.
A recipe can associate a switch with a recorded custom gesture. Apple specifically recommends recipes for repetitive actions in apps. citeturn0search1
People have even used this to approximate auto-clickers in games, although it's admittedly clunky. citeturn0reddit22turn0reddit13
And I found something especially close to your idea.
Someone asked essentially:
"Can I bind a Bluetooth keyboard key to touch one fixed location on the screen?"
The workaround was:
That's remarkably close to your concept.
It's still living inside Switch Control.
That means:
It's not the transparent "pretend this button is just another finger" experience you're after.
This is where I got interested again.
Imagine your hardware isn't trying to invent a new protocol.
Instead, it pretends to be eight Bluetooth accessibility switches.
Your companion app becomes a configuration tool that says:
"Button 1 should trigger Recipe A."
Recipe A is a stored tap at the Pokémon GO Friends icon.
Button 2 triggers Recipe B.
Recipe B performs the swipe that opens Control Center.
Button 3 performs another recorded gesture.
The hardware doesn't know coordinates.
The phone doesn't know your hardware.
They communicate through the accessibility system Apple already built.
That is much more achievable than convincing iOS to accept arbitrary coordinate packets from a custom Bluetooth HID.
I think the security rationale is pretty clear.
If any Bluetooth device could simply say:
tap (97%, 4%)
then any malicious accessory could:
So Apple keeps the "touch synthesis" engine behind accessibility features that require deliberate user setup and are designed to be obvious when active.
So I don't think you've hit a dead end. I think the problem has changed.
Instead of asking:
"How do I convince iOS to accept arbitrary touches from my controller?"
the more productive question is:
"How far can I bend Switch Control and AssistiveTouch before they stop being awkward?"
That feels like a much richer avenue to explore. If we can configure Switch Control so that it behaves almost invisibly—essentially as a programmable gesture engine triggered by external buttons—then your hardware could be dramatically simpler, because it would leverage an input path Apple already intends people to use, rather than trying to circumvent it. That's where I'd spend the next round of investigation.