if let url = URL(string:UIApplication.openSettingsURLString) { if UIApplication.shared.canOpenURL(url) { UIApplication.shared.open(url, options: [:], completionHandler: nil) } }As from apple doc i use above method to open iphone setting from app but unfortuantely its going to app setting rather than IphoneSetting I am using swift version 4.2 not sure whats the issue

I have successfully implemented Universal Links so that a visitor to specific URLs on our site is redirected to one of our apps. It all works well. Alarmingly well, in that it all worked perfectly first time. (I blame the documentation). A question I can't find specifically addressed in the documentation is: what if we have two apps that can both handle a given link? This is in fact our situation. In most cases users will have one or other of the apps installed. The correct behaviour would then be to direct the user to the installed app. In some cases the user will have both apps installed. In that case the ideal behaviour would be to direct the user to what we have defined to be the "main" app. It looks to me as if it is possible to two apps in an apple-app-site-association file, but not having found this in the documentation, I wonder: has anyone on here actually tried this? Did it work as expected?

I have written C software that makes extensive use of shared memory (200MB using shmget, etc.), which compiled and ran on Mojave and Linux. Using this shared memory required /etc/sysctl.conf to increase the buffer sizes during OSX boot. It appears that Catalina no longer uses my /etc/sysctl.conf file, whether SIP is enabled or disabled. Now the software compiles but fails to run, because the default shared memory size (4MB) is too small on Catalina. How do I specify the shared memory parameters to increase above the default in Catalina? kern.sysv.shmmax=268435456 kern.sysv.shmmin=1 #kern.sysv.shmmni=128 kern.sysv.shmseg=32 kern.sysv.shmall=65536

Hi, I have a macOS application say Main.app which uses Helper App say Helper.app with UI support. Helper.app is placed inside Main.app/Contents/Library/LoginItems/Helper.app. Helper.app is launched using NSWorkSpace and when user opts to launch Helper.app on login, SMLoginItemSetEnabled is turned ON for Helper.app. Main.app and Helper.app communicate with each other via NSConnection.  Helper app supports set of features based on some Condition and same condition is used to validate a feature in Main.app. Hence, Main.app talks to Helper.app to check if a feature can be validated. 1) Can someone write their version of Helper.app with same bundle identifier as my Helper.app and expose a connection with same name (when my Main.app and Helper.app is not running). 2) Now when Main.app is launched, it get connected to 3rd party Helper.app. There are two versions of Main.app Main.app and Helper.app both are sandboxed and Belong to same group. Main.app and Helper.app both are not sandboxed (But, hardened run time is enabled). Groups are not defined. Thank you. Regards, Deepa

Hello - TLDR - Is there any sample code to demonstrate how one goes about creating dedicated XPCServices to wrap ARM and Intel-specific dylibs? We have an app we're looking at moving to a universal binary. In that same app we have a framework that currently wraps R functionality by directly linking to /Library/Frameworks/R.framework/Current . R now has dedicated Intel and ARM builds (https://mac.r-project.org/) After watching the 2020 WWDC session "Port your Mac app to Apple silicon" (https://developer.apple.com/videos/play/wwdc2020/10214/?time=2006), it sounds like, for us to deploy a universal binary I should look at wrapping the R interaction bits into dedicated ARM and Intel XPC services so the appropriate architecture for R will run. Is anyone aware of any sample code or extended documentation demonstrating the ins and outs of how to think about this? Thank you

Can we access and perform actions over the UIElements of other apps from my app in iOS? For example: Suppose i want to access the button of Whatsapp, and Uber from my app.

My IDE like app built with electron allows to spawn a terminal by means of forkpty. Although this is also working in the MAS build, the sandboxed environment results in the terminal being mostly unusable (which I expected). From a technical perspective, what would be the best way to allow an unrestricted terminal experience? Obviously I'd need the terminal process to be spawned outside the sandboxed environment. My initial thinking was that I could create some kind of "Helper" app that the user has to run manually. This app would then run outside the sandbox and would provide a terminal API to my sandboxed app by means of TCP or IPC Socket communication. But this would have multple drawbacks: Uncomfortable for the user because he has to spawn the helper app The communication sockets could be abused by others I'm sure there exist many other apps on the Mac App Store that face the same problem (running a process outside the sandboxed environment). What is the best way to solve this? Is it even allowed?

Hi All, I have coded a TCP Server packaged inside C++ static library. I am using this static library within the iOS Swift UI application. I have coded a simple UI which has a button, on click of which I want to start the TCP server (which is written in C++ and inside the linked static library). After the TCP server is started, I want to push the application to background and then run the client application which is going to interact with this TCP server from the backgrounded SwiftUI application. I want the TCP server to be running even the application goes to the background mode as I have another user interface application which is going to interact with the TCP server on the same device. I tried using background task, but I don't know whether I am doing something wrong there, or I cannot achieve what I want using the BackgroundTask functionality available in iOS. The main thing here is, the TCP server code is in C++ inside static library and I want to start the TCP server from SwiftUI application layer. I have managed to call C++ function from Swift that part is available. Can anyone show me the right path here ? How do I keep the BSD Socket based TCP Server active while the application is in Background mode ?

I have an application that upon installation, registers a custom URL protocol (scheme) like foo:// using the lsregister command line tool. Recently I noticed that the custom URL protocol is missing after an upgrade of macOS (Catalina to Big Sur). It appears that the upgrade de-registers the custom URL protocol while my application is still installed as it was before the macOS upgrade.Yet, any application functionality depending on its custom URL protocol is broken. The only workaround seems to reinstall my application, or at minimum re-register the custom URL protocol manually. Is this expected behavior for macOS upgrades? Do applications need to re-register any custom URL protocol again after a macOS upgrade? Why are these not retained as one would expect?

I'm opening a different thread to a question that was asked about a year ago. I'm trying to get the output of "which" so that I can automatically find programs for the user. I've used the code that was provided in that thread which is:  func launch(tool: URL, arguments: [String], completionHandler: @escaping (Int32, Data) -> Void) throws {         let group = DispatchGroup()         let pipe = Pipe()         var standardOutData = Data()         group.enter()         let proc = Process()         proc.executableURL = tool         proc.arguments = arguments         proc.standardOutput = pipe.fileHandleForWriting         proc.terminationHandler = { _ in             proc.terminationHandler = nil             group.leave()         }         group.enter()         DispatchQueue.global().async {             // Doing long-running synchronous I/O on a global concurrent queue block             // is less than ideal, but I’ve convinced myself that it’s acceptable             // given the target ‘market’ for this code.             let data = pipe.fileHandleForReading.readDataToEndOfFile()             pipe.fileHandleForReading.closeFile()             DispatchQueue.main.async {                 standardOutData = data                 group.leave()             }         }         group.notify(queue: .main) {             completionHandler(proc.terminationStatus, standardOutData)         }         try proc.run()         // We have to close our reference to the write side of the pipe so that the         // termination of the child process triggers EOF on the read side.         pipe.fileHandleForWriting.closeFile()     } it works fine for all of the normal command line routines but not for custom ones such as avr-gcc or any other that is installed via homebrew. I can use "which avr-gcc" in terminal and it shows the path just fine but in my app it returns nothing where as if I search for the path of something like ls in my app it returns it just fine. What could be the cause of this?

I've got an mach-o executable that runs from launchDaemon plist file, and is communicating with other processes using unix domain socket. The file that backs this socket created in /tmp. However, this cause the executable to fail reading the file unless given full disk access. I'd like to find a location for the socket file, which is shared to all processes and doesn't require full disk access. the executable reside in /Library/Application Support/myProj/bin/exec_file is there such location ? Perhaps can i use the same location of the executable itself ?

Running a child process using Process (or NSTask in Objective-C) is easy, but piping data to and from the child’s stdin and stdout is surprisingly tricky. I regularly see folks confused by this. Moreover, it’s easy to come up with a solution that works most of the time, but suffers from weird problems that only show up in the field [1]. I recently had a couple of DTS incidents from folks struggling with this, so I sat down and worked through the details. Pasted below is the results of that effort, namely, a single function that will start a child process, pass it some data on stdin, read the data from the child’s stdout, and call a completion handler when everything is done. There are some things to note here, some obvious, some not so much: I’ve included Swift and Objective-C versions of the code. Both versions work the same way. The Swift version has all the comments. If you decide to base your code on the Objective-C version, copy the comments from there. I didn’t bother collecting stderr. That’s not necessary in many cases and, if you need it, it’s not hard to extend the code to handle that case. I use Dispatch I/O rather than FileHandle to manage the I/O channels. Dispatch I/O is well suited to this task. In contrast, FileHandle has numerous problems working with pipes. For the details, see Whither FileHandle?. This single function is way longer than I’d normally tolerate. This is partly due to the extensive comments and party due to my desire to maintain focus. When wrapping Process it’s very easy to run afoul of architecture astronaut-ism. Indeed, I have a much more full-featured Process wrapper sitting on my hard disk, but that’s going to stay there in favour of this approach (-: Handling a child process correctly involves some gnarly race conditions. The code has extensive comments explaining how I deal with those. If you have any questions or comments about this, put them in a new thread. Make sure to tag that thread with Foundation and Inter-process communication so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Indeed, this post shows that I’ve made this sort of mistake myself )-:

I’m trying to implement a simple cross-process notify/observe system, using a pthread mutex and condition variable in shared (mapped) memory. It seems to be working fine (on macOS 11.6) if one process calls pthread_cond_wait and then another calls pthread_cond_broadcast — the waiting process indeed wakes up. However, if two processes try to observe at the same time, the second one's call to pthread_cond_wait fails with EINVAL. I’m wondering if I’m just doing something wrong in my setup, or if this sort of usage isn’t supported. Basically I create and mmap a file, initialize a pthread mutex and condition in the mapped memory using the setpshared attributes, then lock the mutex and notify or wait on the condition. Actual source code here: Here’s the code that does the pthreads stuff Here’s the outer code that opens and mmaps the file I’m aware that there are a few dozen 🙄 Apple IPC APIs that are probably preferred over these POSIX ones. I’ve used some in the past. I’m doing it this way because: (a) this is in a cross-platform project and it would be nice to share code between Unix platforms, at least Darwin and Linux; (b) the thing I’m notifying/observing about is a database file, so tying the notifications to a side file next to the database provides ideal scoping; (c) it’s similar in principle to the usage of shared memory for locking in SQLite and LMDB. (The difference is, I’m doing notification not locking.) Any advice? —Jens

Hello, We created a sample app delegate to test whether applicationDidFinishLaunching runs as expected or not (code as follows). The observed behavior was that the executable prints both applicationWillFinishLaunching and applicationDidFinishLaunching in the case when we're using an RDP connection to the mac prints only applicationWillFinishLaunching in case of ssh connection to the mac Why is this behavior different and how can I ensure it runs correctly with ssh? Kindly help. #include <unistd.h> #include <sys/types.h> #include <Foundation/Foundation.h> #import <Cocoa/Cocoa.h> #import <SystemConfiguration/SystemConfiguration.h> #import <SystemConfiguration/SCDynamicStore.h> @interface TWAppKitAppDelegate : NSObject <NSApplicationDelegate> @end @implementation TWAppKitAppDelegate // Launching Applications - (void) applicationWillFinishLaunching: (NSNotification *) pNotification { NSLog(@"applicationWillFinishLaunching"); } - (void) applicationDidFinishLaunching: (NSNotification *) pNotification { NSLog(@"applicationDidFinishLaunching"); } // Managing Active Status - (void) applicationWillBecomeActive: (NSNotification *) pNotification { } - (void) applicationDidBecomeActive: (NSNotification *) pNotification { } - (void) applicationWillResignActive: (NSNotification *) pNotification { } - (void) applicationDidResignActive: (NSNotification *) pNotification { } // Terminating Applications #if 0 - (NSApplicationTerminateReply) applicationShouldTerminate:(NSNotification *) pNotification { return NSApplicationTerminateReply::NSTerminateNow; } #endif - (BOOL) applicationShouldTerminateAfterLastWindowClosed:(NSNotification *) pNotification { return NO; } - (void) applicationWillTerminate:(NSNotification *) pNotification { } - (BOOL) application:(NSApplication *) pSender openFile: (NSString *) pFileName { return YES; } - (void) application:(NSApplication *) pSender openFiles: (NSArray<NSString *> *) pFileNames { } @end int main (int pArgc, char ** pArgv) { NSApplication * app; TWAppKitAppDelegate * appdelegate; app = [NSApplication sharedApplication]; appdelegate = [[TWAppKitAppDelegate alloc] init]; [app setDelegate:appdelegate]; [NSApp run]; //NOTE: Apple never 'returns' from here NSLog(@"Function main called \n"); return 0; }