My apple Account having Two active 'iOS Distribution' now Both are expected to Expire in next ~20 day's. Below are my queries looking for the details. a) can we create the new (third) iOS Distribution certificate for the build distribution ? b) how can we identified the current Active application provisioning profiles are boing with which iOS Distribution certificate (as under the Profile details showing two certificate having the same date) , so not able ti identified which certificate currently is in use?

We are considering developing our own MDM server for internal app distribution. Is it necessary to enroll in the Apple Enterprise Developer Program to develop MDM server? Currently, our company is only enrolled in the Apple Developer Program and Business Manager. Additionally, since we have fewer than 100 employees, it is difficult for us to join the Enterprise Program. In this case, is it not possible for us to set up an MDM server?

Learn techniques to help debug any coordinate space issue. View Technote TN3124 >

I'm trying to compile a little project in C with the following structure: Project | |->Headers |->library.h | |->src |->main.c |->library.c I've checked all my files, my configurations files and I'm getting the same error everytime, someone could please help me? :( Undefined symbols for architecture arm64: "_getfavoritenumber", referenced from: _main in main-99c109.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

Cx was unable to login to their cloud account when the policy was pushed on to their device. However, when no policy was pushed cx could login. The issue is with applying whitelist configuration to device with passcode turned on..while whitelisting the app some system bundle identifier is getting blocked, we tried whitelisting all system app available for ios and couldn't find a solution

I have integrated MetricKit into my production app and listening for the corresponding callback func didReceive(_ payloads: [MXDiagnosticPayload]) After some time, I've noticed that the hang diagnostics data collected are all for hangs longer than 1 second. Does MetricKit only collect hang data for hangs longer than 1 second? Can this threshold be adjusted, for example, to 500ms? Is there any sampling involved in the collection of hang diagnostics? The number of hang events collected by MetricKit is significantly lower compared to other third-party platforms. Thank you for your response, this is very important to me.

Hi all , We are planning to manage about 1 Million+ Apple devices of inclusive of both iPhone and Mac devices under a AxM Account. However while adding VPP Licenses for an App i'm prompted with below error: " You cannot order more than 100000 copies of same the free item per week" While our goal is to manage 1 Million devices under same Location token , i have below questions in mind 1 . What is the upper limit of number of Licenses that can be added per app in a Location token? Currently it says 1 Lakh Licenses per app per week . Wanted to know if there is any limit on this count as it shouldn't surprise us in upcoming weeks. 2 . How many Locations can be created in a AxM Account? Currently we created about 15 location to see if there are any limit but so far couldn't find any limit on number of locations that can be created. This limit could help us plan our deployment in advance 3 . What is the total number of licenses a VPP Location token can hold ? As we manage 1 Million Devices for 12 Apps , 1 Million x 12= 12 Million licenses would be transacted in this location token by our MDM Solution , is this okay or will there be any limitations in this count

Hi, ho un'idea per un'applicazione che può rivoluzionare e agevolare riguardo l'utilizzo degli apparati video (telefoni, monitor, tv) per almeno il75/80% dell'intera popolazione mondiale. Vorrei che fosse un'operazione realizzata inizialmente da apple ios/os e in seguito su tutti i supporti. Mi piacerebbe creare, sviluppare o cedere l'idea ma non so proprio da dove iniziare. potete darmi info su questo? so che può sembrare una richiesta astrana, ma sono certo che questa app sarà una vera rivoluzione per tutti, o quasi Grazie Giovanni da Cagliari, Sardegna, Italia Hi, I have an idea for an application that can revolutionize and facilitate the use of video equipment (telephones, monitors, TVs) for at least 75/80% of the entire world population. I would like it to be an operation carried out initially by apple ios/os and later on all media. I would like to create, develop or sell the idea but I really don't know where to start. can you give me info on this? I know it may seem like a strange request, but I'm sure that this app will be a real revolution for everyone, or almost everyone Thank you Giovanni from Italy [Edited by Moderator]

Hi, I want to create an offline mode for my iOS app. Where is it better to keep files in terms of download speed: in a CDN like Cloudflare or using On-Demand Resources? The total file size is 2 GB.

As presented in the talks and documentation I’ve seen so far, DocC works for public and open Swift symbols. But how about stuff for internal use? We are developing a fairly complex mixed source SDK with several components, that would benefit greatly from direct integration of auxiliary content for diagrams and so on. But since many of these parts are for internal use only, they have module or below level visibility. Is there a way to build an internal documentation target that includes this information with DocC, and — if so — how?

I am looking forward to develop an ecommerce IOS application. When I conducted my research for the same I found that offshore developers are offering solutions in quite less price compare to onshore developers. At the same time I also have some doubts over offshore development such as reliability, quality, collaboration and more.. Anyone can suggest me what would be the best in long term.

Hello, I'm in charge of the system at a certain company. We've been having trouble lately. Does anyone have the same problem? Our company have IN-HOUSE app for our employee. An issue has been occurring where the app can't be started after updating since last year. It is distributed to 2000 devices, and about 3 errors occur every time. When I try to start it I get the error below. "Unable to Verify App: An internet connection is required to verify the trust of the developer ... This app will not be available until verified." (IN JAPANESE：アプリを検証できません デベロッパー″iPhone　Distribution：...″の信用を確認するにはインターネット接続が必要です。確認が終わるまではこのアプリは使用できません。) *There were no problems with internet connectivity on any of the devices. *Provisioning profile has not expired. Moreover, Errors suddenly started to occur frequently even on devices that have not been updated since last month. The issue is occurring on the following devices. iOS16.6～17.3 iPhone 8, iPhone SE2 Although We restarted the iPhone and redistributed the app, the issue didn't improve. Currently, we are resolving by initializing the iPhone, but is there any workaround?

This is related to feedback submitted at https://feedbackassistant.apple.com.

The MAC device is a device that has been manually added to the Apple Business Manager. DEP profiles are normally installed in both iOS and iPadOS. Profile descript error occurs only when attempting DEP of MacOS. (If you look at the picture, a decryption error occurs in the remote device registration step.) I asked Apple's customer center about this problem,  and it is said that it is caused by the lack of a key called "automatic registration on the MDM server" The key cannot be found in the Apple official document related to the profile below. https://developer.apple.com/documentation/devicemanagement/mdm/ Information received during DEP enroll of Macmini using Apple silicon. {    'LANGUAGE': 'en_US',    'PRODUCT': 'Macmini 9,1',    'SERIAL': 'CXXXXXXXXXXV',    'UDID': '0XXXXX27-XXXX-XXXX-XXXX-XZXXXXXXXXX',    'VERSION': '21C52' } Information received during DEP enroll of iPAD {    'LANGUAGE': 'en_US',    'PRODUCT': 'iPad5,4',    'SERIAL': 'DXXXXXXXXXXQ',    'UDID': '9aXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX6d',    'VERSION': '19C63' } Profile to be transmitted to the device (same as MacOS, iOS, IPadOS) {    'AccessRights': 8191,    'CheckInURL': 'https://apm.xxxxx.com/checkin',    'CheckOutWhenRemoved': True,    'IdentityCertificateUUID': '00000000-0000-0000-0000-000000000000',    'PayloadDescription': 'MDM Profile',    'PayloadDisplayName': 'MDM',    'PayloadIdentifier': 'com.xxxxx.xxxxxxx.mdm',    'PayloadOrganization': 'MDM provider',    'PayloadType': 'com.apple.mdm',    'PayloadUUID': '00000000-0000-0000-0000-000000000000',    'PayloadVersion': 1,    'PromptUserToAllowBootstrapTokenForAuthentication': True,   'ServerCapabilities': ['com.apple.mdm.per-user-connections','com.apple.mdm.bootstraptoken'],    'ServerURL': 'https://apm.xxxxx.com/server',    'SignMessage': False,    'Topic': 'com.apple.mgmt.External.206bfa63-f76a-4381-9e50-6f74241d14d9' }  Because it uses the same profile structure, it is not understood that iOS/iPadOS operates normally and errors occur only in MacOS. If there is anything that can help me, please let me know. Thank you.

It seems impossible to me, but around the time I installed the latest command line tools (xcode-select version 2397) binaries what were built with linkages to @rpath/libfoo.dyld stopped being able to find their dependency. The error looks like this. dyld[1471]: Symbol not found: _GEOSGeomGetX Referenced from: <16DBE67F-CB32-31EE-BCE0-BFB58EEC9740> /Users/pramsey/tmp/capi_indexed_predicate Expected in: <no uuid> unknown zsh: abort ./capi_indexed_predicate If I turn on DYLD_PRINT_SEARCHING, I can see the linker giving up on the rpath entry. dyld[1501]: find path "@rpath/libgeos_c.1.dylib" dyld[1501]: not found: "@rpath/libgeos_c.1.dylib" I can work around, partially, by setting DYLD_LIBRARY_FALLBACK_PATH to have /usr/local/lib in it, but that is only a partial fix, because SIP will strip that variable for any child processes, which means most of my development and database work is borked. This seems like a very new quirk, maybe related to the XCode 15 update, at least in my personal time line, has anyone else seen it, or have any clue as to what has changed? (Worth noting, nothing changed in my code, just one day my builds wouldn't run anymore, and that day was the day after I had installed the new commandline tools).

Hello there: On November 2023, I submitted enrollment ID 3BR28NV28U. I am responsible on behalf of my employer, Strathcona Resources, to submit this Apple Developer enrollment to advance in a custom app that we must implement to our iPads in our field sites. As you can probably tell, I have not received any advancement with this request, and seven months have passed, without any update or any notification regarding this enrollment. I would appreciate it if you can please channel this request to the appropriate party, in order to provide a status update, escalation, and completion as appropriate. Seven months without an update is a major delay, and we are behind schedule for the custom app that we need to implement in our organization. Thank you for your attention to this matter. Best regards, **** Godoy Strathcona Resources

Hi, Guys, I would lie to ask it been more than 10 days I add my card but still it shows Your purchase may take up to 48 hours to process. i use my name same in card also anybody know what possible issues here, i was using my email but it is not same email with my card I located in Malaysia

Apple’s library technology has a long and glorious history, dating all the way back to the origins of Unix. This does, however, mean that it can be a bit confusing to newcomers. This is my attempt to clarify some terminology. If you have any questions or comments about this, start a new thread and tag it with Linker so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" An Apple Library Primer Apple’s tools support two related concepts: Platform — This is the platform itself; macOS, iOS, iOS Simulator, and Mac Catalyst are all platforms. Architecture — This is a specific CPU architecture used by a platform. arm64 and x86_64 are both architectures. A given architecture might be used by multiple platforms. The most obvious example of this arm64, which is used by all of the platforms listed above. Code built for one platform will not work on another platform, even if both platforms use the same architecture. Code is usually packaged in either a Mach-O file or a static library. Mach-O is used for executables, dynamic libraries, bundles, and object files. These can have a variety of different extensions; the only constant is that .o is always used for a Mach-O containing an object file. Use otool and nm to examine a Mach-O file. Use vtool to quickly determine the platform for which it was built. Use size to get a summary of its size. Use dyld_info to get more details about a dynamic library. IMPORTANT All the tools mentioned here are documented in man pages; for information on how to access that documentation, see Reading UNIX Manual Pages. The term Mach-O image refers to a Mach-O that can be loaded and executed without further processing. That includes executables, dynamic libraries, and bundles, but not object files. A dynamic library has the extension .dylib. You may also see this called a shared library. A framework is a bundle structure with the .framework extension that has both compile-time and run-time roles: At compile time, the framework combines the library’s headers and its stub library (stub libraries are explained below). At run time, the framework combines the library’s code, as a Mach-O dynamic library, and its associated resources. The exact structure of a framework varies by platform. For the details, see Placing Content in a Bundle. macOS supports both frameworks and standalone dynamic libraries. Other Apple platforms support frameworks but not standalone dynamic libraries. Historically these two roles were combined, that is, the framework included the headers, the dynamic library, and its resources. These days Apple ships different frameworks for each role. That is, the macOS SDK includes the compile-time framework and macOS itself includes the run-time one. Most third-party frameworks continue to combine these roles. A static library is an archive of one or more object files. It has the extension .a. Use ar, libtool, and ranlib to inspect and manipulate these archives. The static linker, or just the linker, runs at build time. It combines various inputs into a single output. Typically these inputs are object files, static libraries, dynamic libraries, and various configuration items. The output is most commonly a Mach-O image, although it’s also possible to output an object file. The linker may also output metadata, such as a link map (see Using a Link Map to Track Down a Symbol’s Origin). The linker has seen three major implementations: ld — This dates from the dawn of Mac OS X. ld64 — This was a rewrite started in the 2005 timeframe. Eventually it replaced ld completely. If you type ld, you get ld64. ld_prime — This was introduced with Xcode 15. This isn’t a separate tool. Rather, ld now supports the -ld_classic and -ld_new options to select a specific implementation. Note During the Xcode 15 beta cycle these options were -ld64 and -ld_prime. I continue to use those names because the definition of new changes over time (some of us still think of ld64 as the new linker ;–). The dynamic linker loads Mach-O images at runtime. Its path is /usr/lib/dyld, so it’s often referred to as dyld, dyld, or DYLD. Personally I pronounced that dee-lid, but some folks say di-lid and others say dee-why-el-dee. IMPORTANT Third-party executables must use the standard dynamic linker. Other Unix-y platforms support the notion of a statically linked executable, one that makes system calls directly. This is not supported on Apple platforms. Apple platforms provide binary compatibility via system dynamic libraries and frameworks, not at the system call level. Note Apple platforms have vestigial support for custom dynamic linkers (your executable tells the system which dynamic linker to use via the LC_LOAD_DYLINKER load command). This facility originated on macOS’s ancestor platform and has never been a supported option on any Apple platform. The dynamic linker has seen 4 major revisions. See WWDC 2017 Session 413 (referenced below) for a discussion of versions 1 through 3. Version 4 is basically a merging of versions 2 and 3. The dyld man page is chock-full of useful info, including a discussion of how it finds images at runtime. One of the most common points of confusion with dynamic linker is the way that the dynamic linker identifies dynamic libraries. There are two standard approaches to this, as described in Dynamic Library Identification. Xcode 15 introduced the concept of a mergeable library. This a dynamic library with extra metadata that allows the linker to embed it into the output Mach-O image, much like a static library. Mergeable libraries have many benefits. For all the backstory, see WWDC 2023 Session 10268 Meet mergeable libraries. For instructions on how to set this up, see Configuring your project to use mergeable libraries. If you put a mergeable library into a framework structure you get a mergeable framework. Xcode 15 also introduced the concept of a static framework. This is a framework structure where the framework’s dynamic library is replaced by a static library. Note It’s not clear to me whether this offers any benefit over creating a mergeable framework. Earlier versions of Xcode did not have proper static framework support. That didn’t stop folks trying to use them, which caused all sorts of weird build problems. A universal binary is a file that contains multiple architectures for the same platform. Universal binaries always use the universal binary format. Use the file command to learn what architectures are within a universal binary. Use the lipo command to manipulate universal binaries. A universal binary’s architectures are either all in Mach-O format or all in the static library archive format. The latter is called a universal static library. A universal binary has the same extension as its non-universal equivalent. That means a .a file might be a static library or a universal static library. Most tools work on a single architecture within a universal binary. They default to the architecture of the current machine. To override this, pass the architecture in using a command-line option, typically -arch or --arch. An XCFramework is a single document package that includes libraries for any combination of platforms and architectures. It has the extension .xcframework. An XCFramework holds either a framework, a dynamic library, or a static library. All the elements must be the same type. Use xcodebuild to create an XCFramework. For specific instructions, see Xcode Help > Distribute binary frameworks > Create an XCFramework. Historically there was no need to code sign libraries in SDKs. If you shipped an SDK to another developer, they were responsible for re-signing all the code as part of their distribution process. Xcode 15 changes this. You should sign your SDK so that a developer using it can verify this dependency. For more details, see WWDC 2023 Session 10061 Verify app dependencies with digital signatures and Verifying the origin of your XCFrameworks. A stub library is a compact description of the contents of a dynamic library. It has the extension .tbd, which stands for text-based description (TBD). Apple’s SDKs include stub libraries to minimise their size; for the backstory, read this post. Stub libraries currently use YAML format, a fact that’s relevant when you try to interpret linker errors. Use the tapi tool to create and manipulate these files. In this context TAPI stands for a text-based API, an alternative name for TBD. Oh, and on the subject of tapi, I’d be remiss if I didn’t mention tapi-analyze! Mach-O uses a two-level namespace. When a Mach-O image imports a symbol, it references the symbol name and the library where it expects to find that symbol. This improves both performance and reliability but it precludes certain techniques that might work on other platforms. For example, you can’t define a function called printf and expect it to ‘see’ calls from other dynamic libraries because those libraries import the version of printf from libSystem. To help folks who rely on techniques like this, macOS supports a flat namespace compatibility mode. This has numerous sharp edges — for an example, see the posts on this thread — and it’s best to avoid it where you can. If you’re enabling the flat namespace as part of a developer tool, search the ’net for dyld interpose to learn about an alternative technique. WARNING Dynamic linker interposing is not documented as API. While it’s a useful technique for developer tools, do not use it in products you ship to end users. Apple platforms use DWARF. When you compile a file, the compiler puts the debug info into the resulting object file. When you link a set of object files into a executable, dynamic library, or bundle for distribution, the linker does not include this debug info. Rather, debug info is stored in a separate debug symbols document package. This has the extension .dSYM and is created using dsymutil. Use symbols to learn about the symbols in a file. Use dwarfdump to get detailed information about DWARF debug info. Use atos to map an address to its corresponding symbol name. Different languages use different name mangling schemes: C, and all later languages, add a leading underscore (_) to distinguish their symbols from assembly language symbols. C++ uses a complex name mangling scheme. Use the c++filt tool to undo this mangling. Likewise, for Swift. Use swift demangle to undo this mangling. Over the years there have been some really good talks about linking and libraries at WWDC, including: WWDC 2023 Session 10268 Meet mergeable libraries WWDC 2022 Session 110362 Link fast: Improve build and launch times WWDC 2022 Session 110370 Debug Swift debugging with LLDB WWDC 2021 Session 10211 Symbolication: Beyond the basics WWDC 2019 Session 416 Binary Frameworks in Swift — Despite the name, this covers XCFrameworks in depth. WWDC 2018 Session 415 Behind the Scenes of the Xcode Build Process WWDC 2017 Session 413 App Startup Time: Past, Present, and Future WWDC 2016 Session 406 Optimizing App Startup Time Note The older talks are no longer available from Apple, but you may be able to find transcripts out there on the ’net. Historically Apple published a document, Mac OS X ABI Mach-O File Format Reference, or some variant thereof, that acted as the definitive reference to the Mach-O file format. This document is no longer available from Apple. If you’re doing serious work with Mach-O, I recommend that you find an old copy. It’s definitely out of date, but there’s no better place to get a high-level introduction to the concepts. The Mach-O Wikipedia page has a link to an archived version of the document. For the most up-to-date information about Mach-O, see the declarations and doc comments in <mach-o/loader.h>. Revision History 2024-05-08 Added links to the demangling tools. 2024-04-30 Clarified the requirement to use the standard dynamic linker. 2024-03-02 Updated the discussion of static frameworks to account for Xcode 15 changes. Removed the link to WWDC 2018 Session 415 because it no longer works )-: 2024-03-01 Added the WWDC 2023 session to the list of sessions to make it easier to find. Added a reference to Using a Link Map to Track Down a Symbol’s Origin. Made other minor editorial changes. 2023-09-20 Added a link to Dynamic Library Identification. Updated the names for the static linker implementations (-ld_prime is no more!). Removed the beta epithet from Xcode 15. 2023-06-13 Defined the term Mach-O image. Added sections for both the static and dynamic linkers. Described the two big new features in Xcode 15: mergeable libraries and dependency verification. 2023-06-01 Add a reference to tapi-analyze. 2023-05-29 Added a discussion of the two-level namespace. 2023-04-27 Added a mention of the size tool. 2023-01-23 Explained the compile-time and run-time roles of a framework. Made other minor editorial changes. 2022-11-17 Added an explanation of TAPI. 2022-10-12 Added links to Mach-O documentation. 2022-09-29 Added info about .dSYM files. Added a few more links to WWDC sessions. 2022-09-21 First posted.

Recently a bunch of folks have asked about why a specific symbol is being referenced by their app. This is my attempt to address that question. If you have questions or comments, please start a new thread. Tag it with Linker so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Determining Why a Symbol is Referenced In some situations you might want to know why a symbol is referenced by your app. For example: You might be working with a security auditing tool that flags uses of malloc. You might be creating a privacy manifest and want to track down where your app is calling stat. This post is my attempt at explaining a general process for tracking down the origin of these symbol references. This process works from ‘below’. That is, it works ‘up’ from you app’s binary rather than ‘down’ from your app’s source code. That’s important because: It might be hard to track down all of your source code, especially if you’re using one or more package management systems. If your app has a binary dependency on a static library, dynamic library, or framework, you might not have access to that library’s source code. IMPORTANT This post assumes the terminology from An Apple Library Primer. Read that before continuing here. The general outline of this process is: Find all Mach-O images. Find the Mach-O image that references the symbol. Find the object files (.o) used to make that Mach-O. Find the object file that references the symbol. Find the code within that object file. This post assumes that you’re using Xcode. If you’re using third-party tools that are based on Apple tools, and specifically Apple’s linker, you should be able to adapt this process to your tooling. If you’re using a third-party tool that has its own linker, you’ll need to ask for help via your tool’s support channel. Find all Mach-O images On Apple platforms an app consists of a number of Mach-O images. Every app has a main executable. The app may also embed dynamic libraries or frameworks. The app may also embed app extensions or system extensions, each of which have their own executable. And a Mac app might have embedded bundles, helper tools, XPC services, agents, daemons, and so on. To find all the Mach-O images in your app, combine the find and file tools. For example: % find "Apple Configurator.app" -print0 | xargs -0 file | grep Mach-O Apple Configurator.app/Contents/MacOS/Apple Configurator: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64] … Apple Configurator.app/Contents/MacOS/cfgutil: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] … Apple Configurator.app/Contents/Extensions/ConfiguratorIntents.appex/Contents/MacOS/ConfiguratorIntents: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] … Apple Configurator.app/Contents/Frameworks/ConfigurationUtilityKit.framework/Versions/A/ConfigurationUtilityKit: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64] … This shows that Apple Configurator has a main executable (Apple Configurator), a helper tool (cfgutil), an app extension (ConfiguratorIntents), a framework (ConfigurationUtilityKit), and many more. This output is quite unwieldy. For nicer output, create and use a shell script like this: % cat FindMachO.sh #! /bin/sh # Passing `-0` to `find` causes it to emit a NUL delimited after the # file name and the `:`. Sadly, macOS `cut` doesn’t support a nul # delimiter so we use `tr` to convert that to a DLE (0x01) and `cut` on # that. # # Weirdly, `find` only inserts the NUL on the primary line, not the # per-architecture Mach-O lines. We use that to our advantage, filtering # out the per-architecture noise by only passing through lines # containing a DLE. find "$@" -type f -print0 \ | xargs -0 file -0 \ | grep -a Mach-O \ | tr '\0' '\1' \ | grep -a $(printf '\1') \ | cut -d $(printf '\1') -f 1 Find the Mach-O image that references the symbol Once you have a list of Mach-O images, use nm to find the one that references the symbol. The rest of this post investigate a test app, WaffleVarnishORama, that’s written in Swift but uses waffle management functionality from the libWaffleCore.a static library. The goal is to find the code that calls calloc. This app has a single Mach-O image: % FindMachO.sh "WaffleVarnishORama.app" WaffleVarnishORama.app/WaffleVarnishORama Use nm to confirm that it references calloc: % nm "WaffleVarnishORama.app/WaffleVarnishORama" | grep "calloc" U _calloc The _calloc symbol has a leading underscore because it’s a C symbol. This convention dates from the dawn of Unix, where the underscore distinguish C symbols from assembly language symbols. The U prefix indicates that the symbol is undefined, that is, the Mach-O images is importing the symbol. If the symbol name is prefixed by a hex number and some other character, like T or t, that means that the library includes an implementation of calloc. That’s weird, but certainly possible. OTOH, if you see this then you know this Mach-O image isn’t importing calloc. IMPORTANT If this Mach-O isn’t something that you build — that is, you get this Mach-O image as a binary from another developer — you won’t be able to follow the rest of this process. Instead, ask for help via that library’s support channel. Find the object files used to make that Mach-O image The next step is to track down which .o file includes the reference to calloc. Do this by generating a link map. A link map is an old school linker feature that records the location, size, and origin of every symbol added to the linker’s output. To generate a link map, enable the Write Link Map File build setting. By default this puts the link map into a text (.txt) file within the derived data directory. To find the exact path, look at the Link step in the build log. If you want to customise this, use the Path to Link Map File build setting. A link map has three parts: A simple header A list of object files used to build the Mach-O image A list of sections and their symbols In our case the link map looks like this: # Path: …/WaffleVarnishORama.app/WaffleVarnishORama # Arch: arm64 # Object files: [ 0] linker synthesized [ 1] objc-file [ 2] …/AppDelegate.o [ 3] …/MainViewController.o [ 4] …/libWaffleCore.a[2](WaffleCore.o) [ 5] …/Foundation.framework/Foundation.tbd … # Sections: # Address Size Segment Section 0x100008000 0x00001AB8 __TEXT __text … The list of object files contains: An object file for each of our app’s source files — That’s AppDelegate.o and MainViewController.o in this example. A list of static libraries — Here that’s just libWaffleCore.a. A list of dynamic libraries — These might be stub libraries (.tbd), dynamic libraries (.dylib), or frameworks (.framework). Focus on the object files and static libraries. The list of dynamic libraries is irrelevant because each of those is its own Mach-O image. Find the object file that references the symbol Once you have list of object files and static libraries, use nm to each one for the calloc symbol: % nm "…/AppDelegate.o" | grep calloc % nm "…/MainViewController.o" | grep calloc % nm "…/libWaffleCore.a" | grep calloc U _calloc This indicates that only libWaffleCore.a references the calloc symbol, so let’s focus on that. Note As in the Mach-O case, the U prefix indicates that the symbol is undefined, that is, the object file is importing the symbol. Find the code within that object file To find the code within the object file that references the symbol, use the objdump tool. That tool takes an object file as input, but in this example we have a static library. That’s an archive containing one or more object files. So, the first step is to unpack that archive: % mkdir "libWaffleCore-objects" % cd "libWaffleCore-objects" % ar -x "…/libWaffleCore.a" % ls -lh total 24 -rw-r--r-- 1 quinn staff 4.1K 8 May 11:24 WaffleCore.o -rw-r--r-- 1 quinn staff 56B 8 May 11:24 __.SYMDEF SORTED There’s only a single object file in that library, which makes things easy. If there were a multiple, run the following process over each one independently. To find the code that references a symbol, run objdump with the -S and -r options: % xcrun objdump -S -r "WaffleCore.o" … ; extern WaffleRef newWaffle(void) { 0: d10083ff sub sp, sp, #32 4: a9017bfd stp x29, x30, [sp, #16] 8: 910043fd add x29, sp, #16 c: d2800020 mov x0, #1 10: d2800081 mov x1, #4 ; Waffle * result = calloc(1, sizeof(Waffle)); 14: 94000000 bl 0x14 <ltmp0+0x14> 0000000000000014: ARM64_RELOC_BRANCH26 _calloc … Note the ARM64_RELOC_BRANCH26 line. This tells you that the instruction before that — the bl at offset 0x14 — references the _calloc symbol. IMPORTANT The ARM64_RELOC_BRANCH26 relocation is specific to the bl instruction in 64-bit Arm code. You’ll see other relocations for other instructions. And the Intel architecture has a whole different set of relocations. So, when searching this output don’t look for ARM64_RELOC_BRANCH26 specifically, but rather any relocation that references _calloc. In this case we’ve built the object file from source code, so WaffleCore.o contains debug symbols. That allows objdump include information about the source code context. From that, we can easily see that calloc is referenced by our newWaffle function. To see what happens when you don’t have debug symbols, create an new object file with them stripped out: % cp "WaffleCore.o" "WaffleCore-stripped.o" % strip -x -S "WaffleCore-stripped.o" Then repeat the objdump command: % xcrun objdump -S -r "WaffleCore-stripped.o" … 0000000000000000 <_newWaffle>: 0: d10083ff sub sp, sp, #32 4: a9017bfd stp x29, x30, [sp, #16] 8: 910043fd add x29, sp, #16 c: d2800020 mov x0, #1 10: d2800081 mov x1, #4 14: 94000000 bl 0x14 <_newWaffle+0x14> 0000000000000014: ARM64_RELOC_BRANCH26 _calloc … While this isn’t as nice as the previous output, you can still see that newWaffle is calling calloc.

Hi,for the past 2 days i ve been going crazy over this problem i am having with my mackbook air, i recntly got a 2019 13 inch model and i basically factory reset it wyping the disk and reinstalling os,it booted in mac os mohave 10.14.6 and ive been trying evr since to update it to sonoma but each time the download is doneand it says the mac is about to reboot to install it screen may turn off up to a min it does not ,it just goes black for a second and then boots back into mojave without even a failed to install promt,it just acts like nothing happened and then ask to install it again. At this point i ve checke for evrything, i dont have antivirus or storage problems since essentially it s a blank mackbook without any apps ,i tried to install a combo update after realising that i have a security update for 10.14.6 that does almost the same thing but this time i do get a promt that an error occured and it sends me to disk startup to boot it again but it didnt work,i tried updating to a previous version like big sur hoping it was too big of a leap and that even tho evrywere i checked it said its compatible maybe it was not but nope exact same thing as sonoma i cnt boot it from a usb cuz i only have usb c ports(idiotic design from apple) i dont know what else to do it seems like no one had on the entire the same prob so i am here after the 12 th try hoping somebody has a fix.