I'm a programmer who've been working on mobile app automation for end-to-end testing for years. Appium is the industory standard in this area. It's basically a WebDriver protocol server spetiallized for non-browser apps like iOS/Android. The beauty of Appium is its clean separation of the responsibility by the client/server architecture. So consumers select any language binding they like when use it. It means you typically need to care of server and client at the same time, and this is the pain.
As a mobile automation engineer, I often need to run a small experiment to make sure of the behavior of AUT(application under test) or Appium itself: how long does it take to fetch page source from a complex screen, how much ScrollView moves to a specific swipe amount, what's hapenning behined the sceen when some letters are dropped from text sent, etc. When it comes, I usually write a small script tp send commands to server, spin up an Appium server, run the script, and then observe the result. It's not so hard but a bit hussle as I need to recall required parameters to give to the server and wire them up just to see actual interaction.
aco makes it significantly compact. You just need to specify your app file and platform from CLI. That's it. The core idea is packing server launch and session initiation in a single command. The other point is that aco is designed as stateful. Session is stored on disk and implicitly picked up so you don't have to care about it when consuming.
$ aco session start --platform ios --app ./your_aut.app.zip --detach
{"sessionId":"0134d269-eb58-4569-97d0-446c5e808fd4","serverUrl":"http://127.0.0.1:4723","platform":"ios","pid":21762}
session detached -- pid 21740, stop with `aco session stop`
$ aco elements
#0 XCUIElementTypeApplication "Some label"
selector: accessibility id:Some label
rect: 0,0 402x874
......
#58 XCUIElementTypeStaticText "Other label"
selector: accessibility id:Other label
rect: 172,630 57x19
$ aco tap --selector 'accessibility id:Other label'
ok