The ios compilation logic need to removed from npm install

[sebv]

Why the precompiled simulator binaries are not available anymore? they don't need signing.

The real device logic need to be be triggered in npm run-script and or package binaries. The binaries which are not portable should not be saved within the package.

[sebv]

cc @Jonahss

[Jonahss]

@sebv I don't quite understand.

What's wrong with building the ios apps when you install them via npm?

If we need the precompiled binaries back, they're super easy to add, we can just dump them straight into the precompiled directory.

For simulators they don't need to be signed, but having them signed isn't bad is it?

[sebv]

Hey @Jonahss could you try to regenerate WebViewApp6.0.app.zip, I don't think it is too easy.

[sebv]

Just too illustrate that some old apps have historical value.

[Jonahss]

Yeah, if we're using those old values, we can bring them into the Precompiled directory. Do you need those back?

[sebv]

Another more realistic scenario is you want to run the following within xCode 6.3.1

./bin/test --ios71

npm will generate a 8.2 app, which very likely won't work on 7.1.

[Jonahss]

So it sounds like we need a different solution than what we currently have. I would like to understand the problem space involved. What do we actually want? A module that returns our various apps, and we can specify the ios version, the xcode version, and the skd (iphonesimulator|iphoneos)?

[sebv]

Just imagine you are releasing Appium and you need to test all the configurations, including real devices.

[sebv]

Should be easy enough to see that some use cases are not covered.

[Jonahss]

Yes, the next step is to think of a good solution. The .xcarchive solution sounds great if it works. We could host precompiled versions on S3 or something, since it would be faster and more convenient than npm.

[sebv]

Sounds good, but we should probably start with something simple and iterate on it.