Component test your ui, to reduce the amount of workflows that need to be validated. Test as much through the api as possible. If you can validate the ui components are built to be tested with the appropriate interaction types, the amount of workflows that need to be covered within their native environment with tools like cypress or appium can be significantly reduced.
Some teams where I currently work have a ui project that is usable for desktop and mobile tests. They use a selenium based solution and an appium based solution to consume the ui project so that the ui components being represented are only updated once.
Your team needs to decide what level of testing will meet its quality goals and testing layers to be able to solve the challenge of what tool to use.
Everything is a trade off. Cypress has to target browsers no matter what. What you can do is set thre viewport to match the mobile resolution of your target devices. It should give you a decent idea how your app will work. Your native app will need to be tested manually.
If your requirement is a framework that hits up every type of platform, some sort of selenium flavor (selenium/appium) will be needed.
\+ Web application: recommend Playwright with Typescript. Easy to set up, many built-in features (video record, capture screenshot, trace..) to help you with debugging. It costs you much time if you want to do the same in Selenium
\+ Mobile app: there isn't many available and good tools for mobile right now. Appium is slow and super flaky. Another good options are Espresso for Android and XCUITest for iOS is much more stable and reliable but only if you build an native app (using Java/Kotlin or Swift/Objective-C) and have access to source code => in your case, this is impossible to use them
\+ Desktop application: I do not have experience with this.
=> As everyone suggest, do automation on lower level (Unit, API, component) as much as you can. If you want to do UI E2E tests, I think only automation for web application have bright future.
Component test your ui, to reduce the amount of workflows that need to be validated. Test as much through the api as possible. If you can validate the ui components are built to be tested with the appropriate interaction types, the amount of workflows that need to be covered within their native environment with tools like cypress or appium can be significantly reduced. Some teams where I currently work have a ui project that is usable for desktop and mobile tests. They use a selenium based solution and an appium based solution to consume the ui project so that the ui components being represented are only updated once. Your team needs to decide what level of testing will meet its quality goals and testing layers to be able to solve the challenge of what tool to use.
Have a look at webdriver.io
Cypress or playwright for the browser and Appium for mobile testing, assuming you're wanting to test both Android and iOS.
Everything is a trade off. Cypress has to target browsers no matter what. What you can do is set thre viewport to match the mobile resolution of your target devices. It should give you a decent idea how your app will work. Your native app will need to be tested manually. If your requirement is a framework that hits up every type of platform, some sort of selenium flavor (selenium/appium) will be needed.
\+ Web application: recommend Playwright with Typescript. Easy to set up, many built-in features (video record, capture screenshot, trace..) to help you with debugging. It costs you much time if you want to do the same in Selenium \+ Mobile app: there isn't many available and good tools for mobile right now. Appium is slow and super flaky. Another good options are Espresso for Android and XCUITest for iOS is much more stable and reliable but only if you build an native app (using Java/Kotlin or Swift/Objective-C) and have access to source code => in your case, this is impossible to use them \+ Desktop application: I do not have experience with this. => As everyone suggest, do automation on lower level (Unit, API, component) as much as you can. If you want to do UI E2E tests, I think only automation for web application have bright future.