Problem Description MacBookPro M2, MacOS Sonoma 14.3.1, Xcode 15.3. I'm trying to recompile my project that uses SDL2, from: SDL.org's github using their SDL2-2.30.2.dmg release. "Embed Framework" is required to get around this runtime error: dyld[85171]: Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2 Referenced from: <525E2631-2C23-3E66-96F5-031C734CF0B5> Once the "Embed Framework" step is performed, the Xcode mapping of #include files stored in the loaded framework is undone. Undoing the "Embed Framework" step, puts the name mapping back but the program aborts as before. Either I can compile and obtain a run-time abort or I can not compile and not run the program. I've included a cludge to get around the issue, awaiting your fix (or advice). Replication Details Starting from a “from scratch”, Apple-supplied, “one-liner” (“Hello World”) as follows: Start new project in Xcode, selecting “MacOS”, “Command Line Tool”. Product Name:FrameWorkTest, Team:None, Organization Identifier:frameworktest, Language:C. Create the project in a new folder. with the given (default) settings. hit Apple-R… yay… it compiles and runs! add this line under the #include <stdio.h> #include "SDL2/SDL.h" Now “main.c” source is showing “file not found” against this new #include line. That’s expected. (6) Select FrameWorkTest from Navigator Pane (left hand side) (7) Select “General” tab (middle pane) (8) Finder drag “SDL2.framework” into Xcode’s middle-pane “Frameworks and Libraries” section (check the navigator pane (left pane) and now you have a “Frameworks” group containing “SDL2.framework” After a few seconds the “file not found” indicator in “main.c” vanishes and the program is compilable (Apple+B). The Framework has been integrated (Hooray). After a few seconds the “file not found” returns, though the program is still compilable (this seems to be a real-time parser mismatch with the compiler results, but not the main issue). I found the program is actually runable (Apple+R), probably because “main.c” has not been recompiled. (9) Force a recompile by adding a space to “main.c” (and remove the space) and, once again hit Apple+R. Now compile fails because “SDL2/SDL.h” is not found. (10) Change the #include "SDL2/SDL.h" to #include <SDL2/SDL.h> “file not found” goes away after “Apple+R” forces a recompile. though now the runtime “abort” issue is present. Xcode is seriously confused at this point as putting double-quote version: #include "SDL2/SDL.h" back is fine now (no longer “file not found”) even though the source is back to a failing state. Fine. now to fix the runtime “abort” issue: (11) Select “file view” in the Navigator pane (little folder icon). Select Project name, (topmost “FrameWorkTest” to show settings in middle pane). Select “Build Phases” tab. (12) Drag “SDL2.framework” from the “Frameworks” group in the project Navigator pane (leftmost pane) into “Embed Frameworks” (middle pane) (13) Now Apple+R will not compile (again) with “file not found” and I cannot get the project to compile and run without my “Trick” detailed above. Once the “Trick” is applied and the “file not found” goes away, the embed step (#12) lets the program compile and run - without “abort”. Apple’s prepending of framework name to included files is inconsistent and faulty. The step 12 appears to undo the framework name mapping for #included files found in the framework. This step-by-step repeatable bug crib is not fixed by a “Product->Clean Build Folder…”. Note: If step 12 is applied by doing a Finder drag and not a pane-to-pane drag, a (pointless) second Framework entry is introduced into the project, this confuses things further! CLUDGE WARNING Get around the “file not found” issue (total cludge but awaiting Apple’s real fix) is: Logged in as an admin, in a terminal shell, do this: cd /usr/local/include (if you don’t have this directory; mkdir -p /usr/local/include; cd /usr/local/include) ln -s /Library/Frameworks/SDL2.framework/Headers; mv Headers SDL2 Now in target settings, “Build Settings” tab, find “Header Search Paths” section and add “/usr/local/include” with “recursive” option selected (if it’s not already there). I used a symbolic link (-s) for the trick so that the link is not disrupted when you next upgrade your SDL2.framework. Now, even when you do a Product->Clean Build Folder, the project should build and run without Xcode issues. Additionally, if you’d like to perform “the trick” for SDL2_ttf.framework #include files, do: cd /usr/local/include ln -s /Library/Frameworks/SDL2_ttf.framework/Headers; mv Headers SDL2_ttf in an admin terminal. Aside... Reporting web page renumbers my 1) through 13), though the renumbering does not appear in the preview as it does in the actual post!

Since 2023 Apple have strongly suggested signing XCFrameworks to verify their origins. This has worked perfectly fine for the last year. Seeing that our certificate was about to expire, we revoked it and created a new one which we will use to sign all future releases. However, because that first certificate has been revoked, all previous releases of our XCFramework now have invalid signatures because the certificate they used no longer exists. While an update to the latest XCFramework would solve the issue, that's not always a possibility for people with lower minimum deployment targets that can only run an older version of our XCFramework. In the wwdc video on the topic it states: When the xcframework author's signing certificate expires, Xcode is able to automatically validate that a new certificate for Apple Developer Program identities is from the same developer. Does this mean that if we had not pre-empted the expiry and instead let the certificate expire, we wouldn't have this backwards compatibility issue? The course of action we've had to take is to manually go through all of our releases for the last year and re-sign them with the latest certificate. This doesn't seem like a tenable solution each year. Looking for guidance on how to manage this situation each year.

We are using mach_absolute_time to determine the number of CPU cycles in our app, and from that, we are using it to seed a random number generator. From this random number generator, we are getting a series of random numbers and combining it with other random numbers from another generator not seeded via mach_abolute_time. This combined random number is being sent off device as a unique ID for authentication purposes. I've read through the required reasons for using this API, and I am not sure if it falls under the acceptable use cases. My gut-feeling is that it does not. The following reasons are what Apple lists as acceptable reasons for this API: 35F9.1 Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers. Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device. 8FFB.1 Declare this reason to access the system boot time to calculate absolute timestamps for events that occurred within your app, such as events related to the UIKit or AVFAudio frameworks. Absolute timestamps for events that occurred within your app may be sent off-device. System boot time accessed for this reason, or any other information derived from system boot time, may not be sent off-device. 3D61.1 Declare this reason to include system boot time information in an optional bug report that the person using the device chooses to submit. The system boot time information must be prominently displayed to the person as part of the report. Information accessed for this reason, or any derived information, may be sent off-device only after the user affirmatively chooses to submit the specific bug report including system boot time information, and only for the purpose of investigating or responding to the bug report. Would anybody be able to confirm that this usage is allowed or if we will need to change it to be in accordance with Apple's new policies regarding the usage of this API? Thanks

We are using AFnetworking in our code base - this framework is build from source code and we not using any binaries provided by AFNetworking team. We have also modify the open source code, so that it is different from the original open source code in a way so that it won't lead to runtime conflicts in case the customers is including similar frameworks in their application. We're using those derivatives of the open source frameworks as a statically linked libraries to our SDK. Now as announce by the AFNetworking Team the SDK is now deprecated - " As of Jan. 17, 2023, AFNetworking is deprecated and there will be no further releases. This repo will remain online in perpetuity as an archive. There are a couple options for continued AFNetworking use: Copy AFNetworking into your project and compile it directly. This gives you full control over the code. Fork AFNetworking and use the fork in your dependency manager. There will be no official forks but anyone can fork at any time and can even publish those forks under a different name, in accordance with AFNetworking's license. Moving forward, Alamofire is the suggested migration path for networking in modern Swift. " Since major part of our code base extensively use objective C we are reluctant to migrate at the moment. Query: - As AFNetworking announcement clearly states the SDK can still be used and repo will remain available as an archive - If we continue to use forked version of AFNetworking in the way stated above in our code base - will it have any impact on App Submission for the APP store ?

For our application, we are aiming to have full control over setting and locking the camera exposure settings when taking a video. We’re working with Apple’s AVFoundation framework for a range of devices, but most of the development is focused on the iPad 8 front camera. The manual settings are specific to our use, so we aim to use the custom exposure mode with e.g ISO = 100, exposureDuration = 1/60, and a fixed white balance. The duration, ISO, and white balance are all set in advance of recording, but when we begin we can see that something is still adjusting and compensating for lighting changes. We then also tried locking the exposure mode after setting the custom values, but there appears to be a delay in this lock taking effect. While tracking the ISO during a recording, we see that the ISO values change in the first second of the recording, leading to oversaturated images, despite our efforts to keep it locked. This is our attempt to lock the settings using custom mode, which we don’t adjust ourselves during the recording, but it does not work as expected: func setCameraSettings(newValueISO: Float, newValueDuration: CMTime){ do { try cameraDevice?.lockForConfiguration() cameraDevice?.automaticallyAdjustsVideoHDREnabled = false cameraDevice?.setExposureModeCustom(duration: newValueDuration, iso: newValueISO, completionHandler: { [self] _ in cameraDevice?.setWhiteBalanceModeLocked(with: cameraDevice!.deviceWhiteBalanceGains) if ((cameraDevice!.isFocusModeSupported(.locked))) { do { cameraDevice!.focusMode = .locked debugPrint("Focus mode set to locked.") } } cameraDevice?.unlockForConfiguration() }) } catch { debugPrint("Error adjusting the exposure") cameraDevice?.unlockForConfiguration() } } We then tried to lock the exposure mode after setting the custom values, but it then changes during the first second of the recording. We also explicitly tried setting exposureTargetBias to 0, but this made no difference. func setCameraSettings(newValueISO: Float, newValueDuration: CMTime){ guard let camera = cameraDevice else { return } do { if camera.isExposureModeSupported(.custom) { do { try camera.lockForConfiguration() let customExposureBias: Float = 0 //camera.setExposureTargetBias(customExposureBias, completionHandler: nil) if camera.isExposureModeSupported(.custom) { camera.setExposureModeCustom(duration: newValueDuration, iso: newValueISO) { [weak camera ] _ in guard let camera = camera else { return } if camera.isExposureModeSupported(.locked) { camera.exposureMode = .locked } } } camera.unlockForConfiguration() print("Exposure settings locked with custom values.") } catch { print("Failed to lock configuration for capture device: \(error.localizedDescription)") camera.unlockForConfiguration() } } else { print("Custom exposure mode is not supported.") } } } We would very much appreciate input on how to keep the manually selected camera settings fixed throughout the video recording.

Hi, I am splitting my iOS app into smaller components, the natural way of doing this is to create static libraries that I can link with the main binary. I did succeed at making small static libraries (.a) and link them, but I was struggling with static framework where I have color assets. Finally I was able to make it work by going to the app target > Build Phases > Copy Bundle Resources and add there the .xcassets from the static framework I created. The confusion on my side is that the assets are accessed from the Framework code not from the app target code, and the guidance I am asking for is: How to create and link a static framework on iOS so that the framework can load and use it's own defined assets without having to do the Copy Bundle Resources step. Best Regards, Ion

I have a React-Native App that I am trying to build to iOS using Xcode. When I build to my iPhone 12 Mini (iOS 17.4.1), the app works perfectly. When I build to my iPhone 7 Plus (iOS 15.8.2), the app pauses running immediately, and Xcode displays the following in the log: dyld[935]: Symbol not found: (_JSGlobalContextSetInspectable) Referenced from: '/private/var/containers/Bundle/Application/2579192B-74C5-4B54-AA59-948C49A4A7CA/MANHUNT2.app/MANHUNT2' Expected in: '/System/Library/Frameworks/JavaScriptCore.framework/JavaScriptCore' The app used to work perfectly on both phones, but this error has been happening recently, and I am unsure of the cause. Cleaning build folder and deleting derived data has not fixed the issue. Xcode: Version 15.3 React-Native: 0.73.6 Working Phone: iOS 17.4.1 Non-Working Phone: iOS 15.8.2

I have been working with a framework to add multiplayer support to my app. The app runs on test devices, simulators, and archives perfectly fine and the app is fine without the framework. But when I go to distribute the app, I see get this error related to the multiplayer framework I have added. I have tried updating the minimumOSVersion to 9.0, 10.0, 12.0, and 13.0 everywhere (info.plist, deployment info, build settings, etc) and they all match with each build/archive but no matter what I can't get fix this error. This error only shows up when I go to distribute the app to the store. Any ideas on what to try or how to fix this issue? I've attached a screenshot of the issue below.

We are using AFnetworking in our code base - this framework is build from source code and we not using any binaries provided by AFNetworking team. We have also modify the open source code, so that it is different from the original open source code in a way so that it won't lead to runtime conflicts in case the customers is including similar frameworks in their application. We're using those derivatives of the open source frameworks as a statically linked libraries to our SDK. Now as announce by the AFNetworking Team the SDK is now deprecated -“ As of Jan. 17, 2023, AFNetworking is deprecated and there will be no further releases. This repo will remain online in perpetuity as an archive. There are a couple options for continued AFNetworking use: Copy AFNetworking into your project and compile it directly. This gives you full control over the code. Fork AFNetworking and use the fork in your dependency manager. There will be no official forks but anyone can fork at any time and can even publish those forks under a different name, in accordance with AFNetworking's license. Moving forward, Alamofire is the suggested migration path for networking in modern Swift.  Since major part of our code base extensively use objective C we are reluctant to migrate at the moment. Query for the Apple support team - As AFNetworking announcement clearly states the SDK can still be used and repo will remain available as an archive - If we continue to use forked version of AFNetworking in the way stated above , in our code base will it have any impact on App Submission for the APP store.

Hello, When you integrate framework linked statically, the usage is that those framework provide a bundle in which they put their PrivacyInfo.xcprivacy file. If you decompress an .ipa file you submit to Apple, you can see this bundle at the root. The problem is that the PrivacyInfo.xcprivacy files inside bundles seem not to be scan by Apple in the privacy process. Thus Apple send us issues about missing privacy. Have you already heard about this problem ? Probably link to what i am saying : Firebase issue #12557 Thank you very much for your feedback !

We're distributing an XCFramework to a customer to create their own apps. With the new XCFramework signing requirements, we have a question with regards the way how to implement it. We're using a few of the frameworks on the list https://developer.apple.com/support/third-party-SDK-requirements/ including [AFNetworking], as a dependencies for our framework. We are building those frameworks from source code and not using any binaries provided by any third-party. We also modify the open source code, so that it is different from the original open source code in a way so that it won't lead to runtime conflicts in case the customers is including similar frameworks in their application. We're using those derivatives of the open source frameworks as a statically linked libraries to our SDK. Questions: Do we need to sign the third party frameworks of which we have cloned source code and using it within our SDK Framework? Is it required that the XCFramework built this way is signed when it is delivered to a third party and they use it in their app?

Since yesterday (03/22/24) we are unable to upload new or existing builds to AppStoreConnect. We get the following error - “Error ITMS-90432 Unexpected file found in Frameworks. MyApp.app/Frameworks/Configurations” file is in the Frameworks directory, but the Swift runtime libraries are the only files permitted in that directory. Please remove this file and upload a new build. (ID: 57e219ea-d27e-465d-9e9b-ec41d3a0b1f7). We have tried rebuilding targerts with no changes for Builds that use to upload ok and they now get the same error too. Is this an appstoreconnect bug? If not where is the Frameworks directory and how do we remove the file?

Hey! TLDR: How Health app knows the new menstruation cycle started? The API Adding .menstrualFlow (HKCategoryValueMenstrualFlow) samples require HKMetadataKeyMenstrualCycleStart: Bool parameter. It's fairly simple for the consecutive days - the first sample includes true, the rest false. The problem What about more complex scenarios like: 3 days of unspecified samples, then 2 days of none samples, and unspecified sample again. Should it be marked as the new cycle start? I don't want to prompt the user to confirm the new menstruation cycle. Observations I noticed Health app performs some logic under the hood. For instance, when I marked 5 days in a row unspecified, then left 6 days in a row empty, then selected unspecified again, I got 2 menstruation cycles (11 days ago and today). But when I changed the number of the days I marked as unspecified before the gap, or the length of the gap, or edited the cycles further in the past, I ended up having just 1 menstruation cycle. I guess Health app takes into consideration: previous menstruation length, gap length, average cycle length. But what is the exact math here? I don't want to ruin the user's statistics 💚 I found in the user guide this info about the fertility: The fertile window will be the six days you're most likely to be fertile, based on data that you’ve logged about your period or a positive ovulation test result. The fertile window prediction is based on a traditional calendar method. The fertile window is calculated by subtracting 13 days (the luteal phase) from the estimated next cycle start date. So I think something similar might be going on here. Thanks in advance!

I'm developing a (XC) 3rd party framework, but the framework doesn't use any privacy access API as listed in listed in this document. Do I still need to include the PrivacyManifest.xcprivacy file which will have empty content into the framework?

Per my understanding of the DispatchQueue docs, and various WWDC videos on the matter, if one creates a queue in the following manner: let q = DisqpatchQueue( label: "my-q", qos: .utility, target: .global(qos: .userInteractive) ) then one should expect work items submitted via async() to effectively run at userInteractive QoS, as the target queue should provide a 'floor' on the effective QoS value (assuming no additional rules are in play, e.g. higher priority items have been enqueued, submitted work items enforce QoS, etc). In practice, however, this particular formulation does not appear to function that way, and the 'resolved' QoS value seems to be utility, contrary to what the potentially relevant documentation suggests. This behavior appears to be inconsistent with other permutations of queue construction, which makes it even more surprising. Here's some sample code I was experimenting with to check the behavior of queues created in various ways that I would expect to function analogously (in regards to the derived QoS value for the threads executing their work items): func test_qos_permutations() { // q1 let utilTargetingGlobalUIQ = DispatchQueue( label: "qos:util tgt:globalUI", qos: .utility, target: .global(qos: .userInitiated) ) let customUITargetQ = DispatchQueue( label: "custom tgt, qos: unspec, tgt:globalUI", target: .global(qos: .userInitiated) ) // q2 let utilTargetingCustomSerialUIQ = DispatchQueue( label: "qos:util tgt:customSerialUI", qos: .utility, target: customUITargetQ ) // q3 let utilDelayedTargetingGlobalUIQ = DispatchQueue( label: "qos:util tgt:globalUI-delayed", qos: .utility, attributes: .initiallyInactive ) utilDelayedTargetingGlobalUIQ.setTarget(queue: .global(qos: .userInitiated)) utilDelayedTargetingGlobalUIQ.activate() let queues = [ utilTargetingGlobalUIQ, utilTargetingCustomSerialUIQ, utilDelayedTargetingGlobalUIQ, ] for q in queues { q.async { Thread.current.name = q.label let threadQos = qos_class_self() print(""" q: \(q.label) orig qosClass: \(q.qos.qosClass) thread qosClass: \(DispatchQoS.QoSClass(rawValue: threadQos)!) """) } } } Running this, I get the following output: q: qos:util tgt:customSerialUI orig qosClass: utility thread qosClass: userInitiated q: qos:util tgt:globalUI-delayed orig qosClass: utility thread qosClass: userInitiated q: qos:util tgt:globalUI orig qosClass: utility thread qosClass: utility This test suggests that constructing a queue with an explicit qos parameter and targeting a global queue of nominally 'higher' QoS does not result in a queue that runs its items at the target's QoS. Perhaps most surprisingly is that if the target queue is set after the queue was initialized, you do get the expected 'QoS floor' behavior. Is this behavior expected, or possibly a bug?

Hello, Which API can be used to programatically fetch the ID of user who installed/paid the app? This is useful if an app has to create a path hierarchy for different users who have installed/paid the app, for instance, /AppName//user_files, how to get the uniqueUserID, and also, to get the information about which user these files belong to based on this uniqueUserID. App is using Swift, SwiftUI. Thanks.

Please help me understand the phrasing from Apple's articles about this topic. Of course, I am referring to the SDKs from the official list, as only those are affected by the new regulations. 1, https://developer.apple.com/support/third-party-SDK-requirements/ Starting in spring 2024, you must include the privacy manifest for any SDK listed below when you submit new apps in App Store Connect that include those SDKs, or when you submit an app update that adds one of the listed SDKs as part of the update. That states 2 cases in which fresh SDK versions are needed, containing privacy information: If you submit a completely new app If your app update contains a framework which was not present in the previous version of the app So, according to my understanding, if I create an app update, which does not contain any new SDKs, only the ones that I have been using for a while now, I can keep using these older SKD versions. And it is not mandatory to update them to newer versions. Does Apple state anywhere that we have to update every SDK from the list this spring in every case? Because that would contradict what I quoted from the article. 2, https://developer.apple.com/news/?id=3d8a9yyh And if you add a new third-party SDK that’s on the list of commonly used third-party SDKs, these API, privacy manifest, and signature requirements will apply to that SDK. Again, this states that you have to use a fresh version of an SDK in case you add it newly to your app. This seems to reinforce my point that if a 3rd party SDK was already used in previous app versions, the new requirements do not apply to that SDK and I can keep using its older release which does not have its own privacy manifest file. My main concern here is that there are many 3rd party SDKs from the list that we already use in our projects, and it would be a huge effort if my team had to update all those SDKs in every project by May. But if I'm right, it is not mandatory for us. (Of course, it would be wise to update the SDKs every now and then, but that's not the point here.) Can anybody confirm whether my understanding is correct? Maybe link some proof if I'm not right? It would be nice to have a reply from someone working at Apple, to have a reliable answer.

Hi there, I'm working on an app that contains a mini system monitoring utility. I would like to list the top CPU-using processes. As Quinn “The Eskimo!” has repeatedly cautioned, relying on private frameworks is just begging for maintenance effort in the future. Ideally, I want to go through public headers/frameworks. I've gone to great lengths to try to find this information myself, and at this point I'm just struggling. I detail my research below. Any pointers in the right direction would be much appreciated! Attempts Libproc First I looked at libproc. Using proc_pidinfo with PROC_PIDTHREADINFO, I'm able to get each thread of an app, with its associated CPU usage percentage. Summing these, I could get the total for an app. Unfortunately, this has two downsides: Listing a table of processes now takes O(proces_count) rather than just O(process_count), and causes way more syscalls to be made It doesn't work for processes owned by other users. Perhaps running as root could alleviate that, but that would involve making a priviliedged helper akin to the existing sysmond that Activity Monitor.app uses. I'm a little scared of that, because I don't want to put my users at risk. Sysctl Using the keys [CTL_KERN, KERN_PROC, KERN_PROC_PID, someProcessID], I'm able to get a kinfo_proc - https://github.com/apple-opensource/xnu/blob/24525736ba5b8a67ce3a8a017ced469abe101ad5/bsd/sys/sysctl.h#L750-L776 instance. Accessing its .kp_proc - https://github.com/apple-opensource/xnu/blob/24525736ba5b8a67ce3a8a017ced469abe101ad5/bsd/sys/proc.h#L96-L150.p_pctcpu - https://github.com/apple-opensource/xnu/blob/24525736ba5b8a67ce3a8a017ced469abe101ad5/bsd/sys/proc.h#L123 looked really promising, but that value is always zero. Digging deeper, I found the kernel code that fills this struct in (fill_user64_externproc - https://github.com/apple-opensource/xnu/blob/c76cff20e09b8d61688d1c3dfb8cc855cccb93ad/bsd/kern/kern_sysctl.c#L1121-L1168). The assignment of p_pctcpu - https://github.com/apple-opensource/xnu/blob/c76cff20e09b8d61688d1c3dfb8cc855cccb93ad/bsd/kern/kern_sysctl.c#L1149 is in a conditional region, relying on the _PROC_HAS_SCHEDINFO_ flag. Disassembling the kernel on my mac, I could confirm that the assignment of that field never happens (thus _PROC_HAS_SCHEDINFO_ wasn't set during compilation, and the value will always stay zero) Reverse engineering Activity Monitor.app Activity Monitor.app makes proc_info and sysctl system calls, but from looking at the disassembly, it doesn't look like that's where its CPU figures come from. From what I can tell, it's using private functions from /usr/lib/libsysmon.dylib. That's a user library which wraps an XPC connection to sysmond (/usr/libexec/sysmond), allowing you to create requests (sysmon_request_create), add specific attributes you want to retrieve (sysmon_request_add_attribute), and then functions to query that data out (sysmon_row_get_value). Getting the data "striaght from the horses mouth" like this sounds ideal. But unfortunately, the only documentation/usage I can find of sysmond is from bug databases demonstrating a privilege escalation vulnerability lol. There are some partial reverse engineered header files floating around, but they're incomplete, and have the usual fragility/upkeep issues associated with using private APIs. On one hand, I don't want to depend on a private API, because that takes a lot of time to reverse engineer, keep up with changes, etc. On the other, making my own similar privileged helper would be duplicating effort, and expose a bigger attack surface. Needless to say, I have no confidence in being able to make a safer privileged helper than Apple's engineers lol Reverse engineering iStat Menus Looks like they're using proc_pid_rusage - https://github.com/apple-opensource/xnu/blob/24525736ba5b8a67ce3a8a017ced469abe101ad5/libsyscall/wrappers/libproc/libproc.h#L103-L108 . However, I don't know how to convert the cpu_*_time fields of the resulting struct rusage_info_v4 - https://github.com/apple-opensource/xnu/blob/24525736ba5b8a67ce3a8a017ced469abe101ad5/bsd/sys/resource.h#L306-L343 to compute a "simple" percentage. Even if I came up with some formula that produces plausible looking results, I have no real guarantee it's correct or equivalent to what Activity Monitor shows.