need to remove autoLanch=false, launchApp(), closeApp(), and resetApp()

This suite of functionality is outdated and confusing and dangerous. We should remove the routes and driver implementations for these. In their place, users should rely on standard Appium session management (new session + caps, delete session), and the now-reliable app management functions (terminateApp, installApp, activateApp, startActivity, etc...)

[update by Kazu]

Alternative

terminate_app and activate_app to restart the app process
- Other methods: examples: mobile: terminateApp, mobile: activateApp, mobile: launchApp, mobile: startActivity
uninstall/install the app to clean the local data In iOS (iOS does not have clear the local data api, so it requires uninstalling the app to do it)
- For iOS simulators, mobile: clearApp could help -> https://appium.github.io/appium-xcuitest-driver/latest/execute-methods/#mobile-clearapp
https://github.com/appium/appium-uiautomator2-driver#mobile-clearapp to clear the local data in UIA2
Espresso driver hasn't supportted resetApp at the beginning

👍
I forgot since, but non-app and bundleid/apppackage in caps behaves as same as autoLaunch=false.

So, appium has no issue for WPA case as well after removing autoLaunch=false. On iOS, it is just a shortcut of safari on a home screen. It has no bundleid, so to automate it, a user should start a session with homescreen and find the icon, and click it.

for autoLaunch:

Is it good to remove the caps from https://github.com/appium/appium/blob/2.0/packages/base-driver/lib/basedriver/desired-caps.js#L23-L25 and add this in the migration guide...?
after this, we can remove relevant code https://github.com/search?q=org%3Aappium+autoLaunch&type=code

other commands:

Remove them from route.js or return errors first...?
Maybe returning an error message...?

@KazuCocoa

@KazuCocoa yes sounds like a good plan. as for the other commands, i think we should remove them from basedriver now, without any need for deprecation notice. that will be in the migration guide. then we can remove them from the drivers once the crossover to 2.0 is complete in 6 months or whenever. so if you're using 2.0 now with 2.0 basedriver, you won't have access, but with appium 1.x there will be access until the EOL period.

I would argue against the removal ofresetApp.
Strongly.

It seems to me that it is working perfectly fine and it is perfectly maintainable for Android.
I realize the same can't be said for iOS/XCUITest/WDA.

Correct me I'm wrong but the app state is clean, including things like local storage, sessions.
This type of cleaning does not occur when using just installApp / removeApp / activateApp, does it?
It's a crucial piece for the test life cycle.

Instead of removing resetApp couldn't we focus on improving / refactoring it?

Another thing: Creating sessions takes time and resetApp is a huge time saver

Using resetApp is currently a hell of a lot faster than creating new sessions.
Especially when using cloud vendors.

There's often a limit to concurrent sessions.
There's the very real problem of cloud users competing for public hardware.
Wait times for session creation can be long.

If a user wishes to clean the app state while reusing the same session, for whatever reason, making tests atomic or to speed up test runs, they will be left without any options.

Seems the devs are a bit disconnected from the reality of owning and maintaining an Appium test suite.

I don't see enough of an argument to remove this functionality, even if it's for a major version.
Not without addressing these issues and providing alternatives.

This type of cleaning does not occur when using just installApp / removeApp / activateApp, does it?

It does. Actually on iOS uninstalling an app is the only way to cleanup its data

Especially when using cloud vendors.

resetApp is just a workaround for the general session startup performance issue there. I assume cloud vendors could improve their logic for stopping/starting sessions. Basically, if we are talking about pure performance then resetApp call would anyway lose to uninstall/install APIs in scope of a single session

What is to be used as an alternative to resetApp() in situations where we want resets between tests within the same spec file?

It depends on your scenario.
If the reset means uninstall/install the app, then you can call uninstall/install APIs.
If you'd like to close/create a new session again as the old espresso driver does, then you can call quite and create again.

So my scenario is closing and creating a new session each time. Just to clarify this is driver.quit() and driver.create()? Thanks!

@KazuCocoa

So my scenario is closing and creating a new session each time. Just to clarify this is driver.quit() and driver.create()? Thanks!

This will depend on the client you are using. What @KazuCocoa is saying is that you can just quit and start a new session. You are already doing this. If you want to do it multiple times within one test you might need to rearchitect your test suite so that it happens internally rather than on setup/teardown of each test. That's all up to you; your test architecture is not related to Appium.

So yea currently we do do that interally, but the actual code which resets the app is the driver.reset(). What I'm asking is what should we migrate to when that's gone? Using WDIO, XCUI and UIAutomator2 currently

Then, uninstall the app -> install the app -> launch the app should be enough.

@KazuCocoa

Then, uninstall the app -> install the app -> launch the app should be enough.

@KazuCocoa is there a way to maintain the state of application when performing the above operation. I tried with full reset = false and no reset = true but could not get

Hi, just a short note about my Appium expirence using real Android devices:

Appium 1.x using driver.quit was closing the app and the driver
Appium 2.x with java client 7.x using driver.quit is not closing the app (stays in foreground), so I added before driver.closeApp additonally
Appium 2.x with java client 8.x using driver.quit is not closing the app, so I added a http api call …appium/close/app additonally

Or is there another way to close (bring in background) the app at test end using java client 8.x on real device?

Regards

@Portium

@Portium Try shouldTerminateApp capability if you are talking about UIA2 driver

For now the deprecation is done for all major driver but UIA2
Also the API has been removed from major clients

There's still no clear instruction on how to replace the driver.resetApp() command when only bundleID is used (.i.e. the app does not get removed and reinstalled before each test; 'bundleId' capability is used instead of 'app'.
Seems like driver.terminateApp(<bundleId>) + driver.activateApp(<bundleId>) does the trick, is that right? We basically try to simulate killing and relaunching the app on iPhones

yes, terminate/activate is ok for the process restart generally. In case you wanted to clear the local data, you might need to uninstall the app once as iOS. I made some suggestions at the top of this issue #15807 (comment)
Some client deprecation warnings also may have alternative commands.

hey guys, was navigating through google searches for my problem and i stumbled across this thread. i'll keep it short;

i'm doing some test automation for a hybrid app (based on both Android & iOS) through appium 2.1 with python and python client, on macOS Ventura. a little piece of my struggles led me here which is, 'cleaning the cache/resetting the state' of the app on the iOS platform after each test script/case. initially what i've understood from reading this thread, there is no way of doing said task except removing the app and installing it again. but then again, we're on v2.1 of appium, there might've been a way that i've missed. need some guidance regarding this issue.

Also, i'm making a hybrid automation test suite. meaning, same test script, but will run on iOS or Android depending on whichever platform is detected at the start of the script.

PS.
i'm running test scripts on iOS with just the bundleId, not the app.

Look to this capabilities

{
  "platformName": "iOS",
  "appium:platformVersion": "16.4",
  "appium:deviceName": "iPhone 13",
  "appium:automationName": "XCUITest",
  "appium:app": "/Users/username/IdeaProjects/myproj/my.app",
  "appium:enforceAppInstall": false,
  "appium:autoLaunch": false,
  "appium:permissions": "{\"en.myapp\": {\"userTracking\":\"YES\", \"location\":\"YES\", \"calendar\":\"YES\", \"camera\":\"YES\", \"contacts\":\"YES\"}}"
  }

In this case.

myapp will be installed if the current version of the program is not installed
myapp will get the necessary permissions
myapp will not launch

If I remove "appium:autoLaunch": false then the app will launch. How can I install the application, get the permissions but not use the autoLaunch function? How can I check that the current version of a program is not installed, but not launch that application?

@fleytman

@fleytman for checking installation I would probably run ideviceinstaller -l | grep en.myapp. Not sure about permission retrieval, but perhaps libimobiledevice provides some way to extract that, too.

Perhaps mobile:installApp can have enforceAppInstall option to behave the same installation. (should be a new feature request right now)

Then, starting a new session without app/bundle Id and autoLaunch create a session with do nothing. Then, the session calls mobile:installApp and sets permission/s via mobile:setPermission. You could get what app in installed and the version etc via mobile:listApps for real devices in a session. Internally appium checks the CFBundleVersion value for the version check.

@fleytman

@fleytman for checking installation I would probably run ideviceinstaller -l | grep en.myapp. Not sure about permission retrieval, but perhaps libimobiledevice provides some way to extract that, too.

Yes, there are ways to implement it yourself, although not very obvious (there is no mobile:shell analog for ios). In my case I use a simulator. But to manage the same permichins, appium has logic when to use simctl and when to use applesimutils. But KazuCocoa correctly suggested that I could mobile:setPermission to use. Alas, there is no convenient java-client wrapper for this, so unless you get into xcuitest-driver's doc it's not so obvious that there is a way.

P.S. I want to make sure that when I make changes to the appium code I don't lose the functionality that is there. In this case it looks like the case I mentioned with enforceAppInstall was not taken into account. But the very situation with the refusal of capabilities requires a lot of changes in the code of current projects, so much so that there are discussions whether it is worth switching to the latest versions of appium at all...

worst ever change in Appium. Broke my whole framework. Thinking of switching to a new tool :/

Hampura

Navigation Menu

Repository navigation

need to remove autoLanch=false, launchApp(), closeApp(), and resetApp() #15807

Alternative

27 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

need to remove autoLanch=false, launchApp(), closeApp(), and resetApp() #15807

Description

Alternative

Activity

KazuCocoa commented on Sep 3, 2021

KazuCocoa commented on Sep 4, 2021

jlipps commented on Sep 8, 2021

nextlevelbeard commented on Sep 17, 2021

mykola-mokhnach commented on Sep 17, 2021

mykola-mokhnach commented on Sep 17, 2021

kdthomas2121 commented on Oct 11, 2021

KazuCocoa commented on Oct 12, 2021

kdthomas2121 commented on Oct 12, 2021

jlipps commented on Oct 12, 2021

kdthomas2121 commented on Oct 12, 2021

KazuCocoa commented on Oct 12, 2021

ashokkumarg commented on Jan 27, 2022

27 remaining items

Portium commented on Sep 2, 2023

mykola-mokhnach commented on Sep 2, 2023

mykola-mokhnach commented on Oct 19, 2023

mikebruin commented on Oct 26, 2023

KazuCocoa commented on Oct 26, 2023

hassanabbaskazmi commented on Oct 26, 2023

fleytman commented on Feb 5, 2024

eglitise commented on Feb 5, 2024

KazuCocoa commented on Feb 5, 2024

fleytman commented on Feb 6, 2024

aragalstyan2000 commented on Feb 25, 2025

frrzy commented on Jul 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions