This posts collects together a bunch of information about the symbols found in a Mach-O file. It assumes the terminology defined in An Apple Library Primer. If you’re unfamiliar with a term used here, look there for the definition. If you have any questions or comments about this, start a new thread in the Developer Tools & Services > General topic area and tag it with Linker. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Understanding Mach-O Symbols Every Mach-O file has a symbol table. This symbol table has many different uses: During development, it’s written by the compiler. And both read and written by the linker. And various other tools. During execution, it’s read by the dynamic linker. And also by various APIs, most notably dlsym. The symbol table is an array of entries. The format of each entry is very simple, but they have been used and combined in various creative ways to achieve a wide range of goals. For example: In a Mach-O object file, there’s an entry for each symbol exported to the linker. In a Mach-O image, there’s an entry for each symbol exported to the dynamic linker. And an entry for each symbol imported from dynamic libraries. Some entries hold information used by the debugger. See Debug Symbols, below. Examining the Symbol Table There are numerous tools to view and manipulate the symbol table, including nm, dyld_info, symbols, strip, and nmedit. Each of these has its own man page. A good place to start is nm: % nm Products/Debug/TestSymTab U ___stdoutp 0000000100000000 T __mh_execute_header U _fprintf U _getpid 0000000100003f44 T _main 0000000100008000 d _tDefault 0000000100003ecc T _test 0000000100003f04 t _testHelper Note In the examples in this post, TestSymTab is a Mach-O executable that’s formed by linking two Mach-O object files, main.o and TestCore.o. There are three columns here, and the second is the most important. It’s a single letter indicating the type of the entry. For example, T is a code symbol (in Unix parlance, code is in the text segment), D is a data symbol, and so on. An uppercase letter indicates that the symbol is visible to the linker; a lowercase letter indicates that it’s internal. An undefined (U) symbol has two potential meanings: In a Mach-O image, the symbol is typically imported from a specific dynamic library. The dynamic linker connects this import to the corresponding exported symbol of the dynamic library at load time. In a Mach-O object file, the symbol is undefined. In most cases the linker will try to resolve this symbol at link time. Note The above is a bit vague because there are numerous edge cases in how the system handles undefined symbols. For more on this, see Undefined Symbols, below. The first column in the nm output is the address associated with the entry, or blank if an address is not relevant for this type of entry. For a Mach-O image, this address is based on the load address, so the actual address at runtime is offset by the slide. See An Apple Library Primer for more about those concepts. The third column is the name for this entry. These names have a leading underscore because that’s the standard name mangling for C. See An Apple Library Primer for more about name mangling. The nm tool has a lot of formatting options. The ones I use the most are: -m — This prints more information about each symbol table entry. For example, if a symbol is imported from a dynamic library, this prints the library name. For a concrete example, see A Deeper Examination below. -a — This prints all the entries, including debug symbols. We’ll come back to that in the Debug Symbols section, below. -p — By default nm sorts entries by their address. This disables that sort, causing nm to print the entries in the order in which they occur in the symbol table. -x — This outputs entries in a raw format, which is great when you’re trying to understand what’s really going on. See Raw Symbol Information, below, for an example of this. A Deeper Examination To get more information about each symbol table, run nm with the -m option: % nm -m Products/Debug/TestSymTab (undefined) external ___stdoutp (from libSystem) 0000000100000000 (__TEXT,__text) [referenced dynamically] external __mh_execute_header (undefined) external _fprintf (from libSystem) (undefined) external _getpid (from libSystem) 0000000100003f44 (__TEXT,__text) external _main 0000000100008000 (__DATA,__data) non-external _tDefault 0000000100003ecc (__TEXT,__text) external _test 0000000100003f04 (__TEXT,__text) non-external _testHelper This contains a world of extra information about each entry. For example: You no longer have to remember cryptic single letter codes. Instead of U, you get undefined. If the symbol is imported from a dynamic library, it gives the name of that dynamic library. Here we see that _fprintf is imported from the libSystem library. It surfaces additional, more obscure information. For example, the referenced dynamically flag is a flag used by the linker to indicate that a symbol is… well… referenced dynamically, and thus shouldn’t be dead stripped. Undefined Symbols Mach-O’s handling of undefined symbols is quite complex. To start, you need to draw a distinction between the linker (aka the static linker) and the dynamic linker. Undefined Symbols at Link Time The linker takes a set of files as its input and produces a single file as its output. The input files can be Mach-O images or dynamic libraries [1]. The output file is typically a Mach-O image [2]. The goal of the linker is to merge the object files, resolving any undefined symbols used by those object files, and create the Mach-O image. There are two standard ways to resolve an undefined symbol: To a symbol exported by another Mach-O object file To a symbol exported by a dynamic library In the first case, the undefined symbol disappears in a puff of linker magic. In the second case, it records that the generated Mach-O image depends on that dynamic library [3] and adds a symbol table entry for that specific symbol. That entry is also shown as undefined, but it now indicates the library that the symbol is being imported from. This is the core of the two-level namespace. A Mach-O image that imports a symbol records both the symbol name and the library that exports the symbol. The above describes the standard ways used by the linker to resolve symbols. However, there are many subtleties here. The most radical is the flat namespace. That’s out of scope for this post, because it’s a really bad option for the vast majority of products. However, if you’re curious, the ld man page has some info about how symbol resolution works in that case. A more interesting case is the -undefined dynamic_lookup option. This represents a halfway house between the two-level namespace and the flat namespace. When you link a Mach-O image with this option, the linker resolves any undefined symbols by adding a dynamic lookup undefined entry to the symbol table. At load time, the dynamic linker attempts to resolve that symbol by searching all loaded images. This is useful if your software works on other Unix-y platforms, where a flat namespace is the norm. It can simplify your build system without going all the way to the flat namespace. Of course, if you use this facility and there are multiple libraries that export that symbol, you might be in for a surprise! [1] These days it’s more common for the build system to pass a stub library (.tbd) to the linker. The effect is much the same as passing in a dynamic library. In this discussion I’m sticking with the old mechanism, so just assume that I mean dynamic library or stub library. If you’re unfamiliar with the concept of a stub library, see An Apple Library Primer. [2] The linker can also merge the object files together into a single object file, but that’s relatively uncommon operation. For more on that, see the discussion of the -r option in the ld man page. [3] It adds an LC_LOAD_DYLIB load command with the install name from the dynamic library. See Dynamic Library Identification for more on that. Undefined Symbols at Load Time When you load a Mach-O image the dynamic linker is responsible for finding all the libraries it depends on, loading them, and connecting your imports to their exports. In the typical case the undefined entry in your symbol table records the symbol name and the library that exports the symbol. This allows the dynamic linker to quickly and unambiguously find the correct symbol. However, if the entry is marked as dynamic lookup [1], the dynamic linker will search all loaded images for the symbol and connect your library to the first one it finds. If the dynamic linker is unable to find a symbol, its default behaviour is to fail the load of the Mach-O image. This changes if the symbol is a weak reference. In that case, the dynamic linking continues to load the image but sets the address of the symbol to NULL. See Weak vs Weak vs Weak, below, for more about this. [1] In this case nm shows the library name as dynamically looked up. Weak vs Weak vs Weak Mach-O supports two different types of weak symbols: Weak references (aka weak imports) Weak definitions IMPORTANT If you use the term weak without qualification, the meaning depends on your audience. App developers tend to assume that you mean a weak reference whereas folks with a C++ background tend to assume that you mean a weak definition. It’s best to be specific. Weak References Weak references support the availability mechanism on Apple platforms. Most developers build their apps with the latest SDK and specify a deployment target, that is, the oldest OS version on which their app runs. Within the SDK, each declaration is annotated with the OS version that introduced that symbol [1]. If the app uses a symbol introduced later than its deployment target, the compiler flags that import as a weak reference. The app is then responsible for not using the symbol if it’s run on an OS release where it’s not available. For example, consider this snippet: #include <xpc/xpc.h> void testWeakReference(void) { printf("%p\n", xpc_listener_set_peer_code_signing_requirement); } The xpc_listener_set_peer_code_signing_requirement function is declared like so: API_AVAILABLE(macos(14.4)) … int xpc_listener_set_peer_code_signing_requirement(…); The API_AVAILABLE macro indicates that the symbol was introduced in macOS 14.4. If you build this code with the deployment target set to macOS 13, the symbol is marked as a weak reference: % nm -m Products/Debug/TestWeakRefC … (undefined) weak external _xpc_listener_set_peer_code_signing_requirement (from libSystem) If you run the above program on macOS 13, it’ll print NULL (actually 0x0). Without support for weak references, the dynamic linker on macOS 13 would fail to load the program because the _xpc_listener_set_peer_code_signing_requirement symbol is unavailable. [1] In practice most of the SDK’s declarations don’t have availability annotations because they were introduced before the minimum deployment target supported by that SDK. Weak definitions Weak references are about imports. Weak definitions are about exports. A weak definition allows you to export a symbol from multiple images. The dynamic linker coalesces these symbol definitions. Specifically: The first time it loads a library with a given weak definition, the dynamic linker makes it the primary. It registers that definition such that all references to the symbol resolve to it. This registration occurs in a namespace dedicated to weak definitions. That namespace is flat. Any subsequent definitions of that symbol are ignored. Weak definitions are weird, but they’re necessary to support C++’s One Definition Rule in a dynamically linked environment. IMPORTANT Weak definitions are not just weird, but also inefficient. Avoid them where you can. To flush out any unexpected weak definitions, pass the -warn_weak_exports option to the static linker. The easiest way to create a weak definition is with the weak attribute: __attribute__((weak)) void testWeakDefinition(void) { } IMPORTANT The C++ compiler can generate weak definitions without weak ever appearing in your code. This shows up in nm like so: % nm -m Products/Debug/TestWeakDefC … 0000000100003f40 (__TEXT,__text) weak external _testWeakDefinition … The output is quite subtle. A symbol flagged as weak external is either a weak reference or a weak definition depending on whether it’s undefined or not. For clarity, use dyld_info instead: % dyld_info -imports -exports Products/Debug/TestWeakRefC Products/Debug/TestWeakDefC [arm64]: … -imports: … 0x0001 _xpc_listener_set_peer_code_signing_requirement [weak-import] (from libSystem) % dyld_info -imports -exports Products/Debug/TestWeakDefC Products/Debug/TestWeakDefC [arm64]: -exports: offset symbol … 0x00003F40 _testWeakDefinition [weak-def] … … Here, weak-import indicates a weak reference and weak-def a weak definition. Weak Library There’s one final confusing use of the term weak, that is, weak libraries. A Mach-O image includes a list of imported libraries and a list of symbols along with the libraries they’re imported from. If an image references a library that’s not present, the dynamic linker will fail to load the library even if all the symbols it references in that library are weak references. To get around this you need to mark the library itself as weak. If you’re using Xcode it will often do this for your automatically. If it doesn’t, mark the library as optional in the Link Binary with Libraries build phase. Use otool to see whether a library is required or optional. For example, this shows an optional library: % otool -L Products/Debug/TestWeakRefC Products/Debug/TestWeakRefC: /usr/lib/libEndpointSecurity.dylib (… 511.60.5, weak) … In the non-optional case, there’s no weak indicator: % otool -L Products/Debug/TestWeakRefC Products/Debug/TestWeakRefC: /usr/lib/libEndpointSecurity.dylib (… 511.60.5) … Debug Symbols or Why the DWARF still stabs. (-: Historically, all debug information was stored in symbol table entries, using a format knows as stabs. This format is now obsolete, having been largely replaced by DWARF. However, stabs symbols are still used for some specific roles. Note See <mach-o/stab.h> and the stab man page for more about stabs on Apple platforms. See stabs and DWARF for general information about these formats. In DWARF, debug symbols aren’t stored in the symbol table. Rather, debug information is stored in various __DWARF sections. For example: % otool -l Intermediates.noindex/TestSymTab.build/Debug/TestSymTab.build/Objects-normal/arm64/TestCore.o | grep __DWARF -B 1 sectname __debug_abbrev segname __DWARF … The compiler inserts this debug information into the Mach-O object file that it creates. Eventually this Mach-O object file is linked into a Mach-O image. At that point one of two things happens, depending on the Debug Information Format build setting. During day-to-day development, set Debug Information Format to DWARF. When the linker creates a Mach-O image from a bunch of Mach-O object files, it doesn’t do anything with the DWARF information in those objects. Rather, it records references to the source objects files into the final image. This is super quick. When you debug that Mach-O image, the debugger finds those references and uses them to locate the DWARF information in the original Mach-O object files. Each reference is stored in a stabs OSO symbol table entry. To see them, run nm with the -a option: % nm -a Products/Debug/TestSymTab … 0000000000000000 - 00 0001 OSO …/Intermediates.noindex/TestSymTab.build/Debug/TestSymTab.build/Objects-normal/arm64/TestCore.o 0000000000000000 - 00 0001 OSO …/Intermediates.noindex/TestSymTab.build/Debug/TestSymTab.build/Objects-normal/arm64/main.o … Given the above, the debugger knows to look for DWARF information in TestCore.o and main.o. And notably, the executable does not contain any DWARF sections: % otool -l Products/Debug/TestSymTab | grep __DWARF -B 1 % When you build your app for distribution, set Debug Information Format to DWARF with dSYM File. The executable now contains no DWARF information: % otool -l Products/Release/TestSymTab | grep __DWARF -B 1 % Xcode runs dsymutil tool to collect the DWARF information, organise it, and export a .dSYM file. This is actually a document package, within which is a Mach-O dSYM companion file: % find Products/Release/TestSymTab.dSYM Products/Release/TestSymTab.dSYM Products/Release/TestSymTab.dSYM/Contents … Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF/TestSymTab … % file Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF/TestSymTab Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF/TestSymTab: Mach-O 64-bit dSYM companion file arm64 That file contains a copy of the the DWARF information from all the original Mach-O object files, optimised for use by the debugger: % otool -l Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF/TestSymTab | grep __DWARF -B 1 … sectname __debug_line segname __DWARF … Raw Symbol Information As described above, each Mach-O file has a symbol table that’s an array of symbol table entries. The structure of each entry is defined by the declarations in <mach-o/nlist.h> [1]. While there is an nlist man page, the best documentation for this format is the the comments in the header itself. Note The terms nlist stands for name list and dates back to truly ancient versions of Unix. Each entry is represented by an nlist_64 structure (nlist for 32-bit Mach-O files) with five fields: n_strx ‘points’ to the string for this entry. n_type encodes the entry type. This is actually split up into four subfields, as discussed below. n_sect is the section number for this entry. n_desc is additional information. n_value is the address of the symbol. The four fields within n_type are N_STAB (3 bits), N_PEXT (1 bit), N_TYPE (3 bits), and N_EXT (1 bit). To see these raw values, run nm with the -x option: % nm -a -x Products/Debug/TestSymTab … 0000000000000000 01 00 0300 00000036 _getpid 0000000100003f44 24 01 0000 00000016 _main 0000000100003f44 0f 01 0000 00000016 _main … This prints a column for n_value, n_type, n_sect, n_desc, and n_strx. The last column is the string you get when you follow the ‘pointer’ in n_strx. The mechanism used to encode all the necessary info into these fields is both complex and arcane. For the details, see the comments in <mach-o/nlist.h> and <mach-o/stab.h>. However, just to give you a taste: The entry for getpid has an n_type field with just the N_EXT flag set, indicating that this is an external symbol. The n_sect field is 0, indicating a text symbol. And n_desc is 0x0300, with the top byte indicating that the symbol is imported from the third dynamic library. The first entry for _main has an n_type field set to N_FUN, indicating a stabs function symbol. The n_desc field is the line number, that is, line 22. The second entry for _main has an n_type field with N_TYPE set to N_SECT and the N_EXT flag set, indicating a symbol exported from a section. In this case the section number is 1, that is, the text section. [1] There is also an <nlist.h> header that defines an API that returns the symbol table. The difference between <nlist.h> and <mach-o/nlist.h> is that the former defines an API whereas the latter defines the Mach-O on-disk format. Don’t include both; that won’t end well!

I'm pretty new on this platform and also developing IOS mobile apps. I've been struggling for using the data of the api weather kit apple. I have an acount of apple developer, downloaded the certificate... i follow all the necessaries steps in the portal and also in my project and i keep having this error message when i try to use it. I don't know what else should i do for having working it. I would absolutely appreciate that someone could help me with this. Thank you very much!!!!! Encountered an error when fetching weather data subset; location=<+41.38268070,+2.17702390> +/- 0.00m (speed -1.00 mps / course -1.00) @ 2/3/25, 22:54:03 Central European Standard Time, error=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors 2 Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)"

I can use devicectl to copy single files from a device fine using: xcrun devicectl --verbose device copy from --user mobile --domain-identifier <BUNDLE_ID> --domain-type appDataContainer --device <DEVICE_ID> --source Documents/Screenshots/0001.png --destination Screeshots/0001.png but when there are many files this can get pretty slow. Is there a way of recursively copying an entire directory? I've tried this: xcrun devicectl --verbose device copy from --user mobile --domain-identifier <BUNDLE_ID> --domain-type appDataContainer --device <DEVICE_ID> --source Documents/Screenshots --destination Screeshots but nothing is transferred and it times out eventually with the error: ERROR: The specified file could not be transferred. (com.apple.dt.CoreDeviceError error 7000 (0x1B58)) ERROR: The operation couldn’t be completed. The file service client failed to read data from the network socket because we timed out when waiting for data to become available. (NSPOSIXErrorDomain error 60 (0x3C)) NSLocalizedFailureReason = The file service client failed to read data from the network socket because we timed out when waiting for data to become available. Xcode itself can do it with the "download container..." option, but I'd like to be able to automate it.

Hello, I've noticed that many people on the forum are experiencing issues enrolling in the Apple Developer Program. I’m facing the same problem—I can't complete my enrollment using my MacBook Pro. When I try to enroll through the Apple Developer app, I get an error saying, "Enrollment through the Apple Developer app is not available for this Apple ID." So, I tried using Safari instead. I submitted all my personal information and credit card details and initiated the order. However, no transaction was processed from my bank account, and I received an email stating that I would be notified when my order and items are ready. When I check the Apple Developer portal, my enrollment status is Pending, and I see a message prompting me to complete the purchase, as if I need to make a new payment. I don’t understand why Apple makes it so complicated just to subscribe to the Developer Program. Why can’t I use my MacBook Pro for enrollment? Why does the Developer portal ask me to complete the purchase even though I already submitted my payment details? Why is the process so confusing? Any help or clarification would be greatly appreciated. Thanks!

Hello Apple Developer Community, I recently created a fresh project with: No dependencies No additional written code After generating the iOS build, I navigated to the build folder: cd build/ios/iphoneos/Runner.app Then, I ran the following commands to inspect the binary: otool -Iv Runner | grep -w _strlen otool -Iv Runner | grep -w _malloc Surprisingly, I received positive results, meaning these functions are present in the binary. My Questions: Why is a fresh Flutter project (with no extra dependencies) including these APIs in the binary?

I'm currently writing a macro which outputs Swift Testing code: // Macro code ... @MainActor @SnapshotSuite struct MySuite { func makeView() -&gt; some View { Text("a view") } } which expands to... // Expanded macro code ... @MainActor @Suite struct _GeneratedSnapshotSuite { @MainActor @Test(.tags(.snapshots)) func assertSnapshotMakeView() async throws { let generator = SnapshotGenerator( testName: "makeView", traits: [ .theme(.all), .sizes(devices: .iPhoneX, fitting: .widthAndHeight), .record(false), ], configuration: .none, makeValue: { MySuite().makeView() }, fileID: #fileID, filePath: #filePath, line: 108, column: 5 ) await __assertSnapshot(generator: generator) } } In short, this macro creates snapshot tests from a function. This all works but I'm finding a couple of limitations, potentially with how Macros are expanded in Swift. Xcode diamonds are not visible The snapshots tag isn't discovered There are a couple of things worth noting though: The suites and tests are discovered in Xcode's Test Navigator each time Xcode runs tests (cmd + u) - although they need to rerun to be updated. I manually add a @Suite in my code as well as my @SnapshotSuite to all of the suites. (The tags never seem to be available though) Couple of questions on this: Is this a known issue? Are there any workarounds? I do wonder if there's a workaround for showing the diamonds with XCTest APIs such as: https://github.com/swiftlang/swift-corelibs-xctest/tree/main https://developer.apple.com/documentation/xctest

I am currently developing a No-Sandbox application. What I want to achieve is to use AuthorizationCopyRights in a No-Sandbox application to elevate to root, then register SMAppService.daemon after elevation, and finally call the registered daemon from within the No-Sandbox application. Implementation Details Here is the Plist that I am registering with SMAppService: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.example.agent</string> <key>BundleProgram</key> <string>/usr/local/bin/test</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/test</string> <string>login</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> Code that successfully performs privilege escalation (a helper tool popup appears) private func registerSMAppServiceDaemon() -> Bool { let service = SMAppService.daemon(plistName: "com.example.plist") do { try service.register() print("Successfully registered \(service)") return true } catch { print("Unable to register \(error)") return false } } private func levelUpRoot() -> Bool { var authRef: AuthorizationRef? let status = AuthorizationCreate(nil, nil, [], &authRef) if status != errAuthorizationSuccess { return false } let rightName = kSMRightBlessPrivilegedHelper return rightName.withCString { cStringName -> Bool in var authItem = AuthorizationItem( name: cStringName, valueLength: 0, value: nil, flags: 0 ) return withUnsafeMutablePointer(to: &authItem) { authItemPointer -> Bool in var authRights = AuthorizationRights(count: 1, items: authItemPointer) let authFlags: AuthorizationFlags = [.interactionAllowed, .preAuthorize, .extendRights] let status = AuthorizationCopyRights(authRef!, &authRights, nil, authFlags, nil) if status == errAuthorizationSuccess { if !registerSMAppServiceDaemon() { return false } return true } return false } } } Error Details Unable to register Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} The likely cause of this error is that /usr/local/bin/test is being bundled. However, based on my understanding, since this is a non-sandboxed application, the binary should be accessible as long as it is run as root. Trying post as mentioned in the response, placing the test binary under Contents/Resources/ allows SMAppService to successfully register it. However, executing the binary results in a different error. Here is the plist at that time. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.example.agent</string> <key>BundleProgram</key> <string>Contents/Resources/test</string> <key>ProgramArguments</key> <array> <string>Contents/Resources/test</string> <string>login</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> Here is the function at that time. private func executeBin() { let bundle = Bundle.main if let binaryPath = bundle.path(forResource: "test", ofType: nil) { print(binaryPath) let task = Process() task.executableURL = URL(fileURLWithPath: binaryPath) task.arguments = ["login"] let pipe = Pipe() task.standardOutput = pipe task.standardError = pipe do { try task.run() let outputData = pipe.fileHandleForReading.readDataToEndOfFile() if let output = String(data: outputData, encoding: .utf8) { print("Binary output: \(output)") } task.waitUntilExit() if task.terminationStatus == 0 { print("Binary executed successfully") } else { print("Binary execution failed with status: \(task.terminationStatus)") } } catch { print("Error executing binary: \(error)") } } else { print("Binary not found in the app bundle") } } Executed After Error Binary output: Binary execution failed with status: 5 Are there any other ways to execute a specific binary as root when using AuthorizationCopyRights? For example, by preparing a Helper Tool?

Hello Apple Developer Community, I recently created a fresh project with: No dependencies No additional written code After generating the iOS build, I navigated to the build folder:"build/ios/iphoneos/Runner.app" Then, I ran the following otool commands to inspect the binary: otool -Iv Runner | grep -w _strlen otool -Iv Runner | grep -w _malloc Surprisingly, I received positive results, meaning these functions are present in the binary. My Questions: Why is a fresh project (with no extra dependencies & No additional written code) including these APIs in the binary?

Hi, I want to build an ios app that uses static c libraries. For reference, i did the following as a test: Compiled a simple c date and time program with clang -c -arch arm64 -sysroot <iPhoneOSSDK_path> date.c -o date_arm64.o Created the static lib ar rcs libdatetime_arm64.a date_arm64.o Added the lib in my Xcode project. Added the (.a) file in Build Rules -> Link Binary With Libraries Included the (.a) and (.h) file path in Build Settings -> Search Paths -> Header and Library Search Path Created a Bridging-Header.h file where I added #import "date.h" In my App.swift file, I called the function for getting the date and time let dateTimeStr = String(cString: get_current_datetime()) print("Current Date and Time: \(dateTimeStr)") After doing all the steps above, I am met with the error - Cannot find 'get_current_datetime' in scope Is there any other method to use static c libraries in xcode?

I have used XCode for decades as my default C/C++ programming IDE. I write code that I run locally on my Mac, via "Sign to run locally". Typically this has always "just worked". I am now using MacOS 14.7 Sonoma, and I suddenly find I cannot run my code projects because I cannot dynamically load unsigned libraries. "not valid for use in process: library load disallowed by system policy" BUT - it appears that to allow my local MacOS code to bypass this requires I have a bundle identifier to modify entitlements. Which in turn requires a developer account which I don't have. Is this all correct? Is there any way to have code run locally and use dynamic libraries as I've done previously? Any advice is much appreciated.

I can see that a MacOS VM guest running on top of an Apple Silicon MacOS host has GPU acceleration - indicating GPU sharing capabilities for the hardware. Is there also a way to have GPU acceleration in Linux guests (with Vulkan/Mesa drivers)?

What I want? I expect to use xcrun devicectl device process launch --device <uuid> <bundle-identifier> --payload-url <URL> to launch my app and pass the specified URL as I usually do in iPhone. What I do? Let's say the app A which I'm developing. I try to use UIApplication.open(:options:completionHandler:) in another app to open the app A with registered schema. And whether app A is cold launch or background resumption, app A can go foreground with receiving URL. If I use xcrun devicectl as above described, app A can still be opened. However, app A can't receive URL which I pass through --payload-url option. That's different from in iOS. BTW: I as well try YouTube with UIApplication.open and xcrun devicectl, the former way work, the latter way not work.

This morning I installed podman on my new Apple laptop. It can be inited successfully but failed to start. The error is: Error: Error Domain=VZErrorDomain Code=1 Description="Internal Virtualization error. The virtual machine failed to start." UserInfo={ NSLocalizedFailure = "Internal Virtualization error."; NSLocalizedFailureReason = "The virtual machine failed to start."; My new Mac laptop with the latest OS version: 15.3.1 and it is Apple M4 chip. I verified that my Virtualization.framework is good by ls -l /System/Library/Frameworks/Virtualization.framework also my MacOS support virtualization because sysctl kern.hv_support returns kern.hv_support: 1. I tried to install it on my old Apple laptop which is intel core, same OS version - everything is good. How to fix this issue?

Hi everyone, I am experiencing an issue where I am unable to sign in to my Apple ID within Xcode. Even after updating my password and ensuring that all my credentials are correct, I continue to receive an "Incorrect username or password" error. However, I can successfully log in to Apple Developer Portal, iCloud, and Apple ID settings using the same credentials. Steps I've Taken to Resolve the Issue: Updated Software I have updated macOS Sequoia and Xcode to the latest versions. I have also verified that my Apple Developer certificates are up to date. Tried Resetting Authentication in macOS I removed all related entries for Xcode, Apple ID, and Developer from Keychain Access. Logged out of my Apple ID from System Settings and restarted my Mac. Logged back in and retried signing in to Xcode. Checked Authentication & Security Settings I verified that two-factor authentication (2FA) is enabled. Tried appending the verification code directly to the password when logging into Xcode. Checked Xcode Developer Directory Ran sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer Verified using xcode-select -p, which correctly pointed to the Xcode Developer directory. Tried Resetting Developer Tools Removed and reinstalled Command Line Tools (xcode-select --install). Accepted the Xcode license agreement (sudo xcodebuild -license). Reinstalled Xcode Completely uninstalled Xcode using sudo rm -rf /Applications/Xcode.app and reinstalled it from the Mac App Store. Problem Summary: Xcode does not recognize my Apple ID credentials, despite them being correct. I can successfully log in to Apple’s web services, but not to Xcode. I have already attempted multiple fixes, including resetting keychain entries, reinstalling Xcode, and verifying system configurations. I would appreciate your guidance on resolving this issue, as I need access to my Apple Developer account within Xcode to continue working on my app. Thank you for your support.

When I open developer.apple.com I do not see my other teams on the top right dropdown. After logging in, it directly takes me to one of my teams which is Nautilus and It does not allow me to change to other teams.

We are building a framework which will be used by other apps. Want to integrate crash reporting and diagnostics for our framework. Want to report crashes to our backend happening inside our framework only and ignore app level crashes. Is it possible to filter crashes like that ?

Hello! When trying to use MLTensor, I am getting the error that it is not found in scope even though I am using Xcode 15.1 (it says fully up to date) and set my deployment target to iOS 17.2. Is there something else I need to be doing in order to use MLTensor? Thanks! Michael

Today after I apparently fat fingered/misclicked/misdragged something in Xcode, the short cut for "Reveal in Project Navigator" (cmd+shift+J) stopped working for me. I don't have any custom shortcut bindings and the other shortcuts still work, as far as I can tell. I've deleted and re-installed Xcode; I've run defaults delete com.apple.dt.Xcode to no avail. I'd really like this shortcut back as it's probably my second or third most used one :(

Hello Apple Developer Team, I have been trying to request a correction to my tax invoice for my Apple Developer Program purchase, but I have been continuously redirected between Apple Developer Support and Apple Store Online, with no resolution to my issue. Issue Details: Tax Invoice No.: 0015056100 Problem: The company name is incorrect, and the Tax ID is missing. Correction Requested: Company Name: Bluebik Vulcan Company Limited (Head Office) Tax ID: 0105565196514 Address: No.199 S-OASIS Building, 11th Floor, Unit no. 1103-1106, Vibhavadi Rangsit Road, Chomphon, Chatuchak, Bangkok, Thailand 10900 What Happened: I initially contacted Apple Developer Support, but they informed me that they do not handle invoice modifications and asked me to contact Apple Store Online. When I contacted Apple Store Online, they redirected me back to Developer Support. This back-and-forth has been going on for days, and no one has taken responsibility for my request. I need urgent assistance to resolve this issue. Could someone from Apple clarify which team is responsible for invoice modifications and escalate this matter? I have a Case ID for my request and can provide additional details if needed. Looking forward to a resolution as soon as possible. Best regards, Pornthep Jaroen-ngam | Non Technical Consultant, Associate Director Bluebik Vulcan Company Limited

I am trying to test this simulated Error. The issue is, I can't get this to trigger through the simulatedError function. Error will always end up as an unknown error Example code snippet: @available(iOS 17.0, *) func testPurchase_InvalidQuantity() async throws { // Arrange testSession.clearTransactions() testSession.resetToDefaultState() let productID = "consumable_1" try await testSession.setSimulatedError(.purchase(.invalidQuantity), forAPI: .purchase) guard let product = await fetchProduct(identifier: productID) else { XCTFail("Failed to fetch test product") return } let option = Product.PurchaseOption.quantity(4) let result = await manager.purchase(product: product, options: option) switch result { case .success: XCTFail("Expected failure due to invalid quantity") case .failure(let error): print("Received error: \(error.localizedDescription)") switch error { case .purchaseError(let purchaseError): XCTAssertEqual(purchaseError.code, StoreKitPurchaseError.invalidQuantity.code) default: XCTFail("Unexpected error: \(error)") } } } In the above code snippet, I have an Unexpected Error. But if i remove try await testSession.setSimulatedError(.purchase(.invalidQuantity), forAPI: .purchase) I will receive a XCTFail in the success of my result. So when I set the quantity to a -1, only then can I correctly receive an invalidQuantity. Does anyone know why the try await testSession.setSimulatedError(.purchase(.invalidQuantity), forAPI: .purchase) would fail to work as directed? I have tests for all the generic errors for loadProducts API and the simulatedError works great for them