Failing to open iOS application in the simulator

[sharplet]

I'm getting further since #60 was fixed, but not quite all the way there yet. The application appears to successfully install in the simulator, but then fails to open:

An error was encountered processing the command (domain=FBSOpenApplicationErrorDomain, code=1):
The operation couldn’t be completed. (FBSOpenApplicationErrorDomain error 1.)

This could be related: http://stackoverflow.com/questions/31350957/fbsopenapplicationerrordomain-error-1. Something to do with environment variables on launch. I'll try take a look into this later.

[gfontenot]

@sharplet I'd love to know if you've resolved this.

[sharplet]

I have not. Might try to take a look tomorrow.

[sharplet]

Ok! I worked out what's going on here. The cause of the error: the app bundle that was being installed was built for iphoneos, not for iphoneosimulator. No wonder it crashed on launch. Here's how that happens:

• bin/run_ios_app searches relative to Build/Products, which contains subfolders for all destination + configuration pairs.
• I had previously built for device from within Xcode
• During :Xrun, right here, we do a find for *.app bundles and take the first result.
• The iphoneos build is the first result.

[sharplet]

Here's what I thought we could do: Instead of grepping for BUILD_DIR, we instead use CONFIGURATION_BUILD_DIR to build the path to the app bundle.

However, there seems to be a discrepancy between xcodebuild build and xcodebuild -showBuildSettings in terms of how it resolves build settings. xcodebuild build uses the Configuration defined in the Run action of the scheme, whereas xcodebuild -showBuildSettings completely ignores the configuration from the scheme, instead using the default configuration for command line builds.

I can think of two options:

1. Replicate Xcode's behaviour by locating the .xcscheme file and parsing the XML to find the Run action's configuration
2. Add an :Xconfiguration command to vim-xcode and then use that to pass an explicit configuration through to invocations of xcodebuild.

Thoughts?

[gfontenot]

Is there an even easier way to solve this? We actually don't support running on a device at all right now, so could we modify our script to only find simulator builds?

[sharplet]

Yeah we could totally hardcode that.

[sharplet]

FWIW, it's currently hardcoded to look up simulator builds in #71.

[sharplet]

In a discussion on #71, it became clear that it makes sense to flesh out support for schemes.

The core of the problem is that when we use xcodebuild -showBuildSettings, it doesn't actually use the configuration defined in any scheme action, instead using the default configuration for command-line builds (usually Release) or a configuration that's explicitly passed in.

So because xcodebuild -showBuildSettings doesn't do enough to let us read build settings based on the current scheme, we'll have to instead start parsing the scheme. After talking with @gfontenot about it in person, here's a proposal for how to implement this:

• When running :Xscheme, we validate the scheme name using the output of xcodebuild -list. No change here from current behaviour.
• After validating the scheme name, we do a recursive search in the current directory for a .xcscheme file that matches the selected scheme, and choose the first match.
• Store the path to the .xcscheme file.
• Add a new shell script that can parse a scheme file for useful information.
• Somewhere during the run part of :Xrun, grab the configuration for the current scheme's build action and pass that explicitly to bin/run_ios_app.
• Now we can use xcodebuild -showBuildSettings -configuration <name> to read CONFIGURATION_BUILD_DIR and install the correct app bundle.

[sharplet]

Note: this would explicitly not be supporting ambiguous scheme names in workspaces or projects. Unambiguous scheme lookup can be added later.