{
	"id": "a9906cd9-e095-4043-9662-a9c801469b71",
	"created_at": "2026-04-06T00:19:14.633977Z",
	"updated_at": "2026-04-10T03:21:15.737924Z",
	"deleted_at": null,
	"sha1_hash": "aa3088211587d7967c08478ed82a58c3766e1e6b",
	"title": "Creating XPC Services",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 605287,
	"plain_text": "Creating XPC Services\r\nPublished: 2016-09-13 · Archived: 2026-04-05 19:35:55 UTC\r\nThe XPC Services API, part of libSystem, provides a lightweight mechanism for basic interprocess\r\ncommunication integrated with Grand Central Dispatch (GCD) and launchd . The XPC Services API allows you\r\nto create lightweight helper tools, called XPC services, that perform work on behalf of your application.\r\nThere are two main reasons to use XPC services: privilege separation and stability.\r\nStability:\r\nLet’s face it; applications sometimes crash. We don’t want it to happen, but it does anyway. Often, certain\r\nparts of an application are more prone to crashes than others. For example, the stability of any application\r\nwith a plug-in API is inherently at the mercy of the authors of plug-ins.\r\nWhen one part of an application is more at risk for crashes, it can be useful to separate out the potentially\r\nunstable functionality from the core of the application. This separation lets you ensure that that, if it\r\ncrashes, the rest of the application is not affected.\r\nPrivilege Separation:\r\nModern applications increasingly rely on untrusted data, such as web pages, files sent by email, and so on.\r\nThis represents a growing attack vector for viruses and other malware.\r\nWith traditional applications, if an application becomes compromised through a buffer overflow or other\r\nsecurity vulnerability, the attacker gains the ability to do anything that the user can do. To mitigate this risk,\r\nMac OS X provides sandboxing—limiting what types of operations a process can perform.\r\nIn a sandboxed environment, you can further increase security with privilege separation—dividing an\r\napplication into smaller pieces that are responsible for a part of the application’s behavior. This allows each\r\npiece to have a more restrictive sandbox than the application as a whole would require.\r\nOther mechanisms for dividing an application into smaller parts, such as NSTask and posix_spawn , do\r\nnot let you put each part of the application in its own sandbox, so it is not possible to use them to\r\nimplement privilege separation. Each XPC service has its own sandbox, so XPC services can make it easier\r\nto implement proper privilege separation.\r\nFor more information about sandboxing, see App Sandbox Design Guide.\r\nUnderstanding the Structure and Behavior\r\nXPC services are managed by launchd , which launches them on demand, restarts them if they crash, and\r\nterminates them (by sending SIGKILL ) when they are idle. This is transparent to the application using the service,\r\nexcept for the case of a service that crashes while processing a message that requires a response. In that case, the\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 1 of 23\n\napplication can see that its XPC connection has become invalid until the service is restarted by launchd .\r\nBecause an XPC service can be terminated suddenly at any time, it must be designed to hold on to minimal state\r\n—ideally, your service should be completely stateless, although this is not always possible.\r\nBy default, XPC services are run in the most restricted environment possible—sandboxed with minimal filesystem\r\naccess, network access, and so on. Elevating a service’s privileges to root is not supported. Further, an XPC\r\nservice is private, and is available only to the main application that contains it.\r\nChoosing an XPC API\r\nBeginning in Mac OS X v10.8, there are two different APIs for working with XPC services: the XPC Services API\r\nand the NSXPCConnection API.\r\nThe NSXPCConnection API is an Objective-C-based API that provides a remote procedure call mechanism,\r\nallowing the client application to call methods on proxy objects that transparently relay those calls to\r\ncorresponding objects in the service helper and vice-versa.\r\nThe XPC Services API is a C-based API that provides basic messaging services between a client application and a\r\nservice helper.\r\nThe XPC Services API is recommended if you need compatibility with Mac OS X v10.7, or if your application\r\nand its service are not based on the Foundation framework. The NSXPCConnection API is recommended for apps\r\nbased on the Foundation framework in Mac OS X v10.8 and later.\r\nThe NSXPCConnection API\r\nThe NSXPCConnection API is part of the Foundation framework, and is described in the NSXPCConnection.h\r\nheader file. It consists of the following pieces:\r\nNSXPCConnection —a class that represents the bidirectional communication channel between two\r\nprocesses. Both the application and the service helper have at least one connection object.\r\nNSXPCInterface —a class that describes the expected programmatic behavior of the connection (what\r\nclasses can be transmitted across the connection, what objects are exposed, and so on).\r\nNSXPCListener —a class that listens for incoming XPC connections. Your service helper must create one\r\nof these and assign it a delegate object that conforms to the NSXPCListenerDelegate protocol.\r\nNSXPCListenerEndpoint —a class that uniquely identifies an NSXPCListener instance and can be sent to\r\na remote process using NSXPCConnection . This allows a process to construct a direct communication\r\nchannel between two other processes that otherwise could not see one another.\r\nIn addition, the header contains a few constants, described in NSXPCConnection Constants Reference.\r\nThe XPC Services API\r\nThe (C-based) XPC Services API consists of two main pieces:\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 2 of 23\n\nxpc.h —APIs for creating and manipulating property list objects and APIs that daemons use to reply to\r\nmessages.\r\nBecause this API is at the libSystem level, it cannot depend on Core Foundation. Also, not all CF types can\r\nbe readily shared across process boundaries. XPC supports connection types such as file descriptors in its\r\nobject graphs, which are not supported by CFPropertyList because it was designed as a persistent storage\r\nformat, whereas XPC was designed as an IPC format. For these reasons, the XPC API uses its own\r\ncontainer that supports only the primitives that are practical to transport across process boundaries.\r\nSome higher-level types can be passed across an XPC connection, although they do not appear in the\r\nxpc.h header file (because referencing higher level frameworks from libSystem would be a layering\r\nviolation). For example, the IOSurfaceCreateXPCObject and IOSurfaceLookupFromXPCObject functions\r\nallow you to pass an IOSurface object between the XPC service that does the drawing and the main\r\napplication.\r\nconnection.h —APIs for connecting to an XPC service. This service is a special helper bundle embedded\r\nin your app bundle.\r\nA connection is a virtual endpoint; it is independent of whether an actual instance of the service binary is\r\nrunning. The service binary is launched on demand.\r\nA connection can also be sent as a piece of data in an XPC message. Thus, you can pass a connection\r\nthrough XPC to allow one service to communicate with another service (for example).\r\nCreating the Service\r\nAn XPC service is a bundle in the Contents/XPCServices directory of the main application bundle; the XPC\r\nservice bundle contains an Info.plist file, an executable, and any resources needed by the service. The XPC\r\nservice indicates which function to call when the service receives messages by calling xpc_main(3) Mac OS X\r\nDeveloper Tools Manual Page from its main function.\r\nTo create an XPC service in Xcode, do the following:\r\n1. Add a new target to your project, using the XPC Service template.\r\n2. Add a Copy Files phase to your application’s build settings, which copies the XPC service into the\r\nContents/XPCServices directory of the main application bundle.\r\n3. Add a dependency to your application’s build settings, to indicate it depends on the XPC service bundle.\r\n4. If you are writing a low-level (C-based) XPC service, implement a minimal main function to register\r\nyour event handler, as shown in the following code listing. Replace my_event_handler with the name of\r\nyour event handler function.\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 3 of 23\n\nint main(int argc, const char *argv[]) {\r\n xpc_main(my_event_handler);\r\n \r\n // The xpc_main() function never returns.\r\n exit(EXIT_FAILURE);\r\n}\r\nIf you are writing a high-level (Objective-C-based) service using NSXPCConnection , first create a\r\nconnection delegate class that conforms to the NSXPCListenerDelegate protocol. Then, implement a\r\nminimal main function that creates and configures a listener object, as shown in the following code\r\nlisting.\r\nint main(int argc, const char *argv[]) {\r\n MyDelegateClass *myDelegate = ...\r\n NSXPCListener *listener =\r\n [NSXPCListener serviceListener];\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 4 of 23\n\nlistener.delegate = myDelegate;\r\n [listener resume];\r\n \r\n // The resume method never returns.\r\n exit(EXIT_FAILURE);\r\n}\r\nThe details of this class are described further in Using the Service.\r\n5. Add the appropriate key/value pairs to the helper’s Info.plist to tell launchd the name of the service.\r\nThese are described in XPC Service Property List Keys.\r\nUsing the Service\r\nThe way you use an XPC service depends on whether you are working with the C API (XPC Services) or the\r\nObjective-C API ( NSXPCConnection ).\r\nUsing the Objective-C NSXPCConnection API\r\nThe Objective-C NSXPCConnection API provides a high-level remote procedure call interface that allows you to\r\ncall methods on objects in one process from another process (usually an application calling a method in an XPC\r\nservice). The NSXPCConnection API automatically serializes data structures and objects for transmission and\r\ndeserializes them on the other end. As a result, calling a method on a remote object behaves much like calling a\r\nmethod on a local object.\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 5 of 23\n\nTo use the NSXPCConnection API, you must create the following:\r\nAn interface. This mainly consists of a protocol that describes what methods should be callable from the\r\nremote process. This is described in Designing an Interface\r\nA connection object on both sides. On the service side, this was described previously in Creating the\r\nService. On the client side, this is described in Connecting to and Using an Interface.\r\nA listener. This code in the XPC service accepts connections. This is described in Accepting a Connection\r\nin the Helper.\r\nMessages.\r\nFigure 4-1 shows how these pieces fit together.\r\nFigure 4-1  The NSXPC architecture\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 6 of 23\n\nIn some cases, you may need to further tweak the protocol to whitelist additional classes for use in collection\r\nparameters or to proxy certain objects instead of copying them. This is described further in Working with Custom\r\nClasses.\r\nOverall Architecture\r\nWhen working with NSXPCConnection -based helper apps, both the main application and the helper have an\r\ninstance of NSXPCConnection . The main application creates its connection object itself, which causes the helper\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 7 of 23\n\nto launch. A delegate method in the helper gets passed its connection object when the connection is established.\r\nThis is illustrated in Figure 4-1.\r\nEach NSXPCConnection object provides three key features:\r\nAn exportedInterface property that describes the methods that should be made available to the opposite\r\nside of the connection.\r\nAn exportedObject property that contains a local object to handle method calls coming in from the other\r\nside of the connection.\r\nThe ability to obtain a proxy object for calling methods on the other side of the connection.\r\nWhen the main application calls a method on a proxy object, the XPC service’s NSXPCConnection object calls\r\nthat method on the object stored in its exportedObject property.\r\nSimilarly, if the XPC service obtains a proxy object and calls a method on that object, the main app’s\r\nNSXPCConnection object calls that method on the object stored in its exportedObject property.\r\nDesigning an Interface\r\nThe NSXPCConnection API takes advantage of Objective-C protocols to define the programmatic interface\r\nbetween the calling application and the service. Any instance method that you want to call from the opposite side\r\nof a connection must be explicitly defined in a formal protocol. For example:\r\n@protocol FeedMeACookie\r\n - (void)feedMeACookie: (Cookie *)cookie;\r\n@end\r\nBecause communication over XPC is asynchronous, all methods in the protocol must have a return type of void .\r\nIf you need to return data, you can define a reply block like this:\r\n@protocol FeedMeAWatermelon\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 8 of 23\n\n- (void)feedMeAWatermelon: (Watermelon *)watermelon\r\n reply:(void (^)(Rind *))reply;\r\n@end\r\nA method can have only one reply block. However, because connections are bidirectional, the XPC service helper\r\ncan also reply by calling methods in the interface provided by the main application, if desired.\r\nEach method must have a return type of void , and all parameters to methods or reply blocks must be either:\r\nArithmetic types ( int , char , float , double , uint64_t , NSUInteger , and so on)\r\nBOOL\r\nC strings\r\nC structures and arrays containing only the types listed above\r\nObjective-C objects that implement the NSSecureCoding protocol.\r\nConnecting to and Using an Interface\r\nOnce you have defined the protocol, you must create an interface object that describes it. To do this, call the\r\ninterfaceWithProtocol: method on the NSXPCInterface class. For example:\r\nNSXPCInterface *myCookieInterface =\r\n [NSXPCInterface interfaceWithProtocol:\r\n @protocol(FeedMeACookie)];\r\nOnce you have created the interface object, within the main app, you must configure a connection with it by\r\ncalling the initWithServiceName: method. For example:\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 9 of 23\n\nNSXPCConnection *myConnection = [[NSXPCConnection alloc]\r\n initWithServiceName:@\"com.example.monster\"];\r\nmyConnection.remoteObjectInterface = myCookieInterface;\r\n[myConnection resume];\r\nFigure 4-2 shows the basic steps in this process. Note that only the first four steps are described in this section.\r\nFigure 4-2  The NSXPC connection process\r\nAt this point, the main application can call the remoteObjectProxy or remoteObjectProxyWithErrorHandler:\r\nmethods on the myConnection object to obtain a proxy object. This object acts as a proxy for the object that the\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 10 of 23\n\nXPC service has set as its exported object (by setting the exportedObject property). This object must conform to\r\nthe protocol defined by the remoteObjectInterface property.\r\nWhen your application calls a method on the proxy object, the corresponding method is called on the exported\r\nobject inside the XPC service. When the service’s method calls the reply block, the parameter values are serialized\r\nand sent back to the application, where the parameter values are deserialized and passed to the reply block. (The\r\nreply block executes within the application’s address space.)\r\nAccepting a Connection in the Helper\r\nAs shown in Figure 4-2, when an NSXPCConnection -based helper receives the first message from a connection,\r\nthe listener delegate’s listener:shouldAcceptNewConnection: method is called with a listener object and a\r\nconnection object. This method lets you decide whether to accept the connection or not; it should return YES to\r\naccept the connection or NO to refuse the connection.\r\nIn addition to making policy decisions, this method must configure the connection object. In particular, assuming\r\nthe helper decides to accept the connection, it must set the following properties on the connection:\r\nexportedInterface —an interface object that describes the protocol for the object you want to export.\r\n(Creating this object was described previously in Connecting to and Using an Interface.)\r\nexportedObject —the local object (usually in the helper) to which the remote client’s method calls should\r\nbe delivered. Whenever the opposite end of the connection (usually in the application) calls a method on\r\nthe connection’s proxy object, the corresponding method is called on the object specified by the\r\nexportedObject property.\r\nAfter setting those properties, it should call the connection object’s resume method before returning YES .\r\nAlthough the delegate may defer calling resume , the connection will not receive any messages until it does so.\r\nSending Messages\r\nSending messages with NSXPC is as simple as making a method call. For example, given the interface\r\nmyCookieInterface (described in previous sections) on the XPC connection object myConnection , you can call\r\nthe feedMeACookie method like this:\r\nCookie *myCookie = ...\r\n \r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 11 of 23\n\n[[myConnection remoteObjectProxy] feedMeACookie: myCookie];\r\nWhen you call that method, the corresponding method in the XPC helper is called automatically. That method, in\r\nturn, could use the XPC helper’s connection object similarly to call a method on the object exported by the main\r\napplication.\r\nHandling Errors\r\nIn addition to any error handling methods specific to a given helper’s task, both the XPC service and the main app\r\nshould also provide the following XPC error handler blocks:\r\nInterruption handler—called when the process on the other end of the connection has crashed or has\r\notherwise closed its connection.\r\nThe local connection object is typically still valid—any future call will automatically spawn a new helper\r\ninstance unless it is impossible to do so—but you may need to reset any state that the helper would\r\notherwise have kept.\r\nThe handler is invoked on the same queue as reply messages and other handlers, and it is always executed\r\nafter any other messages or reply block handlers (except for the invalidation handler). It is safe to make\r\nnew requests on the connection from an interruption handler.\r\nInvalidation handler—called when the invalidate method is called or when an XPC helper could not be\r\nstarted. When this handler is called, the local connection object is no longer valid and must be recreated.\r\nThis is always the last handler called on a connection object. When this block is called, the connection\r\nobject has been torn down. It is not possible to send further messages on the connection at that point,\r\nwhether inside the handler or elsewhere in your code.\r\nIn both cases, you should use block-scoped variables to provide enough contextual information—perhaps a\r\npending operation queue and the connection object itself—so that your handler code can do something sensible,\r\nsuch as retrying pending operations, tearing down the connection, displaying an error dialog, or whatever other\r\nactions make sense in your particular app.\r\nWorking with Custom Classes\r\nThe NSXPCConnection class limits what objects can be passed over a connection. By default, it allows only\r\nknown-safe classes—Foundation collection classes, NSString , and so on. You can identify these classes by\r\nwhether they conform to the NSSecureCoding protocol.\r\nOnly classes that conform to this protocol can be sent to an NSXPCConnection -based helper. If you need to pass\r\nyour own classes as parameters, you must ensure that they conform to the NSSecureCoding protocol, as described\r\nbelow.\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 12 of 23\n\nHowever, this is not always sufficient. You need to do extra work in two situations:\r\nIf you are passing the object inside a collection (dictionary, array, and so on).\r\nIf you need to pass the object by proxy instead of copying the object.\r\nAll three cases are described in the sections that follow.\r\nConforming to NSSecureCoding\r\nAll objects passed over an NSXPC connection must conform to NSSecureCoding . to do this, your class must do\r\nthe following:\r\nDeclare support for secure coding. Override the supportsSecureCoding method, and make it return\r\nYES .\r\nDecode singleton class instances safely. If the class overrides its initWithCoder: method, when\r\ndecoding any instance variable, property, or other value that contains an object of a non-collection class\r\n(including custom classes) always use decodeObjectOfClass:forKey: to ensure that the data is of the\r\nexpected type.\r\nDecode collection classes safely. Any non-collection class that contains instances of collection classes\r\nmust override the initWithCoder: method. In that method, when decoding the collection object or\r\nobjects, always use decodeObjectOfClasses:forKey: and provide a list of any objects that can appear\r\nwithin the collection.\r\nWhen generating the list of classes to allow within a decoded collection class, you should be aware of two things.\r\nFirst, Apple collection classes are not automatically whitelisted by the decodeObjectOfClasses:forKey: method,\r\nso you must include them explicitly in the array of class types.\r\nSecond, you should list only classes that are direct members of the collection object graph that you are decoding\r\nwithout any intervening non-collection classes.\r\nFor example, if you have an array of dictionaries, and one of those dictionaries might contain an instance of a\r\ncustom class called OuterClass , and OuterClass has an instance variable of type InnerClass, you must include\r\nOuterClass in the list of classes because it is a direct member of the collection tree. However, you do not need to\r\nlist InnerClass because there is a non-collection object between it and the collection tree.\r\nFigure 4-3 shows some examples of when whitelisting is required and shows when classes must provide\r\noverridden initWithCoder : methods.\r\nFigure 4-3  Whitelisting and secure coding examples\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 13 of 23\n\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 14 of 23\n\nWhitelisting a Class for Use Inside Containers\r\nMost of the time, custom classes passed through method parameters can be automatically whitelisted based upon\r\nthe method’s signature. However, when a method specifies a collection class ( NSArray , NSDictionary , and so\r\non) as the parameter type, the compiler has no way to determine what classes should be allowed to appear within\r\nthat container. For this reason, if your methods take collection class instances as parameters, you must explicitly\r\nwhitelist any classes that can appear within those containers.\r\nFor every method in your interface that takes a collection class as a parameter, you must determine what classes\r\nshould be allowed as members.\r\nYou should whitelist only classes that can be members of any top-level collection objects. If you whitelist classes\r\nat the top level unnecessarily, those objects are allowed to appear within the top-level collection objects, which is\r\nnot what you want. In particular:\r\nApple-provided classes that support property list serialization (such as other collection classes) are\r\nautomatically whitelisted for you. It is never necessary to whitelist these classes at the top level.\r\nFor the most up-to-date list of classes supported by property list serialization, read Serializing Property\r\nLists in Archives and Serializations Programming Guide.\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 15 of 23\n\nDon’t whitelist custom classes if they are allowed only inside instances of other custom classes. If the\r\nenclosing class correctly conforms to NSSecureCoding , such whitelisting is not required. For more details,\r\nread Conforming to NSSecureCoding.\r\nFor example, suppose you have the following class and protocol:\r\n@interface FrenchFry\r\n...\r\n@end\r\n \r\n@protocol FeedMeABurgerAndFries\r\n - (void)feedMeFries: (NSArray *)pommesFrites;\r\n - (void)feedMeABurger: (Burger *)aBurger;\r\n@end\r\nAssuming the pommesFrites array is an array of FrenchFry objects (as the name implies), you would whitelist\r\nthe array of FrenchFry objects as follows:\r\n// Create the interface\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 16 of 23\n\nNSXPCInterface *myBurgerInterface =\r\n [NSXPCInterface interfaceWithProtocol:\r\n @protocol(FeedMeABurgerAndFries)];\r\n \r\n// Create a set containing the allowed\r\n// classes.\r\nNSSet *expectedClasses =\r\n [NSSet setWithObjects:[NSArray class], [FrenchFry class], nil];\r\n \r\n[myBurgerInterface\r\n setClasses: expectedClasses\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 17 of 23\n\nforSelector: @selector(feedMeFries:)\r\n argumentIndex: 0 // the first parameter\r\n ofReply: NO // in the method itself.\r\n];\r\nThe first parameter to a method is parameter 0, followed by parameter 1, and so on.\r\nIn this case, the value NO is passed for the ofReply parameter because this code is modifying the whitelist for\r\none of the parameters of the method itself. If you are whitelisting a class for a parameter of the method’s reply\r\nblock, pass YES instead.\r\nPassing an Object By Proxy\r\nMost of the time, it makes sense to copy objects and send them to the other side of a connection. Passing objects\r\nby copying is the most straightforward way to use NSXPC, and should be used wherever possible.\r\nHowever, copying objects is not always desirable. In particular:\r\nIf you need to share a single instance of the data between the client application and the helper, you must\r\npass the objects by proxy.\r\nIf an object needs to call methods on other objects within your application that you cannot or do not wish\r\nto pass across the connection (such as user interface objects), then you must pass an object by proxy—\r\neither the caller, the callee (where possible), or a relay object that you construct specifically for that\r\npurpose.\r\nThe downside to passing objects by proxy is that performance is significantly reduced (because every access to the\r\nobject requires interprocess communication). For this reason, you should pass objects by proxy only if it is not\r\npossible to pass them by copying.\r\nYou can configure additional proxy objects similarly to the way you configured the remoteObjectInterface\r\nproperty of the initial connection. First, identify which parameter to a method should be passed by proxy, then\r\nspecify an NSXPCInterface object that defines the interface for that object.\r\nSuppose, for example, that you have a class conforming to the following protocol:\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 18 of 23\n\n@protocol FeedSomeone\r\n - (void)feedSomeone:\r\n (id \u003cFeedMeACookie\u003e)someone;\r\n@end\r\n \r\n...\r\n \r\nNSXPCInterface *myFeedingInterface =\r\n [NSXPCInterface interfaceWithProtocol:\r\n @protocol(FeedSomeone)];\r\nIf you want to pass the first parameter to that method by proxy, you would configure the interface like this:\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 19 of 23\n\n// Create an interface object that describes\r\n// the protocol for the object you want to\r\n// pass by proxy.\r\nNSXPCInterface *myCookieInterface =\r\n [NSXPCInterface interfaceWithProtocol:\r\n @protocol(FeedMeACookie)];\r\n \r\n// Create an object of a class that\r\n// conforms to the FeedMeACookie protocol\r\nMonster *myMonster = ...\r\n \r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 20 of 23\n\n[myFeedingInterface\r\n setInterface: myCookieInterface\r\n forSelector: @selector(sendOtherProxy:)\r\n argumentIndex: 0 // the first parameter of\r\n ofReply: NO // the feedSomeone: method\r\n];\r\nThe first parameter to a method is parameter 0, followed by parameter 1, and so on.\r\nIn this case, the value NO is passed for the ofReply parameter because this code is modifying the whitelist for\r\none of the parameters of the method itself. If you are whitelisting a class for a parameter of the method’s reply\r\nblock, pass YES instead.\r\nUsing the C XPC Services API\r\nTypical program flow is as follows:\r\n1. An application calls xpc_connection_create(3) Mac OS X Developer Tools Manual Page to create an an\r\nXPC connection object.\r\n2. The application calls some combination of xpc_connection_set_event_handler(3) Mac OS X Developer\r\nTools Manual Page or xpc_connection_set_target_queue(3) Mac OS X Developer Tools Manual Page\r\nas needed to configure connection parameters prior to actually connecting to the service.\r\n3. The application calls xpc_connection_resume(3) Mac OS X Developer Tools Manual Page to begin\r\ncommunication.\r\n4. The application sends messages to the service using xpc_connection_send_message(3) Mac OS X\r\nDeveloper Tools Manual Page , xpc_connection_send_message_with_reply(3) Mac OS X Developer\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 21 of 23\n\nTools Manual Page , or xpc_connection_send_message_with_reply_sync(3) Mac OS X Developer Tools\r\nManual Page .\r\n5. When you send the first message, the launchd daemon searches your application bundle for a service\r\nbundle whose CFBundleIdentifier value matches the specified name, then launches that XPC service\r\ndaemon on demand.\r\n6. The event handler function (specified in the service’s Info.plist file) is called with the message. The\r\nevent handler function runs on a queue whose name is the name of the XPC service.\r\n7. If the original message was sent using xpc_connection_send_message_with_reply(3) Mac OS X Developer\r\nTools Manual Page or xpc_connection_send_message_with_reply_sync(3) Mac OS X Developer Tools\r\nManual Page , the service must reply using xpc_dictionary_create_reply(3) Mac OS X Developer Tools\r\nManual Page , then uses xpc_dictionary_get_remote_connection(3) Mac OS X Developer Tools Manual\r\nPage to obtain the client connection and xpc_connection_send_message(3) Mac OS X Developer Tools\r\nManual Page , xpc_connection_send_message_with_reply(3) Mac OS X Developer Tools Manual Page ,\r\nor xpc_connection_send_message_with_reply_sync(3) Mac OS X Developer Tools Manual Page to send\r\nthe reply dictionary back to the application.\r\nThe service can also send a message directly to the application with xpc_connection_send_message(3) Mac\r\nOS X Developer Tools Manual Page .\r\n8. If a reply was sent by the service, the handler associated with the previous message is called upon receiving\r\nthe reply. The reply can be put on a different queue than the one used for incoming messages. No serial\r\nrelationship is guaranteed between reply messages and non-reply messages.\r\n9. If an error occurs (such as the connection closing), the connection’s event handler (set by a previous call to\r\nxpc_connection_set_event_handler(3) Mac OS X Developer Tools Manual Page ) is called with an\r\nappropriate error, as are (in no particular order) the handlers for any outstanding messages that are still\r\nawaiting replies.\r\n10. At any time, the application can call xpc_connection_suspend(3) Mac OS X Developer Tools Manual\r\nPage when it needs to suspend callbacks from the service. All suspend calls must be balanced with resume\r\ncalls. It is not safe to release the last reference to a suspended connection.\r\n11. Eventually, the application calls xpc_connection_cancel(3) Mac OS X Developer Tools Manual Page to\r\nterminate the connection.\r\nNote: Either side of the connection can call xpc_connection_cancel(3) Mac OS X Developer Tools\r\nManual Page . There is no functional difference between the application canceling the connection and the\r\nservice canceling the connection.\r\nXPC Service Property List Keys\r\nXPC requires you to specify a number of special key-value pairs in the Info.plist file within the service\r\nhelper’s bundle. These keys are listed below.\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 22 of 23\n\nCFBundleIdentifier\r\nString. The name of the service in reverse-DNS style (for example, com.example.myapp.myservice ). (This\r\nvalue is filled in by the XPC Service template.)\r\nCFBundlePackageType\r\nString. Value must be XPC! to identify the bundle as an XPC service. (This value is filled in by the XPC\r\nService template.)\r\nXPCService\r\nDictionary. Contains the following keys:\r\nKey Value\r\nEnvironmentVariables Dictionary. The variables which are set in the environment of the service.\r\nJoinExistingSession\r\nBoolean. Indicates that your service runs in the same security session as\r\nthe caller.\r\nThe default value is False , which indicates that the service is run in a\r\nnew security session.\r\nSet the value to True if the service needs to access to the user’s keychain,\r\nthe pasteboard, or other per-session resources and services.\r\nRunLoopType\r\nString. Indicates the type of run loop used for the service. The default\r\nvalue is dispatch_main , which uses the dispatch_main(3) Mac OS X\r\nDeveloper Tools Manual Page function to set up a GCD-style run loop.\r\nThe other supported value is NSRunLoop , which uses the NSRunLoop\r\nclass to set up a run loop.\r\nSource: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.ht\r\nml#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW1"
	],
	"report_names": [
		"10000172i-SW6-SW1"
	],
	"threat_actors": [],
	"ts_created_at": 1775434754,
	"ts_updated_at": 1775791275,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/aa3088211587d7967c08478ed82a58c3766e1e6b.pdf",
		"text": "https://archive.orkl.eu/aa3088211587d7967c08478ed82a58c3766e1e6b.txt",
		"img": "https://archive.orkl.eu/aa3088211587d7967c08478ed82a58c3766e1e6b.jpg"
	}
}