We have developed a custom iOS framework called PaySDK. Earlier we distributed the framework as PaySDK.xcframework.zip through GitHub (Private repo) with two dependent xcframeworks. Now, one of the clients asking to distribute the framework through Swift Package Manager. I have created a new Private repo in the GitHub, created the new release (iOSSDK_SPM_Test) tag 1.0.0. Uploaded the below frameworks as Assets and updated the downloadable path in the Package.Swift and pushed to the GitHub Main branch. PaySDK.xcframework.zip PaySDKDependentOne.xcframework.zip PaySDKDependentTwo.xcframework.zip When I try to integrate (testing) the (https://github.com/YuvaRepo/iOSSDK_SPM_Test) in Xcode, am not able to download the frameworks, the downloadable path is pointing to some old path (may be cache - https://github.com/YuvaRepo/iOSSDK_SPM/releases/download/1.2.0/PaySDK.xcframework.zip). Package.Swift: // swift-tools-version:5.3 import PackageDescription let package = Package( name: "iOSSDK_SPM_Test", platforms: [ .iOS(.v13) ], products: [ // Products define the executables and libraries a package produces, making them visible to other packages. .library( name: "iOSSDK_SPM_Test", targets: ["PaySDK", "PaySDKDependentOne", "PaySDKDependentTwo"] ) ], targets: [ // Targets are the basic building blocks of a package, defining a module or a test suite. // Targets can depend on other targets in this package and products from dependencies. .binaryTarget( name: "PaySDK", url: "https://github.com/YuvaRepo/iOSSDK_SPM_Test/releases/download/1.0.0/PaySDK.xcframework.zip", checksum: " checksum " ), .binaryTarget( name: "PaySDKDependentOne", url: "https://github.com/YuvaRepo/iOSSDK_SPM_Test/releases/download/1.0.0/PaySDKDependentOne.xcframework.zip", checksum: " checksum " ), .binaryTarget( name: "PaySDKDependentTwo", url: "https://github.com/YuvaRepo/iOSSDK_SPM_Test/releases/download/1.0.0/PaySDKDependentTwo.xcframework.zip", checksum: " checksum " ), .testTarget( name: "iOSSDK_SPM_TestTests", dependencies: ["PaySDK", "PaySDKDependentOne", "PaySDKDependentTwo"] ) ] ) Steps I followed: I have tried below steps, Removed the local repo and cloned new rm -rf ~/Library/Caches/org.swift.swiftpm/ rm -rf ~/Library/Developer/Xcode/DerivedData/* Can anyone help to identify the issue and resolve? Thanks in advance.

in xcode i have select the developer team. but show some error that is here, "Communication with Apple failed Your team has no devices from which to generate a provisioning profile. Connect a device to use or manually add device IDs in Certificates, Identifiers & Profiles. https://developer.apple.com/account/" and show this error also "No profiles for 'com.kuntaldoshi.homeautomation' were found Xcode couldn't find any iOS App Development provisioning profiles matching 'com.kuntaldoshi.homeautomation'."

I regularly see questions from folks who’ve run into problems with their third-party IDE on macOS. Specifically, the issue is that their IDE is invoking Apple’s command-line tools — things like clang and ld — and that’s failing in some way. This post collects my ideas on how to investigate, and potentially resolve, issues like this. If you have any questions or comments, please put them in a new thread here on DevForums. Tag it appropriately so that I see it. Good tags include Compiler, Linker, LLVM, and Command Line Tools. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Investigating Third-Party IDE Integration Problems Many third-party IDEs rely on Apple tools. For example, the IDE might run clang to compile C code or run ld to link object files. These IDEs typically don’t include the tools themselves. Rather, they rely on you to install Xcode or Apple’s Command Line Tools package. These are available at Apple > Developer > Downloads Occasionally I see folks having problems with this. They most typically report that basic stuff, like compiling a simple C program, fails with some mysterious error. If you’re having such a problem, follow the steps below to investigate it. IMPORTANT Some IDEs come with their own tools for compiling and linking. Such IDEs are not the focus of this post. If you have problems with an IDE like that, contact its vendor. Select Your Tools macOS has a concept of the current command-line tools. This can either point to the tools within Xcode or to an installed Command Line Tools package. To see which tools are currently selected, run xcode-select with the --print-path argument. This is what you’ll see if you have Xcode installed in the Applications folder: % xcode-select --print-path /Applications/Xcode.app/Contents/Developer Note All of the tools I discuss here are documented in man pages. If you’re not familiar with those, see Reading UNIX Manual Pages. And this is what you’ll see with a Command Line Tools package selected. % xcode-select --print-path /Library/Developer/CommandLineTools There are two common problems with this: It points to something you’ve deleted. It points to something unexpected. Run the command above to see the current state. If necessary, change the state using the --switch option. For example: % xcode-select --print-path /Applications/Xcode.app/Contents/Developer % clang -v Apple clang version 14.0.3 (clang-1403.0.22.14.1) … % sudo xcode-select --switch ~/XcodeZone/Xcode-beta.app % clang -v Apple clang version 15.0.0 (clang-1500.0.38.1) … I have Xcode 14.3 in the Applications folder and thus clang runs Clang 14.0.3. I have Xcode 15.0b5 in ~/XcodeZone, so switching to that yields Clang 15.0.0. It’s possible to run one specific command with different tools. See Select Your Tools Temporarily, below. Run a Simple Test A good diagnostic test is to use the selected command-line tools to compile a trivial test program. Consider this C [1] example: % cat hello.c #include <stdio.h> int main(int argc, char ** argv) { printf("Hello Cruel World!\n"); return 0; } % clang -o hello hello.c % ./hello Hello Cruel World! IMPORTANT If possible, run this from Terminal rather than, say, over SSH. You may need to expand this test program to exercise your specific case. For example, if your program is hitting an error when it tries to import the Core Foundation framework, add that import to your test program: % cat hello.c #include <stdio.h> #include <CoreFoundation/CoreFoundation.h> int main(int argc, char ** argv) { printf("Hello Cruel World!\n"); return 0; } When you compile your test program, you might see one of these results: Your test program compiles. Your test program fails with a similar error. Your test program fails with a different error. I’ll explore each case in turn. [1] For a C++ example, see C++ Issues, below. If your test program compiles… If your test program compiles from the shell, that proves that your basic command-line tools setup is fine. If the same program fails to compile in your IDE, there’s something IDE-specific going on here. I can’t help you with that. I recommend that you escalate the issue via the support channel for your IDE. If your test program fails with a similar error… If your test program fails with an error similar to the one you’re seeing in your IDE, there are two possibilities: There’s a bug in your test program’s code. There’s an environmental issue that’s affecting your command-line tools setup. Don’t rule out the first possibility. I regularly see folks bump into problems like this, where it turns out to be a bug in their code. For a specific example, see C++ Issues, below. Assuming, however, that your test program’s code is OK, it’s time to investigate environmental issues. See Vary Your Environment, below. If your test program fails with a different error… If your test program fails with a different error, look at the test program’s code to confirm that it’s correct, and that it accurately reflects the code you’re trying to run in your IDE. Vary Your Environment If your test program fails with the same error as you’re seeing in your IDE, and you are sure that the code is correct, it’s time to look for environmental factors. I typically do this with the steps described in the next sections, which are listed from most to least complex. These steps only tell you where things are going wrong, not what is going wrong. However, that’s often enough to continue the investigation of your issue. Vary Your Shell Try running your commands in a different shell. macOS’s default shell is zsh. Try running your commands in bash instead: % bash … bash-3.2$ clang -o hello hello.c bash-3.2$ ./hello Hello Cruel World! Or if you’ve switched your shell to bash, try it in zsh. Vary Your User Account Some problems are caused by settings tied to your user account. To investigate whether that’s an issue here: Use System Settings > Users & Groups to create a new user. Log in as that user. Run your test again. Vary Your Mac Some problems are system wide, so you need to test on a different Mac. The easiest way to do that is to set up a virtual machine (VM) and run your test there. Or, if you have a separate physical Mac, run your test on that. Vary Your Site If you’re working for an organisation, they may have installed software on your Mac that causes problems. If you have a Mac at home, try running your test there. It’s also possible that your network is causing problems [1]. If you have a laptop, try taking it to a different location to see if that changes things. [1] I rarely see this when building a simple test program, but it do see it with other stuff, like code signing. C++ Issues If you’re using C++, here’s a simple test you can try: % cat hello.cpp #include <iostream> int main() { std::cout << "Hello Cruel World!\n"; } % clang++ -o hello hello.cpp % ./hello Hello Cruel World! A classic problem with C++ relates to name mangling. Consider this example: % cat hello.c #include <stdio.h> #include "hello-core.h" int main(int argc, char ** argv) { HCSayHello(); return 0; } % cat hello-core.cpp #include "hello-core.h" #include <iostream> extern void HCSayHello() { std::cout << "Hello Cruel World!\n"; } % cat hello-core.h extern void HCSayHello(); % clang -c hello.c % clang++ -c hello-core.cpp % clang++ -o hello hello.o hello-core.o Undefined symbols for architecture x86_64: "_HCSayHello", referenced from: _main in hello.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) The issue here is that C++ generates a mangled name for HCSayHello: % nm hello-core.o | grep HCSayHello 0000000000000000 T __Z10HCSayHellov whereas C uses the non-mangled name: % nm hello.o | grep HCSayHello U _HCSayHello The fix is an appropriate application of extern "C": % cat hello-core.h extern "C" { extern void HCSayHello(); }; Select Your Tools Temporarily Sometimes you want to temporarily run a command from a particular tools package. To continue my earlier example, I currently have Xcode 14.3 installed in the Applications folder and Xcode 15.0b5 in ~/XcodeZone. Xcode 14.3 is the default but I can override that with the DEVELOPER_DIR environment variable: % clang -v Apple clang version 14.0.3 (clang-1403.0.22.14.1) … % DEVELOPER_DIR=~/XcodeZone/Xcode-beta.app/Contents/Developer clang -v Apple clang version 15.0.0 (clang-1500.0.38.1) … Revision History 2025-01-27 Remove the full width characters. These were a workaround for a forums platform bug that’s since been fixed. Made other minor editorial changes. 2023-07-31 First posted.

iOS simulator way slower to launch after updating to Xcode Version 16.2 (16C5032a). macOS 15.3.1 (24D70) MacBook Air M1, 8GB

Hello, I am working on updating my system for Xcode but it has hanged here from last 4 hours I checked my internet. Thanks Zippy Games

Since updating to Apple Pay SDK 1.2.0, the Apple Pay button is no longer being rendered. Could you please fix this as soon as possible? From my perspective, the issue is clearly on Apple's side because the button renders correctly when I use Apple Pay SDK 1.1.0. So, the problem lies in your update to: https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js. Additionally, I urgently need a contact option regarding the "AbortError", which has recently started occurring for all our customers. Yes, our Apple Pay integration is web-based and has worked flawlessly until now. In the sandbox, Apple Pay still works perfectly! So why, why, why does it no longer work in the production environment? Could you please provide some indication of the cause? An "AbortError" when calling show() on paymentRequest is not helpful at all.

Hello, I made a payment for an Apple Developer account on January 22, 2025, but the processing has not been completed yet. According to Apple's stated timeline, the account should be processed within two business days, but it has now been significantly delayed. I have already sent a follow-up email and a message via the support form, but I have not received any response. I would appreciate any guidance from the community or Apple representatives on how to proceed. Has anyone else faced a similar delay recently? Is there any alternative way to escalate this issue? Looking forward to any insights. Ali

Hello Apple Developer Community, I am encountering an issue while trying to pay the $119.99 Apple Developer Program fee through the Apple Developer app. I have linked a prepaid card to my Apple ID, which works perfectly fine for other purchases and subscriptions, but I am unable to complete the payment for the developer fee. Here are the details of the issue: Payment Method: Prepaid card connected to my Apple ID. Amount: $119.99 (Apple Developer Program fee). Location: Cameroon. Other Transactions: All other purchases and subscriptions using the same prepaid card have been processed successfully without any issues. When I attempt to pay for the developer fee, the payment doesn’t go through, and I receive an error message (Payment Failed). I’ve verified that my card has sufficient funds and that the information is correctly entered in my Apple ID account settings. Has anyone else faced a similar issue, particularly with prepaid cards or payments in Cameroon? Any advice or guidance on how to resolve this problem would be greatly appreciated. Thanks in advance for your help!

I have developed an app that I had been testing on the hardware device with the developer profile signed builds, I had setup a CloudKit container in development mode and also had tested with Production mode and they are working as expected. I have also tested storekit auto renewal subscriptions using Storekit Config file and all of that is working on the hardware device with the developer profile signed builds. Now comes the Fun Part, I want to use the Distribution profile to test the app for production readiness, I had created a distribution profile and had set that up in the Release under target of the app in Xcode, I have also created sandbox tester account (which is showing inactive even after 7 days - though I am also logged in with this sandbox tester account on a hardware device and under developer setting it shows as a sandbox tester account) All the subscriptions are showing Ready to Submit in the App Store Connect. I need help understand this whole flow, how to ensure I can test CloudKit and storekit for production readiness and then publish my app for the review. Thank you.

I have received email about your development certificate has been revoked, but couldn't identify who did that, due to this revocation one of our enterprise application stopped working. So posting here to seek some suggestion on following 1.) Identification of Revoking Party: Though I have already raised a support ticket to Apple still waiting for their reply. Is it possible for Apple to send logs or account activity logs that from which account or who did the revocation? 2.) How much does Apple take to reply to the support tickets. 3.) No one else received email in my development team. Is it because the certificate which I created is revoked that's the reason only I have received email? 4.) May I know what are the other scenarios that certificate can be revoked other than a human error? 5.) Is there a way for us to internally monitor activity within our developer account, such as identifying who has been actively logged in and updating certificates?

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!

Unfortunately, for the past two months I've been trying to migrate to a company account. The banking updates are stuck processing with this error message: Apple Developer support tossed me around between 6 or 7 different representatives, each restarting the process of trying to figure out the problem, contacting the engineering team back and forth, and even remote controlling my screen to try and solve it, to no avail. None of them know what is the issue. What do I do?

I have been invited to teams I can navigate things at https://appstoreconnect.apple.com/ smoothly. But https://developer.apple.com/account does not show teams and don't have access to https://developer.apple.com/account/resources/. Thus my Xcode not showing teams too.

Hello all! My application written with C++/CMake and when building have some troubles with adding test environment for StoreKit every time - it need to be done manually. Is there any way to add StoreKit environment settings with CMake and when executed command like this $ cmake -g Xcode ... StoreKit test environment were automatically added?

Hey folks, We are looking for a way to increase the sampling frequency beyong what's currently called "high frequency sampling" for CPU profiler (or time profiler -- doesn't really matter for us). We are aware that this is not offered through the UI but wondering if we can somehow experimentally enable this via the .tracetemplate (plist). Basically, we see that samplingRate exists (in the plist) but don't see it having an effect on the actual runs. The resulting trace file always lists sample-rate-micro-seconds="1000" for the data table. E.g., <table trigger="time" pmc-events="Cycles" target-pid="SINGLE" schema="counters-profile" needs-kernel-callstack="0" sample-rate-micro-seconds="1000"/> Cheers

Hi everyone, I'm working on an NFC-related app using CoreNFC with APDU commands to read and write tags. I’ve encountered an issue when trying to handle the scenario where the user cancels the NFC session. Here’s what’s happening: When a user cancels the NFC session manually (e.g., by tapping "Cancel"), I see an error log indicating tagReaderSession|userCancelled. However, when I explicitly call session.invalidate(errorMessage: "No NFC tag found") in my code to handle a scenario where no tag is detected, the session still shows the error as userCancelled instead of my custom error message. This behavior is confusing both in terms of debugging and for providing feedback to users, as I expect my custom message to appear instead of the generic "user cancelled" message. func tagReaderSessionDidBecomeActive(_ session: NFCTagReaderSession) { // Session becomes active } func tagReaderSession(_ session: NFCTagReaderSession, didDetect tags: [NFCTag]) { // Handle tag detection logic } func tagReaderSession(_ session: NFCTagReaderSession, didInvalidateWithError error: Error) { print("Session invalidated with error: \(error.localizedDescription)") } func handleNoTagDetected(session: NFCTagReaderSession) { session.invalidate(errorMessage: "No NFC tag found") } I call handleNoTagDetected(session:) explicitly when no tag is detected, expecting the custom error message to show. However, the system still shows the cancellation error. Has anyone else experienced this behavior? Is this the intended behavior for CoreNFC, or am I missing something in my implementation? Any guidance would be appreciated. Thanks in advance!

Hi, Regarding the bundle identifiers of App that I remove from App Store Connect will they be locked forever andI can't reuse them ? Kind Regards

I can sucessfully send pushes to an app (which has been installed/run via Xcode) when the pushes are going through the Apple sandbox server. However I want to test the server is configured correctly to send them through the Apple production server. In the Xcode scheme I tried to change the build configuration to release (and ticked debug executable off) ,however the pushes still only work when sent through the sandbox. Is there a way of installing/running the app using Xcode such that its compatible with the push production environment? Does the APS Environment entitlement come into play here? this only ever says development. (The app is on behalf of a 3rd party company, they've added me to their apple developer account but with limited powers, I can't upload to Testflight nor make an ad-hoc release with with to test with)

Hi, I'm working in unity and I've implemented Firebase Phone Number Authentication in it. Everything works fine when I directly install build from xCode. App Attest screen shows up, user receives OTP on their phone and login works. But when I download the same build from TestFlight, it gets stuck after the user sends OTP request. I've added Push Notifications and App Attest in capabilities. I've also additionally added Remote Notifications. In device log I see an error about mobile provisioning file but I've added that to my account also. Is this expected behavior that phone number authentication does not work on TestFlight? If yes, how can I get this approved from apple since they need to test it before approving it. Thanks!

I work at a well-established university with a business journal that is over 25 years old. We have been waiting now for almost four months to have our Apple News account reviewed. In what world is this OK? No ability to communicate with anyone or have any updates except to log in once a month to see the 'under review' message still there. Seriously?