The Button Problem: What Apple Actually Lets You Press

The Note That Sat There For Six Months

On the 3rd of March 2026, a voice note went into a capture inbox and then sat there, untouched, for almost half a year. It was short. It was the kind of thing you say out loud while you are doing something else, and the transcription came back slightly mangled, the way voice notes always do.

Things to ponder hardware wise. Can an external device control shortcuts on the iPhone, or is that just completely locked out in the Apple world, as I assume it is? Research this.

Two days earlier, another note had gone in about the same problem from a different angle. That one asked about a waterproof version. Something that could live in a shower, survive the steam, and still take a press from a wet hand. The person recording it noted, correctly, that this would be an interesting build challenge.

Both notes are still open. Nobody researched it. And the assumption baked into the first note, the one that says "as I assume it is", turns out to be wrong. Not slightly wrong. Wrong in a way that has been wrong since 2021, sitting in plain sight inside an Apple settings menu that almost nobody opens, because it was not built for people who want to press buttons. It was built for people who cannot press buttons.

That is the story. A door into iPhone automation that exists only because Apple was legally and morally obliged to build it for somebody else, and which anyone with 30 dollars and a screwdriver can walk straight through.

Why Everyone Assumes It Is Locked

The assumption is reasonable, and it comes from a real place. Apple has spent 18 years making it clear that third-party hardware does not get to reach into iOS and pull levers. There is no equivalent of a global hotkey. There is no daemon you can run in the background that listens for a signal and fires an action. If you write an iPhone app, the system can and will suspend it the moment the screen goes dark, and you get a handful of narrow exceptions for music playback, navigation, and voice over internet calls.

For accessories specifically, the wall was even higher. For years, if you wanted a physical device to talk to an iPhone over a wire or over classic Bluetooth in any meaningful way, you needed to be part of Apple's accessory licensing program, which meant an authentication chip in your product and a business relationship with Cupertino. That chip has an actual part number and an actual cost, and it is the reason a certified cable used to cost 25 dollars while a generic one cost 4.

So the mental model most people carry is simple. Apple decides what buttons exist. Apple ships an Action button on some models and a Back Tap gesture on others, and if you want anything beyond that, you are out of luck, because the phone is a sealed box that only Apple gets to drill holes in.

Here is what that model misses. Bluetooth Low Energy changed the accessory rules, because low energy devices never needed the authentication chip in the first place. And more importantly, there is an entire category of input that iOS must accept from any hardware, from any manufacturer, with no licensing and no permission, because refusing it would make the device unusable for a large number of people. That category is keyboards.

A keyboard is not an accessory in the sense Apple polices. A keyboard is an input method. And once your device is a keyboard, iOS stops asking who made you.

A Door Built For Someone Else

In 2021, at its developer conference, Apple gave a session on a feature called Full Keyboard Access. The framing was explicit and it was about motor accessibility. There are people who cannot reliably use a touchscreen. Tremor, limited range of motion, paralysis, chronic pain. For those users, a touchscreen phone is a device that mostly ignores them. Full Keyboard Access was the answer: turn it on, and every single element on screen becomes reachable with keys. A blue focus ring moves around the interface. Space activates whatever is highlighted. Tab and a letter jumps you somewhere specific. You can drive the entire phone without touching it once.

Buried inside that feature is a settings screen called Commands. It lists every action Full Keyboard Access knows how to perform, and it lets you rebind any of them to a key combination of your choosing. Go back. Go home. Open Control Center. Take a screenshot. Standard accessibility fare.

And then, scrolling down past the system commands, there is a section that lists your shortcuts. Every automation you have ever built in the Shortcuts app, sitting there, waiting to be assigned a key combination.

That is the whole trick. You highlight your shortcut, you press some absurd combination that no real keyboard would ever produce by accident, something like control plus option plus command plus shift plus the letter G, and iOS writes it down. From that moment on, any keyboard that sends those five keys at once causes that shortcut to run. Not to open the Shortcuts app. Not to ask permission. To run.

It does not matter what the keyboard is. It does not matter that the keyboard is a plastic puck with one physical button and no keys at all, lying about its nature to the Bluetooth stack. iOS sees a keyboard, iOS receives a keystroke, iOS looks up the binding, iOS runs the shortcut. The accessibility framework does not care about your motives.

There is a small cost, and honesty requires naming it. Turning on Full Keyboard Access changes how your phone behaves. You get that blue focus ring wandering around the interface, and it has an auto-hide timer, 15 seconds by default, which you can turn off or lengthen. Some people find it visually noisy. And a keyboard being connected means the on-screen keyboard sometimes declines to appear when you want to type, which is the classic annoyance of leaving a Bluetooth keyboard powered on in a bag. These are real trade-offs, not deal-breakers, and there is a neat workaround that comes up later.

The Swedish Button

The most polished version of this trick comes from a company about 600 kilometres south of here.

Shortcut Labs was founded in 2013, out of the KTH Innovation incubator in Stockholm. Four founders, a hardware idea, and a name that turned out to be almost embarrassingly on the nose given where this story goes. Their product was a small round plastic button, roughly the size of a large coin, with a Bluetooth radio inside and a coin cell battery. You stick it to a wall or a car dashboard or a bedside table. You press it, and something happens on your phone.

They took it to Indiegogo and raised around 800,000 dollars, roughly 8 times what they asked for, which at the time broke the record for Nordic crowdfunding campaigns. They called it Flic, and they marketed it as the world's first smart button. Second generation, Flic 2, went to Kickstarter and pulled 636,556 dollars from 5,046 backers. A later product, a twisting dial called Flic Twist, raised 683,551 euros. By the early 2020s the company had shipped over half a million buttons.

The interesting part is not the money. It is what the product had to become in order to survive.

The original pitch was elegant and slightly doomed. The button talks to your phone, your phone runs an app, the app does the thing. Except the app is subject to every iOS background restriction described earlier, so the reliability was never quite there, and Apple kept tightening the screws. Over the years Flic added more paths out. They added a hub, so the button could talk to something that was not a phone at all. They joined the smart home standards body. They added support for Apple's home automation framework, so a press could trigger a home automation rather than a phone app.

And they added, quietly, a mode where the button pretends to be a Bluetooth keyboard.

That mode exists so the button can send a keystroke to a computer. But point it at an iPhone with Full Keyboard Access switched on, bind that keystroke to a shortcut, and you have a physical button, sitting on a wall, that runs arbitrary automation on a phone in your pocket. A company called Shortcut Labs ended up shipping the most reliable way to trigger Apple Shortcuts from hardware, and it works through an accessibility feature, not through their own app.

There is also a cruder route that predates all this, and it still works. Flic can be told to open a web address. Apple's Shortcuts app registers a custom address scheme, so a specially formatted link runs a named shortcut directly. It is less clean, because opening a link means the phone has to be awake and unlocked and it visibly jumps into the Shortcuts app, but it requires no accessibility settings at all. Two doors, both open, both slightly ugly, both entirely functional.

The Cheapest Button In The World

Before anyone starts soldering, there is a solution that costs about 30 cents and has no battery, no radio to pair, and no firmware to maintain.

Apple's Shortcuts app has supported near field communication tags as an automation trigger for years. You buy a sticker with a passive chip in it. There is no power source. When you hold your phone near it, the phone's own radio energises the chip, reads its unique identifier, and fires whatever automation you bound to that identifier. Apple's documentation is blunt about the mechanism: apart from the unique identifier, the contents of the tag are ignored entirely. You are not storing data on it. You are storing a name that means "this one".

For a lot of capture problems, this is the right answer and everything else is over-engineering. A tag on the dashboard. A tag by the front door. A tag on the bathroom mirror. Tap, and a shortcut runs that starts a recording, or files a timestamp, or opens the note field. The tag costs nothing, never runs out of battery, survives being wet, and can be laminated or embedded under a tile.

The catch is the gesture. You have to bring the phone to the tag and hold it there for a moment, top edge first, which means you must be holding the phone. That is fine at a doorway. It is useless in a shower, where the entire point is that the phone is somewhere else and your hands are covered in soap. The tag solves the "mark this moment" problem only when the phone is already in your hand, which is precisely the situation where you could have just used the phone.

Still. Two thirds of the button ideas people sketch out are solved by a sticker, and it is worth being honest about which third is not.

Everything Else Apple Hands You

There is a longer list of triggers than most people realise, and several of them are stranger than the hardware route.

Back Tap has been in iOS since the iPhone 8 era. You tap the back of the phone twice or three times, the accelerometer notices the pattern, and a shortcut runs. It costs nothing, works through a case, and is genuinely the fastest capture trigger available if the phone is in your hand. Its weakness is false positives. Set your phone down firmly on a table and it may decide you meant it.

The Action button, on newer Pro models, is a real physical switch dedicated to exactly this, and it will run any shortcut you assign. Apple Watch will do the same from the wrist, which for a person who is often outdoors and often not holding the phone is a serious contender. On iPad, squeezing a Pencil runs a shortcut, which is a wonderfully specific piece of engineering.

Then there are the automation triggers, and this is where recent versions get useful. Shortcuts has long been able to fire when a specific Bluetooth device connects. That alone is a hardware button, if you squint: power on a small Bluetooth device, the phone notices the connection, the automation runs. It is slow and it only works once per connection, but it works.

More recently Apple added an automation that fires specifically when a keyboard connects, along with two others: one that fires when you take a screenshot, and one that fires on an incoming notification and can filter on keywords inside the notification content.

That last one deserves a moment, because it quietly changes the shape of the problem. If an automation can fire on the content of a notification, then anything that can send your phone a notification is now a trigger. A small device on your own network, sending a push through your own service, becomes a button without ever pretending to be a keyboard, without pairing, and without Full Keyboard Access being on at all. The device does not need to be near the phone. It does not need to be in the same country as the phone.

Building Your Own

For the person who wants to solder rather than shop, the parts are cheap and the software is solved.

An ESP32 is a small microcontroller with wireless radios built in, and it costs a few euros. Multiple mature libraries turn one into a Bluetooth Low Energy keyboard. They implement the standard profile that keyboards use, they advertise themselves correctly, and they have been tested against iOS specifically. The code to send a key combination is 1 line. The code to send a key combination when a physical button is pressed is maybe 5.

There are two details that separate a working build from a frustrating one, and both come from people who have already done it.

The first is pairing. For iOS specifically, these projects report that you need proper secure pairing rather than the simpler mode that Android accepts. Get that wrong and the phone will bond with the device, appear to be connected, and then silently fail to receive any keystrokes at all, because it never subscribed to the reports. The failure is invisible. Nothing errors. The button just does nothing, and you spend an evening blaming your shortcut.

The second is power. A microcontroller sitting awake with a radio on will flatten a small battery in a day or two. The fix is sleep, and the chip supports waking from a physical pin, so the button press itself is the wake-up event. The trade-off is latency: a device that was in deep sleep must boot, bring up the radio, and re-establish the connection before it can send anything, and that can take a couple of seconds. A lighter sleep mode keeps the connection alive and responds instantly, at the cost of battery life. The libraries expose an idle timer precisely so you can decide where on that line to sit.

That trade-off is the actual design decision, and it is worth thinking about before ordering parts. Instant response with a battery you charge weekly, or a battery that lasts months with a 2 second wait after every press. For a capture button, 2 seconds of waiting is 2 seconds during which the thought is still forming, so it may not matter. For a button that pauses music, 2 seconds is unacceptable. Same hardware, opposite answers.

The Wet Problem

Now the shower, which is a harder problem than it looks and interesting for reasons that have nothing to do with software.

The obvious issue is water, and that one is nearly solved by shopping. Sealed enclosures with rubber gaskets are a commodity item. The harder problem is that a bathroom does not just get splashed, it gets saturated, and then it cools. Warm humid air enters your enclosure through any gap during the shower, and when the room cools afterwards, that moisture condenses on the inside of your electronics. A box that survives being sprayed with a hose can still die slowly from breathing. The standard answers are to seal it properly and include a desiccant, or to seal it deliberately imperfectly with a vent membrane that passes vapour but not liquid.

Then there is the button itself, which is the classic weak point, because a mechanical switch needs a hole and a hole needs a seal. The elegant way around it is to have no moving part at all. Capacitive sensing works straight through a few millimetres of plastic, so the entire enclosure can be a single sealed shell with a sensing pad glued to the inside surface. No hole, nothing to fail. The complication is that capacitive sensing detects water almost as readily as it detects fingers, so a device covered in running water reads as one continuous press. That is solvable with a threshold and a bit of filtering, but it is real work, and it is the sort of thing that behaves perfectly on the bench and then misbehaves at 6 in the morning.

And then the range question, which is the one that quietly kills the whole design. The phone is not in the bathroom. It is on a kitchen counter, or in a bedroom, through at least one wall, possibly two. Bluetooth Low Energy at those power levels goes through drywall reasonably well and through tiled, plumbed, mirrored bathroom walls considerably less well. A device that has to re-establish a connection from deep sleep, through a wet tiled wall, to a phone in another room, is a device that will work most of the time. Most of the time is a terrible property for a capture tool, because you only find out it failed later, when the thought is gone and you cannot remember having had it.

Skip The Phone Entirely

There is a version of this that is much more likely to work, and it comes from asking what the button is actually for.

A capture button has 2 jobs, and they are usually confused with each other. One is to mark a moment. The other is to record content. Marking a moment is trivial, needs no microphone, no transcription, no phone, and no Apple involvement at all. It needs a timestamp and a destination.

If the device already has a wireless radio, and it does, then it can put a timestamped record into a database directly. No pairing. No keyboard impersonation. No accessibility settings. No dependence on where the phone is or whether it is locked. Press the button, the device wakes, joins a known network, sends a single small request to an endpoint you own, and goes back to sleep. Total awake time is a couple of seconds. Total complexity is roughly the same as the keyboard version, and the failure modes are far better, because a failed request can be retried, and a device that cannot reach the network can hold the timestamp in memory and send it later. A Bluetooth keystroke that fails is gone forever and tells nobody.

What arrives is not the thought. It is a marker that says: at 7:14 on a Tuesday morning, in the shower, this person had something. Which sounds useless until you consider what happens next. The marker sits in the inbox. Twenty minutes later, dressed and holding a coffee, the person opens the inbox and sees an empty item with a time and a place, and the thought comes back. It comes back because the context is intact. Human memory is very bad at spontaneous recall and surprisingly good at recall with a cue, and a timestamp plus a location is a strong cue.

That is the version worth building, and it is cheaper, simpler, and more reliable than every option discussed so far. It also has an obvious extension: the same board, with a microphone and a bit of storage, records 30 seconds of audio and uploads it when it next sees a network. Now you have the content too, and still no phone in the loop.

The honest counter-argument is that this is more work than buying a button. A commercial button is 35 euros, arrives in a week, and has a company maintaining its firmware. A self-built device is an evening of soldering, a weekend of debugging, and a permanent low-level obligation to keep it alive. Anyone who has built infrastructure for themselves knows the shape of that obligation. The right answer depends entirely on whether the building is the point or the capture is the point, and only one person can answer that.

What The Note Should Say Now

Six months on, the note can be closed, and the answer is a firm no to the assumption inside it.

An external device absolutely can control shortcuts on an iPhone. It can do it through an accessibility feature designed for people with motor impairments, by presenting itself as a keyboard and sending an unlikely key combination. It can do it by opening a specially formatted link. It can do it through a passive sticker with no battery. It can do it by connecting over Bluetooth and letting an automation notice the connection. It can do it, in the newest versions, by sending a notification with the right words in it. That is 5 separate doors, none of which require Apple's permission, and 4 of which have been open for years.

Whether any of them should be walked through is a different question. The tag on the mirror costs 30 cents and solves the doorway case immediately. The wrist is already there, always charged, and waterproof, and for a person who spends time outdoors it is probably the honest answer to most of this. The shower device is a genuinely interesting build with a genuinely bad radio environment, and its best form is not a phone accessory at all but a small independent thing that posts a timestamp to a database and goes back to sleep.

And there is one last observation that the research keeps circling back to. The problem was never the trigger. Triggers are cheap and there are 5 of them. The problem is what happens 20 minutes later, when a timestamped marker with nothing attached to it is sitting in an inbox alongside 240 other open items, waiting for someone to remember what it meant. Building a better button is a fun weekend. Building the thing that makes the button's output matter is the harder project, and it does not involve any soldering at all.