@DTS Engineer , Thank you for the earlier response. I understand that Apple’s position is that one cannot programmatically generate a real keystroke event that passes through the OS’s full event pipeline (pressesBegan, etc.). However, based on my experiments, I observe that: * OverridinginsertText(_:) / deleteBackward()allow's interception of typed input and the possibility of deciding whether or not to call super so that the text in the text view actually updates. Calling insertText() programmatically results in the same updating behavior as user typing (for display, selection, etc.) Given these capabilities, could you clarify: Is using insertText(_:) / deleteBackward() in a subclass considered an “allowed” way to simulate user text input, for production code (outside of testing)? Or is it officially unsupported / fragile behavior (i.e. subject to change)? Even though we can’t generate a “real” key press event, since calling insertText(_:) does trigger the same downstream behaviors (delegate calls, text updates, cursor management), is this considered a supported and intended way to simulate user typing in production? Or is it just an internal side-effect that Apple does not want us to rely on?

I’m building a complex application with a rich UI, and I need to handle granular events at multiple levels — UIControl events, UIGestureRecognizer events, and even subclass-level events depending on the use case. For UIControl, I often need to respond to granular events such as .touchUpInside, .touchDown, .touchCancel, etc., which are not fully covered by .primaryActionTriggered. From my understanding, .primaryActionTriggered does not actually reduce the number of addTarget(_:action:for:) calls I need to write — it only simplifies the choice of which event constant to use for a control’s primary action. So in practice, if my use case requires handling these diverse low-level events, I would still need to explicitly register for each event on each control. Is this the correct understanding?

@DTS Engineer, Is there some preference order in which we should use these ways to handle events? Say I want to handle a simple button click event where the user presses the button in UI using a single touch/tap. what should I use in this case? using addTarget() way to handle the .touchUpInside UIControl event. using UITapGestureRecognizer(with numberOfTapsRequired = 1 & numberOfTouchesRequired = 1) or using the custom touch handlers overriding touchesBegan, touchesMoved,touchesEnded Is there some recommendation like If all these options does the work then I should prefer one over the other. Or it does not matter we can use any ?

Update: I want to programatically simulate the key press event similar to user actually pressing a key on a virtual keyboard or external keyboard(for ipad). This will automatically invoke the UITextFieldDelegate method shouldChangeCharactersIn(_:range:replacementString:) and the pressesBegan(_:with:) methods, and take care of the textfield value updation. Note : In MacOS we can create custom NSEvents and post them to NSApp, allowing us to simulate mouse, keypress, gesture interactions. I wanted to understand If there is something similar frame available for iOS simulation?

In AppKit (macOS), you can simulate events(like key press) programmatically using NSEvent and CGEvent APIs. I wanted to know is there something similar to this in uikit? There is XCTest framework available which helps in simulation , how does this internally perform the simulation? Can that not be used?

Thanks for the response. On a different note, I have an application that is meant to be run as a daemon. What is it that the apple recommends on how to create the daemon application(in terms of creating the event loop)? From apple documentations, I understand that we should be using only daemon safe frameworks for creating a daemon application. According to it, we are not allowed to use Appkit( hence we cannot use the delegate implicit event loop). What is the alternative to it, how to create the event loop now?

It is a non-interactive bundled application but it can be run in both gui and non-gui context. In non-gui context(like ssh terminal), this is launched using daemons or using the unix executable in the bundle like .. cd MyApp.app/Content/MacOS ./MyApp In the gui context, the program can be launched by double clicking the bundled app or using 'open' command. If something is running in a non-GUI context then it’s not an app. For the above statement, If my application is capable of running in non-gui context, then what is it that the apple recommends doing. Should I be not creating a bundled application?

This is solved. I am now able to handle the intent in the shortcuts app using the 'Intents extension'. However, I have a observed something which is not in alignment with the apple documentation. This property which is specified in the .plist file for the intents extension is not available for macOS according to their documentation. However, it is observed that I m not able to handle the intents without using this property and it should be specified for macOS. Is this something being missed in the documentation?

@JWWalker NSWorkspace.notificationCenter seems to be no longer supported. It is giving the above error.

To what end? My primary goal to performing exception handling is that when an exception occurs, I want to be able to perform proper finalization(like closing open file handles and ports etc.) for my application before the exception causes my application to terminate. Additionally, I want to show an alert box to the user informing him about the steps to take in case the exception can be recovered like providing a restart button If that could help. I want to be able to provide a better user experience.

@eskimo Can you please revert on this?

I have tried this in an independent project and it works. However, I have figured out the reason why I m getting this error and wanted your help on how to resolve this. My project is using the new interop mechanism using the modulemap file. For this, I m setting the interoperability to c++ in the build setting. After changing the interoperability to C++, I m getting this error for the SessionGetinfo Api. Can you please check this? public static func GetSessionInfo () -> Void { var sessionID = SecuritySessionId() var sessionAttrs = SessionAttributeBits() let status = SessionGetInfo(callerSecuritySession, &sessionID, &sessionAttrs) //error:Cannot convert value of type 'UnsafeMutablePointer<SessionAttributeBits>' to expected argument type 'UnsafeMutablePointer<UInt32>' if status != errSessionSuccess { print("Could not get session info. Error \(status)") } } You can try this in your project.

Can somebody take a look on this as priority? Its been a week after posting here in this developer forum too...

I have also tried setting the cpp macros in Apple clang but it's also not identified in swift.

I have reproduced this problem without cmake. Can you help now? I have an Xcode project containing a cpp target and a swift target. I am making direct swift to cpp call by exposing cpp to swift using the modulemap file. For the cpp target, I have defined some macros which I m using in the cpp header contained in the modulemap file. I m able to successfully build the cpp target. However, when I build the swift target I get an error message stating that the macros are not declared. When swift tries to import the cpp header via the clang module, it is not able to identify the cpp macros. I m setting the macros in the Compiler flags for the cpp file. You can see this in the image below. One of the macro(WINDOW_KERNEL) is defined with some value. error:Use of undeclared identifier 'WIN32' error:Use of undeclared identifier 'WINDOW_KERNEL'