Not sure which method you meant isn’t working, but as I said in my post, the method I implemented has worked across devices for my use case (it was a PWA, didn’t create native builds).
I’m elaborating the logic I used to implement -
In my app I have Home, Screen A, Screen B & Screen C. The flow is Home -> A (entry condition check) -> B (take some action) -> C (confirmation).
B is the screen I want to protect & not have accessible from anywhere after being used exactly once. There are one two ways to access - A (before, from Home) & C (after, via browser or device back buttons).
From A - I add an additional screen A1, so new flow is A (check flag value in action button for conditional linking) -> A1 if flag false, or B if flag is true. I also create a flag variable which changes its value 'When User Visits Screen B" as described above. Once the flag variable is set, user flow will always direct user to Screen A1. You can add any text on A1 to indicate screen B has already been accessed once, so is locked.
From C - I add an addition blank screen C1, with custom action “When User Visits Screen C1, Link to Screen C”. New flow is B -> C1 -> C. Again, since only way to access C1 is through B, and since C1 immediately forces user to link to C, there is no way to access B. No matter how many times or how quickly back button is pressed, screen B is just not accessible. In reality I add a couple of blank screens with forced links, so my flow is B -> C1 -> C2 -> C. Just for added comfort.
That takes care of things logically for Screen B from both sides of my user flow.
For Screen B itself, In my case I was creating a new entry in ‘action’ collection via screen B. So I change the visibility of Action button depending on the condition where button is visible if ‘action collection-> logged in user count-> today < 1’. For me one use is the limit, so button disappears after an entry is created.
Maybe if you meant Screen B is always on your device cache or device history, as a separate page or a hyperlink separate from the app, its maybe possible from mobile device browser where entire app screen slug is exposed. Even on mobile device if a user bookmarks screen B, & directly visits screen B, then the visibility condition takes care of any further actions.
As mentioned, I’ve implemented this flow on a voting use case & I can tell you it worked fine (unfortunately can’t share loom due to it being a private app).
You can customize the flow & visibility / use-count for your specific use case.
Hope that helps.