Is it correct to codesign dylib/framewoks with entitlements? My understanding is that only executables need to have the entitlement and the dylibs loaded in that process will automatically inherit those entitlements. However, I am seeing a lot of scripts on the internet that are signing dylibs as well with entitlements. For eg - # sign *.dylibs find "$APP_BUNDLE" -type f -name "*.dylib" -exec codesign --deep --force --verify --verbose --timestamp --options runtime --entitlements "$ENTITLEMENTS_FILE" --sign "$SIGNING_IDENTITY" {} \; Is this even allowed? I know of at least one app that has passed notarization checks as well. If allowed, can a dylib have more entitlements than the process that loaded it?

I am working on migrating an app to the new build system in Xcode 14. I am observing that sometimes build scripts don't run in order and I am getting random build failures. Are even scripts run in parallel or out of order in the new build system? I found an option that disables this FUSE_BUILD_SCRIPT_PHASES but it is already false by default.

Is it possible to run multiple instance of an app at the same time such that each instance is running in its own sandbox environment? For eg- Each app should have it's own ~/Library and other shared directories. Maybe something like chroot, but I am not sure it would be possible. And by sandbox I really mean isolation, not necessarily macOS App Sandbox.

We have an app on the Mac AppStore that has the following nested structure A.app |-- Contents/MacOS |-- A |-- B.app |-- C.app A.app is a launcher application that acts as a hub to launch B.app and C.app. We would like to use [SKStoreReviewController requestReview] to increase the number of users that rate the app. When the API is called from B.app or C.app, the rating dialog shows up for B.app and C.app respectively, but these apps don't independently exist on the AppStore (only A.app does). Is it possible to request a review for A.app from B.app/C.app using SkStoreKitReviewController?

I am working on a program on macOS that sends UDP probes in batches with increasing TTLs using the following code (stripped down) int sd = socket(AF_INET, SOCK_DGRAM, 0); if (sd < 0) { // error handling } sockaddr_in saddr; memset(&saddr, 0, sizeof (saddr)); saddr.sin_family = AF_INET; saddr.sin_port = htons(port_num); if (bind(sd, (const sockaddr*)&saddr, sizeof(saddr)) < 0) { // error handling } for (int i = 1; i <= 5; ++i) { int ttl = i; if(setsockopt(sd, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl)) < 0) { // error handling } char probe[64] = {0}; int cc = sendto(sd, probe, sizeof(probe), 0, &dest_addr, sizeof(dest_addr)); if (cc < 0 || cc != sizeof(probe)) { // error handling } } I would expect the code to send five packets with TTLs from 1 to 5, however, if I inspect the network activity in Wireshark all the packets are sent with TTL set to 5. I have not set the socket as non-blocking and none of the API calls reports any error. Is it incorrect to call setsockopt between sendto calls like this? Moreover, if I add a 10ms sleep between iterations, it works as expected.

We are creating a universal build of our application for the Mac App Store by merging separate x86_64 and arm64 bundles using a script. Codesign verification fails for some dylibs if they are signed after merging: % lipo -create x86_64/test.dylib arm64/test.dylib -o universal/test.dylib % codesign -s *** -f --timestamp universal/test.dylib % codesign --verify --verbose=2 universal/test.dylib test.dylib: invalid Info.plist (plist or signature have been modified) It seems verification fails for only those dylibs that have an Info.plist embedded in them. We were able to work around this issue by signing the individual dylibs before merging, but now AppStore verification is failing with the following error: ITMS-90336: Mismatched Embedded Info.plist: The executable 'test.dylib' has mismatched embedded Info.plists. This could be due to the use of 3rd party build tools. Does this mean that the __info_plist section in all the slices in the universal binary should be exactly the same (bitwise)? Some of these are third-party binaries and we don't know whether they were created using third-party build tools.

I am trying to pass an array of C-structs to an XPC Service, but the service receives only the first element. Following is the C struct struct MyStruct { char *name; unsigned char v1; unsigned char v2; Status status; // a c-style enum }; and I am using it like this struct MyStruct structs[3] = {{"name1", 0, 0, success}, {"name2", 1,1, success}, {0}}; [[_connectionToService remoteObjectProxy] doSomething:structs]; and doSomething is declared as - (void)doSomething: (struct MyStruct[]) structs; The document Creating XPC Services mentions that C structures and arrays containing only the types listed above are supported, but I am unable to get it to work even for an array of c-strings or ints. Also, there's an API for making synchronous RPC calls but there is no documentation available for it. - (id)synchronousRemoteObjectProxyWithErrorHandler:(void (^)(NSError *error))handler It does seem to block but only if the remote method has a reply block. Is this the expected behaviour? And is it safe to cache the proxy object returned by this method?

I have a task that uses a CFRunLoopObserver like the following. class Task { CFRunLoopObserverRef fObserver; public: Task() { CFRunLoopObserverContext context = {0, this, NULL, NULL, NULL}; fObserver = CFRunLoopObserverCreate(kCFAllocatorDefault, kCFRunLoopBeforeWaiting, true, 0, &MainRunLoopObserverCallback, &context); ::CFRunLoopAddObserver(CFRunLoopGetMain(), fObserver, kCFRunLoopCommonModes); } static void MainRunLoopObserverCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info) { Task* task = reinterpret_cast<Task*>(info); // task->member causes a crash if task deleted } ~Task() { if (fObserver) { ::CFRunLoopRemoveObserver(CFRunLoopGetMain(), fObserver, kCFRunLoopCommonModes); ::CFRelease(fObserver); } } }; I have noticed that the app crashes sometimes when the task object gets deleted before the CFRunLoopObserverCallBack is completed. Would it be possible to make sure that the observer callback is complete before the observer is removed from the runloop?

I am trying to get the execution time of a function in Instruments Time Profiler using the signpost APIs, but it is reporting incorrect time. I have reduced it to the following code sample #import <os/log.h> #import <os/signpost.h>    os_log_t _log = os_log_create("com.example.parser", OS_LOG_CATEGORY_POINTS_OF_INTEREST);   os_signpost_id_t spid = os_signpost_id_generate(_log);       os_signpost_interval_begin(_log, spid, "Parse", "Start");   auto b = clock();   auto begin = std::chrono::high_resolution_clock::now();     // dummy loop instead of actual parse   for(int i = 0; i < INT_MAX; ++i) {   }       auto e = clock();   auto end = std::chrono::high_resolution_clock::now();         auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - begin).count();   os_signpost_interval_end(_log, spid, "Parse", "End");   NSLog(@"CPU Time: %lf s", (e-b)/(double)CLOCKS_PER_SEC);   NSLog(@"Chrono: %lld ms", duration); As per chrono/CPU time, it takes ~3s to execute this code, but in Instruments Time Profiler, it shows the duration as 145 microseconds. Is this not the correct way to use the signpost API? XCode - 11.3 macOS 10.15.7

We have multiple macOS applications (non sandboxed) that share a lot of core frameworks. So if the user installs two of our apps, there are essentially duplicate copies of the same frameworks inside the app bundles. This duplication can cost the user around 450 MB. Is there an apple recommended way to avoid duplication in such scenarios? One approach would be to install the common frameworks in a location like /Library/Application Support/MyCompany/Shared Frameworks/ and then add this to the rpath of all the applications, but I am not sure if this will work after signing and notarization. Note - These apps are not distributed through the app store and are not sandboxed.

The main app communicates with the helper app periodically, but how to handle situations where the helper app gets stuck and stops responding to messages? [NSRunningApplication forceTerminate] would have worked, but it always returns NO when app sandbox is enabled, even if the app being terminated is part of the same app group.

I am working on a mac app that will be distributed via the AppStore. Would it be possible to include a script and some files in the pkg archive that can be copied into the app's sandbox after it has been installed using some sort of a post install hook?

I am working on an application with multiple helper apps and tools with a fairly nested structure, like the following A.app └── Contents   └── MacOS     ├── A     ├── B.app     │  └── Contents     │    └── MacOS     │      ├── B     │      └── D.app     └── C.app and have the following queries I. How to sign bundles correctly? Should the top-level bundle be signed or signing the internal contents is enough or both? For eg: Currently, after signing any nested code, I sign frameworks (and plugins) as codesign -s *** ABC.framework/Versions/A/ABC, which is what I believe Xcode does. However, in this - https://developer.apple.com/forums/thread/130855 thread  the codesign command is run on the .framework directory. 2. How to verify that the app has been signed correctly? I have encountered issues where the following codesign command reports no errors, but the app crashes on launch with Code Signature Invalid exception. codesign --verify --deep --strict --verbose=2|3|4 Foo.app 3. Do Mac App Store apps need to incorporate protections required for notarization? As per docs, Mac App Store apps don't need to go through the notarization process, are they still required to enable hardened runtime, signature timestamps etc? 4. Can helper apps have symlinks that point outside their app bundle? In the structure that I have shared, apps B, C and D share a lot of common frameworks. Can C.app's Frameworks directory be symlinked with D.app's Frameworks directly, even though it is pointing outside C.app's bundle? Note: This app will be distributed via the App Store