镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Help with Python Appium iOS Test Script for Opening Settings and Clicking Buttons #1168

Open

Description

Hi Appium team,

I’m trying to create a Python test script for iOS using Appium. I followed the Quickstart example for Android, but when I adapted it to an emulated iPhone device, I ran into a few issues.

Currently, I want to:

  1. Open the iOS Settings app.
  2. Click a specific button or section (e.g., "Screen Time").
  3. Assert a certain text exists.
  4. Understand how to control app launch behavior in Appium:
    4a. Start an app fresh: Launch the app as if it has never been opened before on the device (no cached state, fresh session).
    4b. Attach to an already running app: Connect to the app if it’s already running on the emulator or device, without restarting it.
import unittest
import warnings
from appium import webdriver
from appium.options.ios import XCUITestOptions
from appium.webdriver.common.appiumby import AppiumBy

options = XCUITestOptions()
options.platform_name = "iOS"
options.automation_name = "XCUITest"
options.device_name = "iPhone 15"
options.platform_version = "17.2"
options.bundle_id = "com.apple.Preferences"
options.language = "en"
options.locale = "US"
# options.device_id = "1F4F5697-3E82-4EC9-819A-9478BDE3E598"

appium_server_url = "http://127.0.0.1:4723"

class TestIOSSettings(unittest.TestCase):
    def setUp(self) -> None:
        self.driver = webdriver.Remote(command_executor=appium_server_url, options=options)

    def tearDown(self) -> None:
        if self.driver:
            self.driver.quit()

    def test_open_screen_time(self) -> None:
        el = self.driver.find_element(AppiumBy.IOS_PREDICATE, 'label == "Screen Time"')
        el.click()

if __name__ == "__main__":
    unittest.main()

Problems I encountered:

  1. I cannot navigate into Settings reliably; nothing is happening on the emulated iPhone screen.
  2. I’m unsure how to launch an app fresh vs attach to an already running app.

Could you provide guidance on:

  • The correct way to open system apps like Settings and interact with buttons.
  • How to launch an app from scratch or attach to an existing session.

Any tips for using iOS emulators specifically with Python/Appium.

Thanks in advance!

Best regards,
Alex

Activity

  1. KazuCocoa commented on Aug 16, 2025

    @KazuCocoa
    Member

    Could you share the appium server log as well? If you gave bundle id, the session should try to start the app process first.

    I’m unsure how to launch an app fresh vs attach to an already running app.

    If you'd like to ensure that the bundle id was not running before the test starts, appium:forceAppLaunch capability would help. https://appium.github.io/appium-xcuitest-driver/latest/reference/capabilities/

    https://appium.github.io/appium-xcuitest-driver/latest/reference/execute-methods/#mobile-queryappstate or query_app_state (https://appium.github.io/python-client-sphinx/webdriver.extensions.html#webdriver.extensions.applications.Applications.query_app_state) would also help to get the current running state of the given bundle id. Launch/kill app (e.g. https://appium.github.io/appium-xcuitest-driver/latest/reference/execute-methods/#mobile-launchapp) in the middle of session also would help to terminate/start the bundle id's process.

    In case you'd like to interact with system app managed elements outside the bundle id (e.g., permission popup), https://appium.github.io/appium-xcuitest-driver/latest/guides/troubleshooting/#interact-with-dialogs-managed-by-comapplespringboard will help.

    Asking questions in https://discuss.appium.io/ would also help.

  2. ALPA-Industry-and-Technology commented on Aug 19, 2025

    @ALPA-Industry-and-Technology
    Author

    appium server log

    In the meantime, the script is working fine. Thank you for your help, @KazuCocoa!

    However, to make the iPhone emulator respond to the script, I currently need to manually click on "WebDriverAgent"; otherwise, the script does not work. Is there a way to avoid this manual step, for example when running the script in a CI/CD pipeline?

    Image

    Additionally, when I run Maestro Studio in parallel, I again have to click on "WebDriverAgent". Is there a solution for this as well?

    Would you need the Appium server logs to investigate this issue?

  3. KazuCocoa commented on Aug 19, 2025

    @KazuCocoa
    Member

    Yes, appium server log will help. If Appium ran expected commands, the issue would be outside appium. e.g. the system internal behavior related

  4. ALPA-Industry-and-Technology commented on Aug 19, 2025

    @ALPA-Industry-and-Technology
    Author

    log_file.txt

    Often, I get the same three lines whenever Maestro Studio is active or if I haven’t clicked on "WebDriverAgent" beforehand.

    [179d8ff2][XCUITestDriver@2a17] Matched '/status' to command name 'getStatus'
    [179d8ff2][XCUITestDriver@2a17] Proxying [GET /status] to [GET http://127.0.0.1:8100/status] with no body
    [179d8ff2][XCUITestDriver@2a17] connect ECONNREFUSED 127.0.0.1:8100
    

    Under these circumstances, is it possible to test an iOS application with Appium in an Azure Pipeline? If so, could you please point me to the relevant documentation?

  5. ALPA-Industry-and-Technology commented on Aug 19, 2025

    @ALPA-Industry-and-Technology
    Author

    Moreover, the Appium Inspector sometimes does not update its current view of the iPhone screen. Do you have any idea why this might be happening?

  6. eglitise commented on Aug 19, 2025

    @eglitise
    Contributor

    I currently need to manually click on "WebDriverAgent"

    This should not be necessary, your test script should automatically activate it when you start the driver.

    when I run Maestro Studio in parallel, I again have to click on "WebDriverAgent"

    I don't see how Maestro Studio being opened could be related to this, unless it happens to use the same ports as Appium processes (in this case port 8100).

    I get the same three lines

    The logs seem to be fine (at least to me). These 3 lines are expected behavior while the simulator is launching and WDA is being built, and it can take up to 1-2 minutes. If your test fails due to a timeout, you may want to set the appium:wdaLaunchTimeout capability to increase the wait timeout.

    the Appium Inspector sometimes does not update its current view of the iPhone screen

    Do you mean that the source and screenshot stay the same after pressing the Inspector's Refresh button? It would be helpful to get the Appium server logs for this case as well.

  7. KazuCocoa commented on Aug 20, 2025

    @KazuCocoa
    Member

    I guess the xcodebuild for WDA took longer time. appium:showXcodeLog would help to print xcodebuild logs into appium server log. The log addressed in #1168 (comment) itself indicated WDA process hadn't been started yet.

  8. ALPA-Industry-and-Technology commented on Aug 21, 2025

    @ALPA-Industry-and-Technology
    Author

    I guess the xcodebuild for WDA took longer time. appium:showXcodeLog would help to print xcodebuild logs into appium server log. The log addressed in #1168 (comment) itself indicated WDA process hadn't been started yet.

    Here are the logs:
    appium_log_20.08.2025.txt

    The log file consists of two successful runs. They worked, but the execution time was unbelievably long, as the delay occurred while the WebDriverAgent (WDA) was initializing, and the actual script execution only started after that.

    Is it considered good practice to end the script with a finally block that calls driver.quit()? Could it be that, because I haven’t done this yet, the Appium server eventually became overloaded with too many open sessions after repeatedly starting my Python script?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions