I have a .app file that I want to run as a daemon. Now there are two ways of running .app as a daemon/agent in macOS.
using .app file : I can specify this in the daemon plist as:
<key>ProgramArguments</key>
<array>
<string>/usr/bin/open</string>
<string>/Applications/myApp.app</string>
</array>
using unix exe within .app file
<key>ProgramArguments</key>
<array>
<string>myApp.app/Content/MacOS/MyApp</string>
</array>
Basically I wanted to know what is the Apple recommendation on how we should be creating daemon plist.
For point 2, is it appropriate to use the unix executable within bundle?Will it not cause any issue in the running application?
Is will be helpful if there is some apple documentation to support this.
Post
Replies
Boosts
Views
Activity
I have a public swift function with the below declaration :
public func InternalMain (_ pNumOfArgs : Int32, _ pCmdlineArgs : UnsafeMutablePointer<UnsafeMutablePointer<Int8>?>) -> Int32 {..}
I need this function as public because I need to invoke in from a different library. But the above declaration produces an error in my generated swift header i.e '-swift.h' file because 'UnsafeMutablePointer<UnsafeMutablePointer?>' type cannot be represented in the swift generated header.
Can someone help how do I get past this. This is a class independent function and I tried using the '@nonobj' to prevent this from getting in the generated header but it still gives an error.
Is there some notification that apple provides that I can register to, and get notified whenever there is a 'battery low' state?
I want to perform certain task in my application for low battery.
Is there some way to identify this?
I have a bundled application(.app file) in macOS which is a non-interactive application. This app does not link to any GUI frameworks and I am able to launch it using the 'open' command in a normal GUI login session.
However, when I perform ssh login to that user and then If I try to launch the application, it fails to launch.
I assume that this is happening because my ssh session is a non-GUI session, and 'open' command is due to some reason failing to run in a non-GUI environment, but I m not sure.
Can someone help me understand why is this happening?
I have an executable in macOS that I m launching as a User Agent. The same executable can be launched in multiple ways like either user can directly click the exe to launch it, or user can launch it from the terminal using ./ etc. One similar way is when the user launches the exe as a User Agent(i.e daemon in user session).
In this scenarios, I want to identify in my exe If my user has launched it as agent to perform certain task.
I wanted to know how can I accurately determine this?
I have tried figuring out If there is some unique session that agents operate in, but I could not find anything. Can someone help here? Is this even possible?
I have macOS application and I want to provide an action for it in the 'Shortcuts' app QuickAction list. I was using InApp handling to present my intent created in the intent.intentdefinition file as action in the shortcuts app and it was working.
However, this action perform a very lightweight task so I intent to have the action implemented as an extension in my xcode project.
According to my minimum deployment(i.e macOS 11.0) I found that 'Intents Extension' could be used.
I have added the 'Intents extension' target to my main application and created an intent using the intent.intentdefinition file. However, my intent does not appear in the shortcuts app. I have verified it multiple time to ensure I am not missing anything, but still the intent is not present in the shortcuts app action.
I wanted to be know, Is this even possible? cause this apple documentation only mentions about iOS and watchOS app. It also does not mention If our custom intent(created using Intents extension) in the intents extension can be exposed to the shortcuts app.
For macOS 13.0+, I have used the 'AppIntents extension' and I m able to achieve the same. So, I suppose the same should be possible using the 'Intents extension'
I have added an "App Intents Extension" target to my main application in macOS. This generated the below two files:
TWAppIntent.swift
import AppIntents
struct TWAppIntent: AppIntent {
static var title: LocalizedStringResource = "TWAppIntentExtension"
static var parameterSummary: some ParameterSummary {
Summary("Get information on \(\.$TWType)")
}
//launch app on running action
static var openAppWhenRun: Bool = true
// we can have multiple parameter of diff types
@Parameter(title: "TWType")
var TWType: String
func perform() async throws -> some IntentResult & ReturnsValue<String> & ProvidesDialog {
return .result(value: TWType, dialog: "Logged break.")
}
}
TWAppIntentExtension.swift
import AppIntents
@main
struct TWAppIntentExtension: AppIntentsExtension {
}
I m able to build the extension target and I my intent action is available in the shortcuts app. However, on launching a shortcut with the above created intent action. I m getting the below popups:
I have identified what is causing this error. Setting the openAppWhenRun to true is causing this error. I don't get this when it is set to false. This property is supposed to launch the application, but can someone help me understand why is it happening? This is only causing the error when using this property for AppIntent Extension and not for In app handling for the AppIntent.
Can we not launch our application from AppIntent extension?
I have a bundled application that contains a widget extension. On launching the application once the widget appears in the widget gallery, However, I have observed that If my widget extension is not sandboxed, the widget fails to show in the widget gallery. Is this expected? I am using the same xcode project and just that AppSandbox capability for the widget extension target is causing this. Can someone please explain why is this happening?
I wanted to identify the shutdown event in macOS, so that If my application is running and the user performs a system shutdown then my application could be notified of the shutdown event and perform finalization.
I came across NSWorkspaceWillPowerOffNotification which is exactly what I require, however, I created a sample application to observe for this notification. Is is observed that right before the system shuts down, the OS terminates my application invoking applicationWillTerminate(_:) delegate and the observer method for 'NSWorkspaceWillPowerOffNotification' is not invoked.
I could perform my finalization in the applicationWillTerminate, but I wanted to know why is the observer not getting invoked. Also why is NSWorkspaceWillPowerOffNotification, even provided by apple when it invoked the termination delegate before shutdown?
below is how I m adding the observer:
NotificationCenter.default.addObserver(forName: NSWorkspace.willPowerOffNotification, object: nil, queue: nil, using: AppDelegate.handlePowerOffNotification)
Below is my observer function, which just logs:
public static func handlePowerOffNotification(_ notification: Notification) {
NSLog (AppDelegate.TAG + "System will power off soon! Perform any necessary cleanup tasks.")
// custom logger to log to a file
TWLog.Log ("System will power off soon! Perform any necessary cleanup tasks.")
}
Can someone update about the current state of the Automator app in macOS. Automator seems like a valuable tool for automating tasks on macOS but in the recent years I have noticed a growing emphasis on the Shortcuts app for automation.
It would be great if you could clarify the following:
• Current Status of Automator: Is there any official statement regarding the continued support of the Automator app in future macOS versions?
• Future of Automator: Does Apple plan to introduce new features or updates for Automator in upcoming releases?
• Indifference to Shortcuts App: From what I understand both the ‘Automator’ and the ‘Shortcuts’ app are used for creating workflows/shortcuts to automate tasks. What is it that Automator app has to offer which cannot be done using the Shortcuts app? assuming the continued support for the Automator app. Can all the automator workflows not be automated using the shortcuts app?
I understand that Apple is constantly innovating and introducing new tools. However, clarity regarding the future of Automator would be helpful for users like myself.
In addition, as a developer I wanted to offer some actions for my application in the Automator app, so that the user can make use of it to create some workflows. But from what I found in the apple documentation here, these action are created using the ‘Automator action’ Project type template in the xcode. However, in the current version of xcode 15, this project type seems to be missing. Does it indicate that apple no longer provides support for applications to create new automator action? If not, how can I provide automator actions for my xcode application?
I have created an intent using AppIntent and this intent(TWIntent in the code below) can be seen in the shortcuts app as an action to create the shortcut.
I am using AppShortcutProvider to create the shortcut so that user can directly make use of it. However, my shortcut does not appear in the shortcut app. The phrases used also do not launch the intent in the spotlight search. Below is my AppShortcutProvider file:
@available(macOS 13.0, *)
struct TWShortcuts: AppShortcutsProvider {
static var appShortcuts: [AppShortcut] {
AppShortcut(
intent: TWIntent(),
phrases: [
"Open Intent in \(.applicationName)",
"Open \(.applicationName) Intent",
"Open my Intent in \(.applicationName)",
"Open my \(.applicationName) Intent",
"Open TWIntent"
],
shortTitle: "Open TWIntent",
systemImageName: "rectangle.stack.fill"
)
}
static var shortcutTileColor: ShortcutTileColor = .lightBlue
}
Is there something I m missing? Also can these phrases be used for siri launch in macOS because the documentation mentions that macOS does not have siri capability?
Below is my AppIntent file:
import SwiftUI
@available(macOS 13, *)
struct TWIntent: AppIntent {
static let title: LocalizedStringResource = "TWIntent"
static var description = IntentDescription("try adding this sample action as your TW shortcut")
//launch app on running action
static var openAppWhenRun: Bool = false
static var parameterSummary: some ParameterSummary {
Summary("Get information on \(\.$TWType)")
}
@Parameter(title: "TWType", description: "The type to get information on.")
var TWType: String
func perform() async throws -> some IntentResult & ReturnsValue<String> & ProvidesDialog {
//perform essential task here to update the application content
return .result(value: TWType, dialog: "Logged a 15 minute break.\(TWType)")
}
}
I have a basic Xcode project where I am adding a swift file with the below AppIntent. This causes the AppIntent action to be added in the Shortcuts app in MacOS. I wanted to know how is this AppIntent directly be able to add the Intent action in the shortcuts app. I have checked the build setting in the Xcode project but I did not find anything being generated that could have caused this. Can someone help me understand what internally happens that causes the action to be added to the shortcuts app?
import AppIntents
import SwiftUI
@available(macOS 13, *)
struct TWIntent: AppIntent {
static let title: LocalizedStringResource = "TWMeditationIntent"
static var description = IntentDescription("try adding this sample action as your TW shortcut")
static var parameterSummary: some ParameterSummary {
Summary("Get information on \(\.$TWType)")
}
// we can have multiple parameter of diff types
@Parameter(title: "TWType", description: "The type to get information on.")
var TWType: String
func perform() async throws -> some IntentResult & ReturnsValue<String> & ProvidesDialog {
NSLog(AppDelegate.TAG + "Inside perform() in MeditationIntent")
return .result(value: TWType, dialog: "Logged a 15 minute break.\(TWType)")
}
}
I have an exception handling frame for an Xcode application in macOS, which contains Cpp and Swift code. I am using the Unix signals frame for handling exceptions using sigaction. My sigaction signal handler get invoked when there is a swift or Cpp exception. However for some exceptions like SIGSEGV, the signal handler gets called repeatedly. To handle this I am using the SA_RESETHAND flag so that the handler gets invoked only once, and then the default action for the signal take over to terminate the process.
This approach works well when an exception occurs due to Cpp code, however when it occurs due to Swift code, the signal handler still gets invoked repeatedly. Can someone explain why is this happening and What is the solution to this?
I wanted to perform handling for the exception in my mac and ios application, I am following this link, where it is suggested to follow either the mach exception handling or use Unix signals. I did not find many resources that could be followed to implement mach exception as suggested. Below are the few resources I could find. Can someone point to the some documentation that apple provides for this or some other helpful documentation.
https://gist.github.com/rodionovd/01fff61927a665d78ecf
I am having a bundled application(.app file) and I am wanting to run this application via ssh session which does not have GUI access. Launching this application in a desktop GUI session, runs the application perfectly. However, on running it on the same machine via ssh session produces an error.
Note: My application does not bring up any GUI window(it' just produces some logs on the terminal), so running it in a non-GUI environment should have worked.
I get the below error when trying to launch the unix exe in the .app bundle( ./Myapp.app/Contents/MacOS/Myapp
) on the terminal. I have observed that applicationDidFinishLaunching(_:) gets called and then the below error occurs.
+[NSXPCSharedListener endpointForReply:withListenerName:replyErrorCode:]: an error occurred while attempting to obtain endpoint for listener 'ClientCallsAuxiliary': Connection interrupted
I tried running other bundled applications via ssh, but all seems to produce the same error. Can someone confirm Is running bundled application in a non GUI session not allowed by Apple. If its allowed, how can I solve this?
Even running the .app file using the open command fails to launch the application, although it produces a different error which is consistent across different applications.