Obviously ids are the least brittle, but I still personally use a lot of xpath, and I don't think we should be dismissing it so quickly. IDs simply are not always an option.
We use name/label/value matches whenever possible. Raw xpath with no labels/values is going to be unreliable. Even if your element doesn't have a proper id, is surely must have a value or label on it that can be extracted?
If not, usually we have found that you can generalize an xpath to work on both platforms. Often there are only subtle index differences like:Â
iOS 6 //window[1]/cell[2]/button
iOS 7 //window[2]/cell[3]/button
Depending on how the rest of your element tree looks, you might be able to get away with using this for both: //window/cell/button
Or surely in a example like this, the button would contain a common string label. You could try something like:
//button[@value='match']
//button[contains(@value,''substring')]
If you need cross-version support simultaneously, you can put some conditional logic in your element's definitions. Example, if (version > 7) { button = By.xpath( //window[1]/cell[2]/button) } else { button = By.xpath(//window[2]/cell[3]/button)
In my experience avoiding numerical xpath indexes and pairing with label/value/name matches leads to minimal maintenance on our part. Now when a developer decides to change things around, that's another thing... and probably beyond our control :)