I saw plenty of years-old threads about this topic with no solutions, at least no solutions that are enabled in the drag-and-drop editor. This isn’t a bug per say, so I thought I’d just make a new, updated thread that officially requests this feature.
The ability to disable the “swipe to go back” feature of iOS would be an excellent feature, and one that will have saved me a ton of time. I’m about to re-build my entire app to work on one screen to avoid it.
It could be implemented similar to disabling the back button on Android by using the “When back button pressed” block with nothing in it. If it’s a built-in iOS thing, I wonder if it could also be implemented by having an option of just disabling the drawer navigator’s drawer, or offering another more generic navigator altogether that offers features like this while being able to be hidden completely.
I built an app that the flow is very specific to what screen the user is on at a specific time. For ease of use, I built it using different screens and navigating between them. I’m now going to re-build my app to work on one screen, changing group visibilities instead. I can’t be having users swiping back to the previous screens.
If there is anyone who has come across a way to disable this feature I’m all ears, but from reading the threads it’s been years since anyone’s posted about this and any workarounds don’t exist in the drag-and-drop editor.
Thanks!
1 Like
I may have come up with a workaround. The way I’ve designed my app, I don’t suspect my users to try and swipe backwards. Until I’m able to disable completely, if I’m able to just neuter that behavior I’m okay.
Here’s basically what I’ve done:
-
I initialize a stored variable “screen” and when Welcome starts, I initialize it to welcome. I did it as a stored variable so my users can close the app and come back, I may make this an app-variable if my programming requires it, as I have several app variables and haven’t gotten to testing app closing and re-opening yet. “Welcome” is my first screen, so the first time a user opens my app I want to set the stored variable screen to that.
-
For every page I run a function “stay_on_screen”
-
The “stay_on_screen” function basically checks if someone’s supposed to be on this screen. If they aren’t, it just sends them back to the screen they’re supposed to be on.
-
Every time I want to navigate to a new screen, I update my stored variable “screen” then navigate to that variable. Think of it as granting permission to move to the new screen. If you try to navigate to a screen without setting the variable, that screen will kick you to whatever the variable is set to.
NOTE: It’s important that you use the “Starts” block for your initial screen, and the “Opens” block for the “stay_on_screen” function. Starts will run once, when the screen is first displayed in the app, and “Opens” will run every time the screen is seen.
So far I haven’t run into any issues with my flow, and I think that’s because it navigates away from the wrong screen as soon as the screen is opened before it executes anything else. To my users, it just bounces them back. Since it doesn’t do anything, hopefully they’re dis-incentivized from doing it again.
This is a very hacky work-around but it does solve my problem, and saves me from trying to re-build my entire app in one screen. Until we can properly disable the feature, this does the trick for me.
It appears that this functionality may be built-in now? I don’t know if anyone at Thunkable can confirm this, but it appears the swipe back functionality doesn’t work anymore…I’d love to know if this is on purpose or on accident!
You’re right, I didn’t know this was fixed. I can reveal the page underneath but it doesn’t actually go to the previous page. Thank god.
The problem is I don’t know if this is “fixed” or just a convenient bug. I’m going to need Thunkable staff confirmation before I actually call this solved, but it’s a good sign I think!
I’m still having to build my app(s) with changing group visibilities rather than pages, especially since the default sliding animations are still there as well. That, and revealing the page underneath but not being able to navigate to it is a good step but ideally it doesn’t let you swipe back at all.
