The behaviour in browsers is the correct behaviour, according to the docs.
Press for ON, release for OFF.
The iOS app is not sending the OFF when the button is released, no statechange event and no update to the UI.
Taking all this into consideration, I would assume the app itself is bugged.
The described behaviour is not about the iOS app any more, but generally about sitemaps in any web browser with BasicUI, as I mentioned above. It has been working fine for me for 10 years with a push button having {autoupdate="false"} and in the sitemap mappings=["ON"="Restart"]
This was working in BasicUI and when programatically sending an ON to the switch.
Why was this ever broken?
Ok, you didn’t suggest it 
but took part in the thread and quoted the 1 second expire solution, which I see more of an awkward crutch to circumvent the current regressional behaviour.
Only with the behaviour when using the push button in the UI. When sending a programatically ON to the button yo0u also end up with a selected ON button in the BasicUI.
Long story short - currently it seems impossible to have a correctly working push button in BasicUI, working in the UI as well as programatically, unless you use the 1 second expire workaround, which is d=sad, especially as this was working flawlessly for many years in previous OH versions.
It might just be a BasicUI redraw issue, as the old definitions still seems viable, but requires a page reload after every push button push or pushing it programatically to get rid of the stuck selected ON state. It really shouldn’t require any expire reset to OFF if the BasicUI correctly redraws a push button.
Lots of people want to have the current state of the Item reflected in the buttons. I know that much. I don’t follow sitemap development much these days.
I know the trend seems to go towards MainUI, but for me the ‘simple’ sitemaps are always one of the biggest plus points when discussing with HA users
As I mainly use openHAB with voice commands thorughout the home, using the sitemap is only for getting an overview of some charts or something.And when I do I obviously want it to work correctly.
I don’t need any fancy gauges or other eye candy possbile with MainUI, and sincerely hope Sutemaps are here to stay in the future.
I think we are over-dramatizing this whole issue, there is just a simple bug in iOS that doesn’t send the OFF state to the switch on release of the button. Fixing this would resolve the issue.
The fact this ‘button’ implementation works in browsers is proof of concept. All philisophical discussion related to the use of sitemaps in general is irrelevant.
Hopefully the team that focusses on mobile app development will address this small bug and restore continuity between mobile and browser functionality.
I can confirm that this has been implemented in the current OpenHABSitemapViewController to SwiftUI migration.
{autoupdate="false"} is not implemented in BasicUI (Browsers, Chrome, Firefox) - [BasicUI] For `autoupdate=false` items after the thing rejects a command, the UI shows the wrong state · Issue #3456 · openhab/openhab-webui · GitHub - and in openHAB-Android - After triggering a change of the state of an item without autoupdate/autoprediction, when the thing rejects the change, Android/OH shows the wrong state · Issue #3947 · openhab/openhab-android · GitHub . I think it is however implemented in openHAB-iOS (but I am not sure).
So if a switch-item, linked to a channel, which channel explicitly by the user, or implicitly by the binding, has autoupdate=false, the user clicks the toggle, the UI will show in the browser a new state. Reloading the page will show the old (correct, real internal) state.