Thanks for pointing this out. I went through the docs and tried out a demo and this indeed solves my issue. I can see that this works for iOS 18+. My target is iOS 14+, is there any equivalent for this initializer that works for the previous versions as well?

Thanks for the quick responses! @Claude31 's solution covers almost all my use cases except for one. I am unable to detect modifier-only keypresses with the above approach. TextField ("Enter text...", text: $txt) .onKeyPress(action: {keyPress in print ("key: \(keyPress.key), modifier: \(keyPress.modifiers)"); return .ignored; }) For eg, nothing gets printed when I press only the Alt key. I ask this since my application has to allow the user to experience additional functionality on press of special keys - like pressing the Alt key may trigger a particular menu on a particular screen. How can I detect such keypresses, or is it not possible by design? The intent is to be able to implement custom functionality corresponding to an extensive set of hotkey combinations and modifier-only keys. Please correct me if I'm approaching the problem in the wrong direction.

As you mentioned, we too see 'best' as a 'reliable and safe' approach. Yes, we're mainly concerned with bridging between C strings and Swift Strings. The implicit conversion provided in Approach 2 uses std::string and while we can obtain the C string from this std::string, we're not supposed to use the std data structures - so maybe approach 3 or 1 is the way to go - or something different that is not known to us yet. What would you recommend?

I’ve used NSTextField as an example, but in reality, there will be various types of UI elements, such as buttons, dropdowns, tables, and more. All these elements must be visible on the screen all at once.

Hi, I've uploaded the test project on github: https://github.com/Raunit-TW/xcode-framework-poc Adding more context to the problem, it was first discussed here: https://developer.apple.com/forums/thread/751522. To summarize, we have an application with a bunch of extensions, all of them dependent on some common C++ source files. Building each target individually leads to a bloated app bundle and final binary, since the contents are copied to each binary. As per our understanding, frameworks can solve this issue of increased binary size by packaging the common C++ files separately such that they can be shared among the extensions.