Cucumber won't magically make tests from your Gherkin features.
With all those tools you still have to write the step definitions and the code that actually makes the tests happen and maintain it. None of the BDD tools will help you do that and most of them make it hard to exploratory test.
If the acceptance is a sprint level its going to be harder to have the time to do this well in a short time, you typically need some preemptive development of fixtures to keep the tests arriving at the right speed.
If its at integration level then its slightly easier to achieve but try not to do this with large steps , use smaller tightly focused ones and re-use as much as possible.
The main advantage with BDD is that you can reasonably expect project managers to be able to write definitions with it, this allows you to sign off those definitions as long as you can maintain trust in your codes validation of them. Its not a silver bullet, you should really have some clarification of the terms and meanings with both sides before getting too heavily invested in it.
As you are testing across multiple platforms it can be helpfull to use BDD to focus on a similar experience across all of them, you will probably also find that most BDD parsers won't have the platform flexibility you need so you will need to make your own. This is not that difficult if you have the time but your management will probably not like it.