Lay out ObjC/Swift bindings skeleton

[shoumikhin]

Landing changes for this RFC
#8360

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/8826

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[shoumikhin]

@pytorchbot label "topic: not user facing"

[facebook-github-bot]

@shoumikhin has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[mergennachin]

1. Added "release notes: api" label instead of "topic: not user facing" since it looks like user facing API change.

2. While we're still finalizing the API, do you wanna tag them as "experimental" as per the lifecycle? https://pytorch.org/executorch/main/api-life-cycle.html#how-to-mark-api-state In 0.6, we make the swift/objC bindings as experimental, and in 0.7 we can promote to stable APIs.. That way, you have more flexibility in terms of changing APIs until 0.7 without breaking our API policy.

[shoumikhin]

@mergennachin thanks for suggestions!
This PR (likewise #8825 and a bunch landed yesterday) basically creates a frame for @bsoyluoglu to fill with some gems. So that the actual implementation can immediately become a part of OSS nightly builds, as well as available internally via Buck.

[mergennachin]

This PR (likewise #8825 and a bunch landed yesterday) basically creates a frame for @bsoyluoglu to fill with some gems. So that the actual implementation can immediately become a part of OSS nightly builds, as well as available internally via Buck.

@shoumikhin Yeap, I understand that the APIs can be immediately part of the OSS nightly builds, which is great. And you are building the scaffolding so that @bsoyluoglu fill in directly the implementations.

I am just making sure that if the users start immediately using the APIs in the nightly, they can expect a certain level of changes, including breaking changes in the API until ET v0.7 release. Otherwise, if you don't mark as experimental, it will be harder to make API breaking changes after 0.6 release (March/April), because by default it will be considered a stable API.

On top of the files, you can just mark them as experimental in the docblock.

[shoumikhin]

@mergennachin those must be experimental for sure, until we switch internal clients to use them and prove everything works well. I've already marked them as such per your suggestion.

[facebook-github-bot]

@shoumikhin has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[facebook-github-bot]

@shoumikhin has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[facebook-github-bot]

@shoumikhin has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.