Appium Inspector on iOS will not start due to initial alert

My app starts with an iOS-generated alert that comes up over the app GUI:

This screen was arrived at in the iOS simulator by clicking on the Inspector button in the Appium.app application window on my Mac. The last part of the console log says:

info: [debug] [INST] 2015-12-15 21:33:32 +0000 Debug: Running system command #15: /Applications/Appium.app/Contents/Resources/node/bin/node /Applications/Appium.app/Contents/Resources/node_modules/appium/submodules/appium-uiauto/bin/command-proxy-client.js /tmp/instruments_sock 2,{“status”:0,“value”:{“UIAApplication”:{"@":{“name”:“SpringBoard”,“label”:" “,“value”:null,“dom”:null,…
info: [debug] Socket data received (7191 bytes)
info: [debug] Socket data being routed.
info: [debug] Got result from instruments: {“status”:0,“value”:{“UIAApplication”:{”@":{“name”:“SpringBoard”,“label”:" “,“value”:null,“dom”:null,“enabled”:true,“valid”:true,“visible”:true,“hint”:null,“path”:”/0",“x”:0,“y”:0,“width”:1024.0000335703464,“height”:768.0000447604625},">":[{“UIAWindow”:{"@":{“name”:null,“label”:null,“value”:null,"do
info: [debug] Condition unmet after 10457ms. Timing out.
info: [debug] Cleaning up appium session
info: [debug] Error: App did not have elements
at /Applications/Appium.app/Contents/Resources/
node_modules/appium/lib/devices/ios/ios.js:483:30
at Object.cb [as callback] (/Applications/Appium.app/Contents/Resources/node_modules/appium/lib/devices/ios/ios-controller.js:261:7)
at next (/Applications/Appium.app/Contents/Resources/node_modules/appium/node_modules/async/lib/async.js:798:43)
at /Applications/Appium.app/Contents/Resources/node_modules/appium/node_modules/async/lib/async.js:32:16
at [object Object].exports.respond (/Applications/Appium.app/Contents/Resources/node_modules/appium/lib/devices/common.js:28:9)
at [object Object]. (/Applications/Appium.app/Contents/Resources/node_modules/appium/lib/devices/ios/ios.js:1498:18)
at getResultAndSendNext (/Applications/Appium.app/Contents/Resources/node_modules/appium/submodules/appium-uiauto/lib/command-proxy.js:146:20)
at Socket. (/Applications/Appium.app/Contents/Resources/node_modules/appium/submodules/appium-uiauto/lib/command-proxy.js:88:7)
at Socket.emit (events.js:129:20)
at _stream_readable.js:908:16
at process._tickDomainCallback (node.js:381:11)
info: [debug] Responding to client with error: {“status”:33,“value”:{“message”:“A new session could not be created. (Original error: App did not have elements)”,“origValue”:“App did not have elements”},“sessionId”:null}
info: <-- POST /wd/hub/session 500 26195.783 ms - 172

Which is followed by this error dialog in the Appium.app:

I’ve discussed this with our developers and they say that the alert is generated by iOS because our app uses the iOS APIs to try to access the user’s photos. They have no control over if or when the alert pops up. Surely this can’t be the ONLY iOS app that behaves this way!

Is there a standard way to tell Appium to expect and respond to this alert BEFORE it sees any GUI structure for the app under test?

BTW: If I manually jump in and clear the alert, then the Appium Inspector starts up OK and I can use it to see and interact with the app’s GUI.

Following the suggestion here, I added this line to the experimental Python program:

desired_caps['autoAcceptAlerts'] = True

and now it works in terms of dismissing the initial alert and not failing with the error mentioned in the original post. However, the post referenced above seems to be negative about doing this since it will automatically dismiss ALL alerts. Its not really clear on the best alternative approach.

Couple of observations from testing other apps that do this same thing:

  1. Yes, if during your test, an alert pops up and you don’t handle it, the next time you try to start Appium won’t work properly until you clear the alert.
  2. Your tests should identify and handle this alert.

Think about it for a second: If your app opened up to a screen with an ‘activate me’ button, then you’d write a test to click that button, right? Well why not identify the alert and click that big fat ‘Ok’ button?

Also, you should probably test how the app works when the user clicks, ‘Don’t Allow’. You know your users do this, right?

wreed wrote: “the next time you try to start Appium won’t work properly until you clear the alert.” Does this mean that even though Appium seems to launch a new simulator and do a 1st time install of my app every time I start Appium, that it somehow “remembers” the alert state not handled from the last run and fails to start properly until I manually clear the alert? This is bizarre!

My test code had steps to detect and clear the alert, but they were never executed because Appium never started correctly until I put the ‘autoAcceptAlerts’ capability in. If this failure to start was always due to the previous run failing by not handling the alert, then this does not bode well for my hope of doing Jenkins-initiated continuous integration style test automation with Appium.

Your developers are correct. The alert is generated by iOS. If you don’t dismiss the alert, it will not go away when the app quits, which means that you’ll have to clear it before using Appium again.