I'm thinking about a UX scenario.
For example, you have a screen in your app with a swipeable tab component. On iOS, you have back gesture too. So users can not swipe to back screen (because of that swipeable component) and they have to use the back button.
So what is the best solution in this case?
I'm thinking about a UX scenario.
Before answering i want to note i doubt that swipeable elements will have the authority over ios native gestures when you said
users can not swipe to back screen (because of that swipeable component) and they have to use the back button.
If they indeed do it would be a threat that might cause security issues, can you imagine a user not being able to exit a fullscreen mode?
My answer is based on speculation, so it won't provide the golden satisfaction nevertheless if you want to decide without having to conduct a full research:
**It should be safe to use swipeable tabs on ios with
I'm looking the following arguments to answer this:
How users interact with swipeable elements
While i do not have any empirical evidence, i am guessing that most users do not reach the edges of the screen when interacting with swipeable tabs.
Apple would not ignore this
Many might argue that apple would use its authority in enforcing developers to change their apps, yet swipeable elements are not some hipster uncommon pattern, it is widely invested in so many apps, meaning apple must have researched the compatibility of its gestures to ensure no/minil conflicts occur.
We haven't heard any buzz about gesture conflicts
Tech news & media is leaving no mercy for apple especially in the iPhone space, i have not heard about any complains happening regarding any conflicts of gestures all what we hear about is the newness of this pattern and how they enforced it over users that prefer the home button. If you heard otherwise please share.
Users eventually will learn it
Even if a conflict occurs, usually it would occur in so many different apps that would kind of establish the concept of accidental discovery across the ios world, the user would have to learn not to swipe from the edge of the screen in this case, therefore not leaving you alone to handle this problem.
Note: this is not the most user-centered way of handling things so let's imagine i have whispered it in your ear.
IOS is not the first
IOS is not the first to do something like this:
On the samsung galaxy, there is the gesture of capturing the screen (on the left) and the Edge panel (on the right) both require swiping gestures that could cause the same issue but they kind of went fine.
The iOS back gesture works from the edge of the screen. So if you keep enough of a margin (e.g 1cm) you can implement the tab swiping on the center of the screen without any conflict.
In fact, I'd argue that it would be the best approach on Android (and other platforms too) because of two main reasons.
Firstly; there are similar apps that take up screen edge space, and would get triggered (because of overlays/prioritization) if your app uses the edge too. For example a ton of android apps that clone the ios back functionality, as well as several sidebar docks - some even factory-installed on phones.
Second, a bit more abstract; it emphasizes what you are swiping. The closer to the center of the screen, the deeper in the current app. Consider it like layers of an onion. The outer edges should be reserved for global functions. Then you have app specific gestures, that work across most of the screen. Then you have smaller elements like swiping through a caroussel, or deleting an email. This hierarchy has been in existance for a long time in many forms; consider where menu and taskbars are in Windows and OSX. On phones we used to have physical buttons below the screen, then virtual buttons, then a disappearing buttonbar, and now it's just the bottom row of pixels.
The hierarchy is quite ingrained in vertical layouts, it's just that the horizontal dimension is relatively new in this respect.