We root-caused a launch crash that only affects ARCHIVED builds (Run/Debug works, simulator works) and filed it as FB23528109. Posting the details here because the crash signatures are hard to search for and other teams are likely to hit this as they adopt Swift 6.3 toolchains. SYMPTOM The archived app crashes before main() on device, on every launch. Depending on which orphaned pointer gets read first, the crash looks like one of these: EXC_BREAKPOINT, "pointer authentication trap DA", inside swift_conformsToProtocolMaybeInstantiateSuperclasses / _searchConformancesByMangledTypeName (often with a Firebase or other +load frame below it; that frame is just the first conformance scan at launch, not the cause) EXC_BAD_ACCESS KERN_INVALID_ADDRESS at a small, raw unslid address (e.g. 0xc118), inside dyld: resolveRebase <- objc_visitor::forEachClass <- dyld4::PrebuiltObjC::make Debug builds, simulator builds and Xcode Run builds are all fine, because the corruption happens in the Strip build phase, which only runs for Archive/install builds. ROOT CAUSE (two defects combine) strip -S -T (what Xcode runs on embedded frameworks during Archive when STRIP_SWIFT_SYMBOLS = YES) corrupts dyld chained fixups. When strip removes a Swift weak-definition symbol that has a GOT bind, it converts the bind into a rebase to the local definition (correct) but writes the converted entry with next = 0 (incorrect). That terminates the 16 KB page's fixup chain early, and every fixup after the converted slot in the same page is orphaned: dyld never processes it, so raw chain-encoding bytes get read as pointers at launch. The bug is present in every strip we tested: Xcode 26.3, 26.4, 26.4.1, 26.5, 26.6 and 27.0 beta 2. strip -S and strip -S -x (without -T) do not corrupt. Starting with Swift 6.3.0 (Xcode 26.4.0), the compiler emits the trigger pattern for ordinary code: cross-module references to a non-final class's stored-property accessors become weak-def-coalesce binds (Swift 6.2.4 emits none). So apps that embed a multi-module Swift dynamic framework (e.g. an SPM package built as one dynamic framework) started getting corrupted by their own default Archive pipeline when they moved past Xcode 26.3. HOW TO CHECK IF YOU ARE AFFECTED Compare the fixups of a framework binary inside your archive against a Run build of the same code: xcrun dyld_info -fixups YourApp.app/Frameworks/YourKit.framework/YourKit If fixups that exist in the Run build are missing after the archive's strip step (in particular __got slots and anything after them in the same 16 KB page), you are affected. Also: any GOT bind of a Swift ($s...) symbol in the pre-strip binary is a red flag. WORKAROUND Set STRIP_SWIFT_SYMBOLS = NO (optionally STRIP_STYLE = non-global, i.e. strip -S -x, which kept the size cost to about +4% for us). Important: if the affected framework is a Swift package product, these must be passed as xcodebuild command-line overrides (e.g. xcodebuild ... STRIP_SWIFT_SYMBOLS=NO STRIP_STYLE=non-global); xcconfig files do not apply to package targets. REPRO FB23528109 contains a complete minimal reproducer (4 small C files + 1 trivial Swift file, no proprietary code): a 30-second CLI script whose host binary segfaults through an orphaned pointer, and a default-settings Xcode project whose Run build works while its archived build crashes pre-main on device, identically for archives produced by Xcode 26.3.0, 26.4.0 and 26.6 (crash logs for each attached in the FB). Happy to share more details from the investigation if anyone is debugging the same signatures.

Working with Agents in Xcode 27 is a nightmare right now. Every conversation opens in a new window, so you don't see the code you and the agent are working on. You have to go back and forward between the code file and the conversation tab to get the names of data types or functions you need to ask the agent to work on, or to see exactly what you need to ask or how to explain it to the agent. We need the conversation and the code to be side by side to be able to work on the code and provide the right instructions, as we do in Xcode 26. The current interface just completely ruins any reasonable workflow, unless you are vibe coding, which I don't recommend. Let me know if there is a way to open the conversation on one side and code files on the other, or PLEASE change it back of what it was before or I will have to keep working on Xcode 26 and miss all the new features. Thanks

Hi guys In Xcode 27, we have to create the Assets Catalog file ourselves. This file is empty. The icon now is generated by Icon Composer, but how do you specify the accent color? I tried creating a Color set with the name AccentColor but didn't work. And look for options in the project settings but couldn't find any.

Hello Apple Developer Support and moderators, I'm concerned about my organization enrollment, which has been stuck in "Processing" since May 7, 2026 after I submitted the documents you requested. It's now nearly 8 weeks with no update. Enrollment ID: MYHC9JTJ47 I have stakeholders waiting on this and need to publish our app as soon as possible, and this delay is blocking that. I'd really appreciate a manual review by the Enrollment team, or at least an ETA. Happy to provide any additional verification needed. Thank you.

I’m running into an issue in App Store Connect where I’m being blocked from creating a new app version because it says I need to accept the latest Apple Developer Program License Agreement. However, I already accepted the agreement two days ago. When I go back to the agreements area, it appears that the agreement has been signed ("Issued June 18, 2026. Accepted June 24, 2026."), but the prompt still appears and continues preventing me from creating a new version. I’ve tried refreshing App Store Connect and checking again, but the issue is still happening. Has anyone else run into a delay where App Store Connect takes time to recognize the accepted agreement? Is there anything else I should check, or is this something that requires Apple Support to resolve? Thanks!

Apple I’ve had iOS 27 for ages and STILL DON’T HAVE THE NEW SIRI!!!

Hello everyone, I recently enrolled in the Apple Developer Program. At first, my credit card payment could not go through because my card was blocked by the bank/security check. After the card issue was resolved and the card was enabled again, one Apple Developer Program payment finally went through successfully. However, because I had clicked “Enroll” / “Complete purchase” a few times while the card was blocked, I now seem to have duplicate payment attempts. Currently, one Apple Developer Program payment is already successfully paid, but another Apple.com/US USD 99 payment is still showing as “Pending” on my bank card. My Apple Developer account is also still showing “Pending”. I only want to keep one active Apple Developer Program membership and one successful payment. I do not want to be charged twice. I have already contacted Apple Developer Support through the official contact page and I am waiting for their reply. Has anyone experienced this before? Will the pending payment disappear automatically? Could it become a duplicate charge? If it becomes a duplicate charge, will Apple cancel or refund it? Thank you.

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 (MH_EXECUTE), dynamic libraries (MH_DYLIB), bundles (MH_BUNDLE), and object files (MH_OBJECT). 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. There’s also a Mach-O man page, with basic information about the file format. Many of these tools have old and new variants, using the -classic suffix or llvm- prefix, respectively. For example, there’s nm-classic and llvm-nm. If you run the original name for the tool, you’ll get either the old or new variant depending on the version of the currently selected tools. To explicitly request the old or new variants, use xcrun. 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. Again, this isn’t a separate tool. Rather, ld supported the -ld_classic and -ld_new options to select a specific implementation. Note During the Xcode 15 beta cycle these options were named -ld64 and -ld_prime. I continue to use those original names because the definition of new changes over time (some of us still think of ld64 as the new linker ;–). Note Xcode 27 beta removed the ld64 implementation. The ld tool now contains just the ld_prime implementation. 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. Every dynamic library has an install name, which is how the dynamic linker identifies the library. Historically that was the path where you installed the library. That’s still true for most system libraries, but nowadays a third-party library should use an rpath-relative install name. For more about this, see Dynamic Library Identification. Mach-O images are position independent, that is, they can be loaded at any location within the process’s address space. Historically, Mach-O supported the concept of position-dependent images, ones that could only be loaded at a specific address. While it may still be possible to create such an image, it’s no longer a good life choice. Mach-O images have a default load address, also known as the base address. For modern position-independent images this is 0 for library images and 4 GiB for executables (leaving the bottom 32 bits of the process’s address space unmapped). When the dynamic linker loads an image, it chooses an address for the image and then rebases the image to that address. If you take that address and subtract the image’s load address, you get a value known as the slide. 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. Use the tapi tool to create and manipulate stub libraries. 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! Stub libraries currently use YAML format, a fact that’s relevant when you try to interpret linker errors. If you’re curious about the format, read the tapi-tbdv4 man page. There’s also a JSON variant documented in the tapi-tbdv5 man page. Note Back in the day stub libraries used to be Mach-O files with all the code removed (MH_DYLIB_STUB). This format has long been deprecated in favour of TBD. Historically, the system maintained a dynamic linker shared cache, built at runtime from its working set of dynamic libraries. In macOS 11 and later this cache is included in the OS itself. Libraries in the cache are no longer present in their original locations on disk: % ls -lh /usr/lib/libSystem.B.dylib ls: /usr/lib/libSystem.B.dylib: No such file or directory Apple APIs, most notably dlopen, understand this and do the right thing if you supply the path of a library that moved into the cache. That’s true for some, but not all, command-line tools, for example: % dyld_info -exports /usr/lib/libSystem.B.dylib /usr/lib/libSystem.B.dylib [arm64e]: -exports: offset symbol … 0x5B827FE8 _mach_init_routine % nm /usr/lib/libSystem.B.dylib …/nm: error: /usr/lib/libSystem.B.dylib: No such file or directory When the linker creates a Mach-O image, it adds a bunch of helpful information to that image, including: The target platform The deployment target, that is, the minimum supported version of that platform Information about the tools used to build the image, most notably, the SDK version A build UUID For more information about the build UUID, see TN3178 Checking for and resolving build UUID problems. To dump the other information, run vtool. In some cases the OS uses the SDK version of the main executable to determine whether to enable new behaviour or retain old behaviour for compatibility purposes. You might see this referred to as compiled against SDK X. I typically refer to this as a linked-on-or-later check. Apple tools support the concept of autolinking. When your code uses a symbol from a module, the compiler inserts a reference (using the LC_LINKER_OPTION load command) to that module into the resulting object file (.o). When you link with that object file, the linker adds the referenced module to the list of modules that it searches when resolving symbols. Autolinking is obviously helpful but it can also cause problems, especially with cross-platform code. For information on how to enable and disable it, see the Build settings reference. 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. For a bunch more info about symbols in Mach-O, see Understanding Mach-O Symbols. This includes a discussion of weak references and weak definition. If your code is referencing a symbol unexpectedly, see Determining Why a Symbol is Referenced. To remove symbols from a Mach-O file, run strip. To hide symbols, run nmedit. It’s common for linkers to divide an object file into sections. You might find data in the data section and code in the text section (text is an old Unix term for code). Mach-O uses segments and sections. For example, there is a text segment (__TEXT) and within that various sections for code (__TEXT > __text), constant C strings (__TEXT > __cstring), and so on. 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 2026-07-02 Added a note about fate of ld64. 2025-08-04 Added a link to Determining Why a Symbol is Referenced. 2025-06-29 Added information about autolinking. 2025-05-21 Added a note about the legacy Mach-O stub library format (MH_DYLIB_STUB). 2025-04-30 Added a specific reference to the man pages for the TBD format. 2025-03-01 Added a link to Understanding Mach-O Symbols. Added a link to TN3178 Checking for and resolving build UUID problems. Added a summary of the information available via vtool. Discussed linked-on-or-later checks. Explained how Mach-O uses segments and sections. Explained the old (-classic) and new (llvm-) tool variants. Referenced the Mach-O man page. Added basic info about the strip and nmedit tools. 2025-02-17 Expanded the discussion of dynamic library identification. 2024-10-07 Added some basic information about the dynamic linker shared cache. 2024-07-26 Clarified the description of the expected load address for Mach-O images. 2024-07-23 Added a discussion of position-independent images and the image slide. 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.

sent 6 emails no reply does the phone number work as been on fro 1 hour 20 mins just losting to music support is not great

Hello, I am looking for advice or assistance from Apple staff regarding a long running Apple Developer Program enrollment issue. My case ID is 102924690854. I have been trying to complete my Apple Developer Program enrollment for more than one month. When I sign in with my Apple Account, I only see "ID Verification Rejected" and I have no option to restart the verification or continue the enrollment. I also tried using another Apple Account, but enrollment is blocked because my company's DUNS number is already associated with my original Apple Account. I have opened multiple support cases. Each time I was told that my case had been transferred to the internal support team, but I never received a resolution. My latest case has also been with the internal team for over a week without any update. At this point I am completely blocked and unable to publish iOS applications for my company. If any Apple staff member can review or help escalate Case 102924690854, I would greatly appreciate it. Thank you.

I found that Xcode 26.1.1 (17B100) silently disables UICollectionView self-sizing configured in Interface Builder, depending on the minimum deployment target. I've fixed this issue in my project by explicitly setting the estimatedItemSize to UICollectionViewFlowLayout.automaticSize, but I was wondering whether this is intended behavior, or am I missing something? When a XIB contains a UICollectionViewFlowLayout with Estimate Size: Automatic (automaticEstimatedItemSize="YES" in the document source): <collectionViewFlowLayout key="collectionViewLayout" scrollDirection="horizontal" automaticEstimatedItemSize="YES" minimumLineSpacing="6" minimumInteritemSpacing="6"> <size key="itemSize" width="128" height="32"/> </collectionViewFlowLayout> ibtool drops the estimated-size key from the compiled nib if IPHONEOS_DEPLOYMENT_TARGET is 17.0 or later. It can be confirmed by compiling the same XIB at two deployment targets: $ ibtool --target-device iphone --minimum-deployment-target 16.0 --compile out16.nib View.xib $ strings out16.nib | grep -i estimat estimatedItemSize # present $ ibtool --target-device iphone --minimum-deployment-target 17.0 --compile out17.nib View.xib $ strings out17.nib | grep -i estimat # (nothing - key is gone) At runtime the flow layout decodes estimatedItemSize = .zero, so self-sizing is silently disabled and every cell is laid out at the placeholder Cell Size (128x32 above), regardless of its content: decoded estimatedItemSize = (0.0, 0.0), itemSize = (128.0, 32.0) // target 17.0 decoded estimatedItemSize = (1.79e+308, 1.79e+308) // target 16.0, works This is independent of the runtime OS version — I reproduced it on iOS 18.4 and iOS 26.1 simulators. The information is simply missing from the compiled nib, and no build warning or error is emitted. Confusingly, UIKit still calls the cell's preferredLayoutAttributesFitting(_:), so cells appear to compute correct sizes; they are just never adopted by the layout, which makes this quite hard to debug. Workaround — set it in code after the nib loads (the XIB cannot be fixed at the source level because the attribute is dropped at compile time): (collectionView.collectionViewLayout as? UICollectionViewFlowLayout)?.estimatedItemSize = UICollectionViewFlowLayout.automaticSize I attached minimal reproduction project (toggle IPHONEOS_DEPLOYMENT_TARGET between 16.0 and 17.0 to see both behaviors) to the feedback filed as FB23526517

My Apple Developer Program membership is paid and should still be active until March 10, 2027. This account had been working normally for several months, but recently I suddenly lost access to membership-related resources. Now when I sign in to developer.apple.com/account, it shows “Join the Apple Developer Program” instead of active membership details. When I try to create an Identifier in Certificates, Identifiers & Profiles, I get this error: “Team ID is not associated with an active membership.” I have already confirmed: I am signed in with the same Apple Account used to purchase the membership the receipt shows the membership is active this problem started only recently, after months of normal use Has anyone seen this before? Did Apple Developer Support need to manually restore the membership or team linkage?

I'm trying to build an Xcode Cloud workflow, but I keep getting this error. At first it just said I had to accept a license agreement, which I did, but it still didn't work after. I had recently added a new branch to the connected GitHub repository and committed to it so that I can have a beta branch separate from the main one. The only error that happens is when archiving. I am using Xcode 27 beta.

Hello, I have a problem. I submitted my ID card eight days ago, but I still haven't heard back from Apple, even though they were supposed to respond within two days of receiving it. I've written to them several times since then but haven't received a reply, so I'm reaching out to you. Could someone please let me know

Hi, I'm trying to figure out what is true here - if I am not in the correct forum please direct me :-) A. It is not possible to test a QR code scan that contains a deeplink into my iOS app from an XCoode build test run. In other words, The build must be published to Test Flight for the iOS's QR code scan sub-system to be able to process the deeplink into my app? If I am wrong about this, it sure would help with testing to be able to test directly from the local XCode build test. If so, can someone point me in the direction of what I would need to do for that? Thanks for your input either way!

Im unable to deploy Xcode 27 beta code to an iPhone 17 pro The build is successful but its not loading

Its been more than 48 hours i have enroll for the developer program but still the status is pending

Hello everyone, I’m running into an issue with my Apple Developer Program enrollment and hoping someone here or an Apple staff member can point me in the right direction. I tried to pay the annual fee, but my account status wasn't updating. Thinking the transaction had failed, I tried to make the payment a second time a few days later. Because of this, my credit card was actually charged twice. The charges appear on my bank statement as: February 19 (R$ 543.16 BRL) February 23 (R$ 536.70 BRL) Despite both payments clearing on my end, it is now March 16 and my account still shows as pending. My enrollment has not been approved yet. Has anyone else experienced this kind of delay? What is the best way to get Apple to activate the account using one of these payments and issue a refund for the duplicate charge? I have all the bank statements ready to show support, but the process has been completely stuck. Thank you in advance for any advice.

I distribute my AppleScript applet in a read only DMG file. I want to add a simple background image which encourages users to copy the applet to their Applications folder. I use the Finder function "Show View Options" which has the option to add a picture. That seems to work in macOS Tahoe. However, the background image is not visible on earlier versions of macOS. I've also found that a background image set on a Mac running Monterey is not visible on a Mac running Tahoe. Is there a way to add a background image which works across multiple macOS versions ?

Entity Type: Organization (NOT Individual). Apple ID Region: India. Payment Method tried: Visa. D-U-N-S Status: Verified and active. The Issue: I complete the enrollment, payment authorization is taken, but it never fully clears. iTunes support just tells me to wait 72 hours. I have done this 4 times. The money is authorized, drops off, and the account stays in "Pending" or "Action Required." What I've tried: Different cards, checked billing address with bank, updated Apple ID region. Question: Has anyone with an Organization account successfully gotten past a recurring payment authorization loop? How did you reach the backend Program Activation team without going through iTunes?