Daniel Lacasse

As for the SDK version, we don't exactly have a good solution. Normally, users would build using _a SDK_ that satisfy the base constraints, so there should be any variant...

The UX would be something like this: ``` $ ./gradlew diff --left=../master-work-tree/Foo.xcodeproj --right=Foo.xcodeproj ``` We will have to deal with the rich console which may or may not be an...

See https://github.com/moonlight-stream/moonlight-ios#building as a good example.

There are some very good information about Xcodebuild output [here (XCLogParser)](https://github.com/MobileNativeFoundation/XCLogParser) and [here (xcpretty)](https://github.com/xcpretty).

So far, there are four different xcodebuild "output": 1) Raw CLI output 2) `xcresult` bundle (generated by `-resultBundlePath`) 3) JSON stream (generated by `-resultStreamPath`) 4) `xcactivitylog` (requires `-resultBundlePath` flag) We...

The project [xcbeautify](https://github.com/tuist/xcbeautify) seems to supersede xcpretty.

We could also capture test execution and output into a build scan. This would require some sort of Xcode output parsing, see https://github.com/nokeedev/gradle-native/issues/648.

`checks`, `build` and `assemble` make sense but we don't yet know which tasks they should depend on. We can back peddle if these tasks are "too much" for the adapter.

I think to properly demonstrate the generated sources, we should implement a proper generator task. We would need to find a common use case that requires generated code (i.e. config...

Good point, the generator is the abstract process to generate the sources. I think we can have a quick mention when we gloss over the generator task implementation. Most users...