Check the status here https://developer.apple.com/system-status/ This prevents use of App Store Connect, XCode accounts, TestFlight, app submissions etc. no need to post about every individual problem ;)

Install CommandLineTools below macOS Sequoia installs the VULNERABLE version of Git, 2.39.3 while macOS Sequoia installs a non-vulnerable version 2.39.5. How to get the non vulnerable version installed on macOS Sonoma? CVE-2024-32002 - Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule's worktree but into a .git/ directory.

I'm a big fan of MetricKit. I decided to see how my apps are performing with iOS 18 and well, I'm not getting any metric payloads from those devices. Metric payloads received from my test devices adopting iOS 18 has pretty much bottomed out to zero. Is anyone getting MetricKit MXMetricPayloads from iOS 18 devices? FB15461298 - MetricKit: Production issue / regression with iOS 18 - Significant dropout or metric payloads being generated since 18.0 - nearly no reports To demonstrate the issue, I decided to graph the metric payloads my infrastructure receives for all of my apps across all of my devices over the last 16 months starting with WWDC23 timeframe. This data is grouped by count per month. A trend can easily be seen starting in June 2024 where I started to adopt iOS 18 betas. Zooming in since WWDC24, grouped by week, it is much easier to see the decline. Note, the second screenshot shows data collected from Xcode builds, TestFlight, and App Store. The last data point from today was a manual creation from Xcode's Debug window, so at least that triggering mechanism works and I can confirm all of my code to upload off device works as expected. On the bright side, I guess I will ship this 'payload received over time' feature in my MetricKit payload analyzer app with a scrolling window and group by features that make up these screenshots.

在idea中Java spring 框架如何运行啊，求求大佬们，我跑https://gitee.com/lab1024/smart-admin 这个包老是报错，不让我写入

https://developer.apple.com/documentation/metrickit I am unable to get the MetricKit logs for past 24 hours time period on my test flight build. I have been able to achieve immediate logs for crash, cpu exception and diskwrite exceptions. But the logs which contains all the crashes, cpu exceptions and diskwrite exceptions, battery and network details, etc for the previous day/24h are never generated. I have used the following method to log the payloads in the file systems. I have tested the same on normal xcode builds as well as TestFlight build. func didReceive(_ payloads: [MXDiagnosticPayload]) https://developer.apple.com/documentation/metrickit/mxmetricmanagersubscriber/didreceive(_:)-9yd4u

I have been waiting for a response for approval of the ESIm rights permit for over 6 months and I have not had any response. I contacted support and they hang up on me. I don't know what to do anymore. Does anyone know how I can obtain the status of my application?

hello, i wrote a method with Neon for accelerate my code.. I don't have the expected result only simples instructions and, or, shift... on 64bits no gain speed. nada :-( i dont understand... how programm this method for speed? original code : unsigned long long RXBitBoard::get_legal_moves(const unsigned long long p_discs, const unsigned long long o_discs) { const unsigned long long inner_o_discs = o_discs & 0x7E7E7E7E7E7E7E7EULL; /* direction W */ unsigned long long flipped = (p_discs >> 1) & inner_o_discs; flipped |= (flipped >> 1) & inner_o_discs; unsigned long long adjacent_o_discs = inner_o_discs & (inner_o_discs >> 1); flipped |= (flipped >> 2) & adjacent_o_discs; flipped |= (flipped >> 2) & adjacent_o_discs; unsigned long long legals = flipped >> 1; // /* direction _E*/ // flipped = (p_discs << 1) & inner_o_discs; // flipped |= (flipped << 1) & inner_o_discs; // // adjacent_o_discs = inner_o_discs & (inner_o_discs << 1); // // flipped |= (flipped << 2) & adjacent_o_discs; // flipped |= (flipped << 2) & adjacent_o_discs; // // legals |= flipped << 1; // trick /* direction _E */ flipped = (p_discs << 1); legals |= ((flipped + inner_o_discs) & ~flipped); /* direction S */ flipped = (p_discs >> 8) & o_discs; flipped |= (flipped >> 8) & o_discs; adjacent_o_discs = o_discs & (o_discs >> 8); flipped |= (flipped >> 16) & adjacent_o_discs; flipped |= (flipped >> 16) & adjacent_o_discs; legals |= flipped >> 8; /* direction N */ flipped = (p_discs << 8) & o_discs; flipped |= (flipped << 8) & o_discs; adjacent_o_discs = o_discs & (o_discs << 8); flipped |= (flipped << 16) & adjacent_o_discs; flipped |= (flipped << 16) & adjacent_o_discs; legals |= flipped << 8; /* direction NE */ flipped = (p_discs >> 7) & inner_o_discs; flipped |= (flipped >> 7) & inner_o_discs; adjacent_o_discs = inner_o_discs & (inner_o_discs >> 7); flipped |= (flipped >> 14) & adjacent_o_discs; flipped |= (flipped >> 14) & adjacent_o_discs; legals |= flipped >> 7; /* direction SW */ flipped = (p_discs << 7) & inner_o_discs; flipped |= (flipped << 7) & inner_o_discs; adjacent_o_discs = inner_o_discs & (inner_o_discs << 7); flipped |= (flipped << 14) & adjacent_o_discs; flipped |= (flipped << 14) & adjacent_o_discs; legals |= flipped << 7; /* direction NW */ flipped = (p_discs >> 9) & inner_o_discs; flipped |= (flipped >> 9) & inner_o_discs; adjacent_o_discs = inner_o_discs & (inner_o_discs >> 9); flipped |= (flipped >> 18) & adjacent_o_discs; flipped |= (flipped >> 18) & adjacent_o_discs; legals |= flipped >> 9; /* direction SE */ flipped = (p_discs << 9) & inner_o_discs; flipped |= (flipped << 9) & inner_o_discs; adjacent_o_discs = inner_o_discs & (inner_o_discs << 9); flipped |= (flipped << 18) & adjacent_o_discs; flipped |= (flipped << 18) & adjacent_o_discs; legals |= flipped << 9; //Removes existing discs legals &= ~(p_discs | o_discs); return legals; } my neon code const uint64x2_t pp_discs = vdupq_n_u64(p_discs); const uint64x2_t oo_discs = vdupq_n_u64(o_discs); const uint64x2_t inner_oo_discs = vdupq_n_u64(o_discs & 0x7E7E7E7E7E7E7E7EULL); //horizontals directions -1, +1 static const int64x2_t shift_1 = {-1, 1}; static const int64x2_t shift_2 = {-2, 2}; uint64x2_t flipped = vandq_u64(vshlq_u64(pp_discs, shift_1), inner_oo_discs); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_1), inner_oo_discs)); uint64x2_t adjacent_oo_discs = vandq_u64(inner_oo_discs, vshlq_u64(inner_oo_discs, shift_1)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_2), adjacent_oo_discs)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_2), adjacent_oo_discs)); uint64x2_t legals = vshlq_u64(flipped, shift_1); //verticals directions -8 , +8 static const int64x2_t shift_8 = {-8, 8}; static const int64x2_t shift_16 = {-16, 16}; flipped = vandq_u64(vshlq_u64(pp_discs, shift_8), oo_discs); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_8), oo_discs)); adjacent_oo_discs = vandq_u64(oo_discs, vshlq_u64(oo_discs, shift_8)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_16), adjacent_oo_discs)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_16), adjacent_oo_discs)); legals = vorrq_u64(legals, vshlq_u64(flipped, shift_8)); //diagonals directions -7 , +7 static const int64x2_t shift_7 = {-7, 7}; static const int64x2_t shift_14 = {-14, 14}; flipped = vandq_u64(vshlq_u64(pp_discs, shift_7), inner_oo_discs); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_7), inner_oo_discs)); adjacent_oo_discs = vandq_u64(inner_oo_discs, vshlq_u64(inner_oo_discs, shift_7)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_14), adjacent_oo_discs)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_14), adjacent_oo_discs)); legals = vorrq_u64(legals, vshlq_u64(flipped, shift_7)); //diagonals directions -9 , +9 static const int64x2_t shift_9 = {-9, 9}; static const int64x2_t shift_18 = {-18, 18}; flipped = vandq_u64(vshlq_u64(pp_discs, shift_9), inner_oo_discs); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_9), inner_oo_discs)); adjacent_oo_discs = vandq_u64(inner_oo_discs, vshlq_u64(inner_oo_discs, shift_9)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_18), adjacent_oo_discs)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_18), adjacent_oo_discs)); legals = vorrq_u64(legals, vshlq_u64(flipped, shift_9)); return ((vgetq_lane_u64(legals, 0) | vgetq_lane_u64(legals, 1)) & ~(p_discs | o_discs)); } i even wrote a interleave version I can expect a speed gain, no?

I have a .NET iOS App(previously Xamarin.iOS) and we recently updated the info.plist minimumosversion from 13.0 to 15.0. The problem is it is not allowing the app to run on devices with iOS 15. Need advice on how we can restrict versions under iOS 15 but still get the iOS 15 devices to run the App

I have a .NET8 iOS app that works fine in local testing but is consistently crashing in app review. I have the original dsym and the crash log, but symbolicating the log only partially reveals the details. I've tried using atos to look up individual hex addresses, but this is still as good as I can get. It is much too vague for me to pinpoint the problem, so I'm stuck. Any suggestions on how to resolve this? Thread 0 Crashed: 0 libsystem_kernel.dylib 0x1df4e51d4 __pthread_kill + 8 1 libsystem_pthread.dylib 0x21729eef8 pthread_kill + 268 2 libsystem_c.dylib 0x196bbead8 abort + 128 3 FolioPlayer 0x107e6347c 0x102618000 + 92583036 4 FolioPlayer 0x107e066dc mono_runtime_setup_stat_profiler + 92202716 (mini-posix.c:662) 5 libsystem_platform.dylib 0x2171e9afc _sigtramp + 56 6 libsystem_pthread.dylib 0x21729eef8 pthread_kill + 268 7 libsystem_c.dylib 0x196bbead8 abort + 128 8 FolioPlayer 0x107b919a4 xamarin_find_protocol_wrapper_type + 89627044 (runtime.m:1218) 9 FolioPlayer 0x107d4244c mono_invoke_unhandled_exception_hook + 91399244 (exception.c:1263) 10 FolioPlayer 0x107ddce78 mono_jit_exec + 92032632 (driver.c:1314) 11 FolioPlayer 0x107b99eb0 xamarin_main + 89661104 (monotouch-main.m:0) 12 FolioPlayer 0x107e456a8 main + 92460712 (main.arm64.mm:298) 13 dyld 0x1b4b3dec8 start + 2724

I am trying to fix a bug in my iOS app that is dependent upon date and time. Is there any way to set the actual time on the iOS Simulator to a specific date and time? I know that you can set one for the status bar, but that doesn't affect the actual date and time that is reported by the system to apps.

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

I tried to create dmg from folder using hdiutil and diskutility , both time it failed creation for a particular folder name, when i change folder name it worked. The error i get is could not access /Volumes/abc/abc.app - Operation not permitted hdiutil: create failed - Operation not permitted When i change abc to def it works.

The operation couldn’t be completed. (ModelCatalog.CatalogErrors.AssetErrors error 1.) Domain: ModelCatalog.CatalogErrors.AssetErrors Code: 1 User Info: { DVTErrorCreationDateKey = "2024-10-06 09:19:05 +0000"; } Failed to find asset: com.apple.gm.safety_deny.output.code_intelligence.base - no asset Domain: ModelCatalog.CatalogErrors.AssetErrors Code: 1 System Information macOS Version 15.0.1 (Build 24A348) Xcode 16.0 (23051) (Build 16A242d) Timestamp: 2024-10-06T11:19:05+02:00

Hi, I developed an app. It is using Firebase Cloud Messaging to send notifications. I got my 5th rejection from Apple. I tried to distribute the app from Xcode with new Provisining Profile and Certificates but it go rejected. I used EAS to distribute it automatically but 5 minutes ago it is again rejected. I tried on iPhone and iPad simulators, it is working perfectly fine. Even sending notifications are working perfect. Please can you help me? My crash reports are : crash1 crash2 crash3

Hi, I'm producing a dylib that another developer is trying to link with an ffmpeg plugin, building on Sequoia (this was not an issue prior to upgrading the OS). The error is: ld: Shared cache eligible dylib cannot link to ineligible dylib '@rpath/libme.dylib'. Remove link to ineligible dylib, fix its eligibility, or opt out of the shared cache using the build setting 'LD_SHARED_CACHE_ELIGIBLE=NO' (or linker flag '-not_for_dyld_shared_cache') clang: error: linker command failed with exit code 1 (use -v to see invocation) So, simple question - how do I "fix my dylib's eligibility"? I can't seem to find much info about this online. Thanks, Jeff

Hi, I am encountering a linking issue with a project for an iOS .NET MAUI application that I am developing using Visual Studio 17.11.4. This project includes a custom static library (.a). The custom static library (.a) depends on the libxml2 library. However, it appears that libxml2 is not included in Xcode 15.4 (Sonoma OS), resulting in the following error: error : Undefined symbols for architecture arm64: error : "_xmlBufferCreate", referenced from: .... I have set the following additional arguments for compilation: -cxx -gcc_flags "-lz -lxml2". Despite my efforts to install libxml2 using Homebrew, I have not been successful. Could you please advise on how I can resolve this issue? Specifically, what is the path that Xcode uses to include libxml2?

I am developing an app using Flutter. When I build, I encounter the following error: Parse Issue (Xcode): Module 'app_tracking_transparency' not found /.../ios/Runner/GeneratedPluginRegistrant.m:11:8 I have cleared the cache and reinstalled everything, but the error persists. Please let me know the cause and possible solutions. occured error source // // Generated file. Do not edit. // // clang-format off #import "GeneratedPluginRegistrant.h" #if__has_include(<app_tracking_transparency/AppTrackingTransparencyPlugin.h>) #import <app_tracking_transparency/AppTrackingTransparencyPlugin.h> #else @import app_tracking_transparency; #endif

Hello, I am currently learning SwiftUI through a paid course and am working on integrating Firebase into my project. While trying to add the Firebase package through Xcode, everything seems to work fine except for the fact that I am unable to find the FirebaseFirestoreSwift package. I am using the latest versions of both Xcode and macOS. I have attached a screenshot from the package manager where I couldn't locate the FirebaseFirestoreSwift package. Could you kindly assist me in resolving this issue? How can I correctly add this specific package to my project? Thank you for your support.

We recently upgrade our OS from Sonoma to Sequoia and have been using Fastlane to generate our ipa(s) However since the upgrade we are facing the following error: 00:26:30 + xcodebuild -exportArchive -exportOptionsPlist /var/folders/sk/_k2v73dd5hscn2mcvcqc43gs69_8bc/T/gym_config20240930-10121-gjvg0h.plist -archivePath /Users/ejeniossvc/jenkins/workers/workspace/local-jenkins-build32/-1449677665/452/build-dir/rqa-EnterpriseDistribution/dist/MY.xcarchive -exportPath /var/folders/sk/_k2v73dd5hscn2mcvcqc43gs69_8bc/T/gym_output20240930-10121-27pj6 -allowProvisioningUpdates -skipPackagePluginValidation -skipMacroValidation CODE_SIGN_STYLE=Manual DEVELOPMENT_TEAM=xxxxxxxxxxxx 00:26:30 error: Couldn't load -exportOptionsPlist: The data couldn’t be read because it isn’t in the correct format. 00:26:30 00:26:30 Swift.DecodingError.dataCorrupted(Swift.DecodingError.Context(codingPath: [], debugDescription: "The given data was not a valid property list.", underlyingError: Optional(Error Domain=NSCocoaErrorDomain Code=3840 "Encountered unexpected character s on line 1 while looking for close tag for key" UserInfo={NSDebugDescription=Encountered unexpected character s on line 1 while looking for close tag for key})))

About technotes Technotes are focused, timely documents from Apple Developer Technical Support. They explore a wide range of development topics and provide guidance for developers creating apps and accessories for all of Apple’s platforms. Learn about specific development topics through these in-depth technical articles. You can subscribe to this RSS feed to get notified when new technotes are published. We encourage you to discuss the technotes here in the forums and share your feedback via Feedback Assistant. Let us know if a technote is helpful, or what we can do to improve it. We would appreciate it if you include a Feedback Assistant (FB) number in your forums post, so we can easily track your feedback, and let you know when it’s resolved. Tagging your post When tagging your post, please add the relevant tags for the technology area it applies to. You can also add the Technotes tag, if you wish. Providing feedback To create new feedback about a specific technote (or technotes as a whole) using Feedback Assistant, use the following path: What are you seeing an issue with? Developer Tools Which area are you seeing an issue with? Developer Documentation What does the documentation issue you are reporting involve? Technotes Please provide the URL of the content you reporting an issue with: The complete URL of the technote. For example, https://developer.apple.com/documentation/technotes/tn3102-http3-in-your-app. If you wish to leave feedback on Technotes in general, use https://developer.apple.com/documentation/technotes for the URL. Then complete the remaining fields appropriately. We appreciate and look forward to your feedback.