Last generated for the following SDKs:
- MacOS 15.0
- iOS 18.0
These are raw platform bindings generated directly from Objective-C framework headers. It is not meant as a replacement for the vendor:darwin package already included in Odin, but as a 1:1 direct, exhaustive bindings to Objective-C frameworks without manual modification or idiomatic changes, in order to have the full framework API available to Odin as needed.
-
Block handling: Odin already handles blocks, we'll leverage those instead. - Marking block function pointers as such?
These bindings are generated automatically by a personal tool which uses libClang to generate C/C++/Objective-C type data, which is then used by a different tool to generate bindings for Odin (which was adapted from its original purpose which was generating C# bindings).
As such, all of the types in specified framework headers are exported, unless explicitly ignored or modified in the export specification configuration file.
Only a few frameworks have currently been generated, sufficient to get basic game apps going in macOS or iOS. The bindings are generated raw, with no idiomatic changes, other than rules to filter type names, enum item names, upgrade enums to bit_sets and auto create procedure groups (explicit overloads).
The automatically generated bindings support explicit overload of procedures, and they are generated whenever possible.
Because Odin seems to disallow explicit overloads when the arguments of any 2 procedures match their types implicitly, I've opted to not resolve most typedefs to their underlying primitive types, as this allowed for a much lower overload conflict. Therefore they have been kept unresolved and marked as distinct types.
There are cases where the overload conflicts still happen, in such cases the overloads are not generated.
Filters are applied to enum elements as a best effort attempt to remove any redundant prefixes.
There are cases when a class method shares the same name with an instance method. When this conflict occurs, the class method will have the suffix "Static" applied to its name.
When overload methods have the same selector, excluding a trailing ':`, then its last parameter's name will be appended to the method name to avoid conflict.
Objective-C protocols that share the same name with an Objective-C class have their name modified by applying a suffix of "Protocol" to their type name (e.g. the protocol NSObject becomes NSObjectProtocol).
When extending objects you can currently only conform to a single protocol per object extension.
Although type info about generic types is generated by the type definition step of the binder, it is not used when generating the Odin code.