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. 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. 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 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.

I have an xCode project called Vision + CoreML I wanted add some charts into it so I started installing cocoapad for the first time I followed all the steps from installing the latest ruby version to running pod install The critical .xcworkspace had been never created no matter how many times pod install was run. It is nowhere to be found. Could anyone advise me on what went wrong here? Here are some files used to generate Podfile platform :ios, '15.0' target 'Vision + CoreML' do use_frameworks! # Comment the next line if you don't want to use dynamic frameworks pod 'Alamofire', '~> 5.6' # Pods for Vision + CoreML pod 'Charts' end and here is the command prompt output ls MacBook-Pro-3:NotAbgabe myusername$ ls App Main View Configuration Models Documentation Podfile Extensions README.md Image Predictor Vision+Core-ML.xcodeproj LICENSE I ran all the commands under the NotAbgabe folder. Not sure if xcworkspace is hidden somewhere between the files

Why as an IDE, many developers want to use the functions are not available, such as code formatting, if the function is not available, why not even a plug-in center, I have been using IDEA for code development, with Xcode development, feel very inconvenient to use

I am developing an Augmented Reality (AR) navigation application for the iPad, utilizing the ARCL library to place Points of Interest (POIs) in the real world. The application's behavior varies significantly based on the device's networking configuration: Cellular Network (Expected Behavior): On an iPad with a cellular modem, when using the cellular network, all POIs are placed accurately with correct orientation. Wi-Fi Only (Expected Behavior): On a Wi-Fi-only model (no GPS chip), POI placement is inaccurate, confirming the need for an external GPS receiver for that hardware configuration. Cellular + Wi-Fi (Anomalous Behavior): The iPad is a cellular model (equipped with GNSS/GPS). The device is connected to a Wi-Fi network (enforced via an MDM profile, preventing the user from disabling Wi-Fi). When actively connected to this specific Wi-Fi network, the AR POIs consistently display with an incorrect orientation and placement, even though the device hardware has a dedicated GPS chip. The placement error strongly suggests that the device's determined location or heading is erroneous. It appears that the active Wi-Fi connection is somehow interfering with or overriding the high-accuracy GNSS/GPS data, leading to a flawed Core Location determination that negatively impacts the ARCL world tracking and anchor placement. Has anyone experienced a scenario where an active Wi-Fi connection on a cellular iPad model causes Core Location to prioritize less accurate location data (potentially Wi-Fi-based location services) over the device's built-in GNSS/GPS, resulting in severe orientation errors? We observed that on Apple map(native application) as well it is showing wrong location and orientation when it is connected to WiFi

How can I allow the popup I am encountering while I run my UI tests with video recording in the Github actions. Since these tests are running on VMs, it's not possible to manually click Allow. Also the remote robot cannot interact with OS-level dialogs.

iphone 15 pro max ios 26 Stuck at the developer mode startup interface and unable to swipe up.

Hey, I am using the terminal a lot. Since I updated to Sonoma (so, really a long time ago). My prompt or more precise the hostname always changes between three states. Sometimes it is username@Macbook-Pro-of-XXX, sometimes username@MacbookPro and sometimes it's username@xxxxxxxx-yyyy-zzzz-aaaa-bbbbbbbbbbbb. The latter is probably my UUID. Does anyone have a clue why this randomly changes?

Not sure if this is common with releases but I've been doing some CI work recently so it's the first time I've seen this myself, When I list the runtimes installed on my machine: xcrun simctl list runtimes I notice the iOS 18.3.1 release has the below info: == Runtimes == iOS 18.3 (18.3.1 - 22D8075) - com.apple.CoreSimulator.SimRuntime.iOS-18-3 Meanwhile the other runtimes are listed as: == Runtimes == iOS 17.5 (17.5 - 21F79) - com.apple.CoreSimulator.SimRuntime.iOS-17-5 iOS 18.4 (18.4 - 22E5216h) - com.apple.CoreSimulator.SimRuntime.iOS-18-4 watchOS 11.2 (11.2 - 22S99) - com.apple.CoreSimulator.SimRuntime.watchOS-11-2 visionOS 2.3 (2.3 - 22N895) - com.apple.CoreSimulator.SimRuntime.xrOS-2-3 (Apologies for the weird formatting above, using code blocks and quote markdown condenses things down to one line for some reason) This is causing some funkiness in my CI code which I've managed to workaround, but wondered if this was a common thing, specifically the mismatch between the iOS name and the runtime version. iOS 18.3 and com.apple.CoreSimulator.SimRuntime.iOS-18-3 vs 18.3.1 - 22D8075 where the .1 has been dropped for the runtime names?

Hello all, I am trying to build a Flutter app that supports a link the opens the app. I would like the link to be sent by email, and when clicked I would like to app to open. On android all works fine, but on IOS it doesnt. I currently have: A link that does open the app but doesnt navigate to the correct screnn - it just shows the last screen that app was on. I have tried following the tutorial on https://docs.flutter.dev/cookbook/navigation/set-up-universal-links to the letter but still doesnt work I am using: Flutter 3.22.3 Go Router 14.2.7 Thanks in advance

I'm integrating Apollo GraphQL into a SwiftUI app and encountering the following error during a query execution: result : failure(Apollo.MultipartResponseParsingInterceptor.ParsingError.cannotParseResponse) failed : The response data could not be parsed. The request hits the server, but the response fails to be parsed by Apollo. I'm using the default code generation setup and executing a simple query to fetch a list of countries. Here’s a snippet of the function: swift Copy Edit private func fetchCountries() { switch result { case .success(let graphQLResult): if let name = graphQLResult.data?.countries { print(name) } else if let errors = graphQLResult.errors { print(errors) } case .failure(let error): print("failed : (error.localizedDescription)") } } This is run on an iPhone 16 Pro simulator with iOS 18.2. Any idea what's causing the parsing error or how I can inspect the raw response for debugging? Thanks in advance!

Hello, I'm encountering an issue when trying to build and launch a Flutter app on a physical iOS device using Android Studio. Here is the full log: `Launching lib/main.dart on （iPhone Name） in debug mode... Automatically signing iOS for device deployment using specified development team in Xcode project: （Project ID） Running Xcode build... Xcode build done. 19.7s Failed to build iOS app Could not build the precompiled application for the device. Error (Xcode): Target debug_unpack_ios failed: Exception: Failed to codesign （Project Names）/build/ios/Debug-iphoneos/Flutter.framework/Flutter with identity （identity ID）. Error launching application on （iPhone Name）.` This only happens when using Android Studio. When I build the same project using Xcode, it runs fine on the same device. Background: I accidentally deleted all Apple accounts from Xcode recently. In Keychain Access, I had three identical certificates; I deleted the older two and kept the newest one. I suspect this may be related to provisioning or code signing, but I’m not sure how to resolve it within Android Studio. Any advice or steps to fix this would be greatly appreciated. I created a new test project in Xcode using the iOS > App template, enabled automatic signing in Signing & Capabilities, and selected my team.
 I then tried building and installing the app on a real device, and it worked successfully.
 This confirms that there are no issues with code signing or provisioning on the Apple side.
 Thanks in advance!

My Apple developer certificates(4 certificates) expire soon. I'm developing an application for iOS but the application is not yet released in the App Store, only Testflight releases for private testing. Is it necessary to create 4 new certificates or can I edit the current certificates so that they don't expire soon?

I have been trying to subscribe a few times from Japan, being a foreigner and i amunable to get validated despite my residence card. it feels a bit difficult to navigate this walkthrough.

If an iOS app gets terminated by watchdog due to, for example, hanging the main thread, is that considered to be a crash or something different. I'm asking because, according to google and AI, Crashlytics can detect and report these,but in my experience it does not. If I deliberately cause a watchdog termination by for example sleeping on the main thread for a long time then these never appear in Crashlytics. I know Apple folks here don't comment on non Apple software, so I'm not asking about Crashlytics, just wondering and interested about watchdog timeout terminations and how they differ from a "regular" crash.

Hi! I'm new at developing apps. I built my app with Expo and it's working fine in simulator and my iPhone 14 as well. But when I try to run the build in my iPhone with TestFlight it crashes instantly :/ This is part of the log: Incident Identifier: B0ED8DEF-A0F0-4D0C-B3BB-3BB9CAB3242A Distributor ID: com.apple.TestFlight Hardware Model: iPhone14,7 Process: colbakapp [83024] Path: /private/var/containers/Bundle/Application/44211687-140E-4DF3-A577-CB68CE6414B0/colbakapp.app/colbakapp Identifier: com.colbak.colbakapp Version: 1.0.0 (3) AppStoreTools: 16F3 AppVariant: 1:iPhone14,7:18 Beta: YES Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.colbak.colbakapp [18141] Date/Time: 2025-06-22 13:26:29.0142 -0400 Launch Time: 2025-06-22 13:26:28.6532 -0400 OS Version: iPhone OS 18.5 (22F76) Release Type: User Baseband Version: 3.60.02 Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: colbakapp [83024] Triggered by Thread: 2 Thread 0: 0 libsystem_kernel.dylib 0x00000001f2e4fce4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x00000001f2e5339c mach_msg2_internal + 76 (mach_msg.c:201) 2 libsystem_kernel.dylib 0x00000001f2e532b8 mach_msg_overwrite + 428 (mach_msg.c:0) 3 libsystem_kernel.dylib 0x00000001f2e53100 mach_msg + 24 (mach_msg.c:323) 4 CoreFoundation 0x00000001a1c42900 __CFRunLoopServiceMachPort + 160 (CFRunLoop.c:2637) 5 CoreFoundation 0x00000001a1c411f0 __CFRunLoopRun + 1208 (CFRunLoop.c:3021) 6 CoreFoundation 0x00000001a1c42c3c CFRunLoopRunSpecific + 572 (CFRunLoop.c:3434) 7 GraphicsServices 0x00000001eee21454 GSEventRunModal + 168 (GSEvent.c:2196) 8 UIKitCore 0x00000001a4655274 -[UIApplication _run] + 816 (UIApplication.m:3845) 9 UIKitCore 0x00000001a4620a28 UIApplicationMain + 336 (UIApplication.m:5540) 10 colbakapp 0x00000001046296b0 main + 64 (AppDelegate.swift:6) 11 dyld 0x00000001c8b17f08 start + 6040 (dyldMain.cpp:1450) Thread 1: 0 libsystem_pthread.dylib 0x000000022c350aa4 start_wqthread + 0 Thread 2 Crashed: 0 libsystem_kernel.dylib 0x00000001f2e5a1dc __pthread_kill + 8 1 libsystem_pthread.dylib 0x000000022c357c60 pthread_kill + 268 (pthread.c:1721) 2 libsystem_c.dylib 0x00000001a9c782d0 abort + 124 (abort.c:122) 3 libc++abi.dylib 0x000000022c2815a0 abort_message + 132 (abort_message.cpp:78) 4 libc++abi.dylib 0x000000022c26fef4 demangling_terminate_handler() + 316 (cxa_default_handlers.cpp:72) 5 libobjc.A.dylib 0x000000019f1e7c08 _objc_terminate() + 172 (objc-exception.mm:499) 6 libc++abi.dylib 0x000000022c2808b4 std::__terminate(void ()()) + 16 (cxa_handlers.cpp:59) 7 libc++abi.dylib 0x000000022c2840d0 __cxa_rethrow + 188 (cxa_exception.cpp:658) 8 libobjc.A.dylib 0x000000019f1e5568 objc_exception_rethrow + 44 (objc-exception.mm:399) 9 colbakapp 0x00000001049f7b68 invocation function for block in facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const, NSInvocation*, NSMutableArray*) + 200 (RCTTurboModule.mm:444) 10 colbakapp 0x00000001049fc538 facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMutableArray*)::$_1::operator()() const + 36 (RCTTurboModule.mm:463) 11 colbakapp 0x00000001049fc538 decltype(std::declval<facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMutableArray*)::$_1&>()()) std::__1::__invoke[abi:ne190102... + 36 (invoke.h:149) 12 colbakapp 0x00000001049fc538 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ne190102]<facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMu... + 36 (invoke.h:224) 13 colbakapp 0x00000001049fc538 std::__1::__function::__alloc_func<facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMutableArray*)::$_1, std::__1::allocator<face... + 36 (function.h:171) 14 colbakapp 0x00000001049fc538 std::__1::__function::__func<facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMutableArray*)::$_1, std::__1::allocator<facebook::... + 104 (function.h:313) 15 libdispatch.dylib 0x00000001a9bbcaac _dispatch_call_block_and_release + 32 (init.c:1575) 16 libdispatch.dylib 0x00000001a9bd6584 _dispatch_client_callout + 16 (client_callout.mm:85) 17 libdispatch.dylib 0x00000001a9bc52d0 _dispatch_lane_serial_drain + 740 (queue.c:3939) 18 libdispatch.dylib 0x00000001a9bc5dac _dispatch_lane_invoke + 388 (queue.c:4030) 19 libdispatch.dylib 0x00000001a9bd01dc _dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7198) 20 libdispatch.dylib 0x00000001a9bcfa60 _dispatch_workloop_worker_thread + 540 (queue.c:6792) 21 libsystem_pthread.dylib 0x000000022c350a0c _pthread_wqthread + 292 (pthread.c:2696) 22 libsystem_pthread.dylib 0x000000022c350aac start_wqthread + 8 Thread 3: 0 libsystem_pthread.dylib 0x000000022c350aa4 start_wqthread + 0 ... EOF

Hi, Apple changed the renewal rate for auto renewable subscriptions in testflight to 24hrs and after 6 renewals it is supposed to expire. My subscription is now active for more than 13 days, it didnt expire as its supposed to. I heard that there is no chance to cancel it manually. Is there anyone else who had this problem and found a solution? I use RevenueCat to manage subscriptions. Maybe its because they have not adapted to apples update yet. Are there any other RevenueCat users that can confirm this experience? Or non RC users who don't have the issue I'm facing? Any responds are welcome.

We recently integrated MetricKit into our app; however, the 90th percentile data does not seem to match the data in Xcode Organizer. The values reported by MetricKit appear to be higher. Additionally, it looks like data for previous app versions is not being updated in Organizer as adoption of the latest version increases. Has anyone else experienced this issue? Could there be a delay in data updates for older versions in Organizer? Are there any known limitations or best practices for ensuring consistency between MetricKit and Xcode Organizer data? Any guidance would be greatly appreciated.

I admit I am doing something unusual, and I would not be surprised if it didn't work. I am surprised, however, because after performing the equivalent operations on four bundles, all of the bundles work fine on macOS 15.6.1, but only two of them work on macOS 26.1 (beta 2). I don't know what causes the different outcomes. What I am trying to do is get Java to pass the macOS 26 AppKit UI SDK linkage checking without having to rebuild the JDK using Xcode 26. Rebuilding works for the latest SDK, but it is very inconvenient and may not work for older JDKs. It usually takes a while before the JDK build team successfully transitions to a new Xcode release. My approach is to use vtool to update the sdk version in the LC_BUILD_VERSION load command of $JAVA_HOME/bin/java, which is the launching executable for the JDK. I performed this operation on four JDKs: 25, 21, 17, and 11. (I ran vtool on macOS 15.) It was completely successful on JDK 25 and 21. The JDK launches correctly on macOS 15 and macOS 26. On macOS 26, AppKit uses the new UI, which is the desired outcome. The JDK runs despite that fact that I signed the modified $JAVA_HOME/bin/java with my developer ID, which is inconsistent with the JDK bundle signature. (Redoing the bundle signing is part of the JDK build process; if that were necessary, I would stick with rebuilding the JDK.) The operation was not successful on JDK 17 and 11. I noticed two problems, which are not obviously related. When vtool created the new version of the java program, it lost the tool definition. $ vtool -show-build-version java java: Load command 10 cmd LC_BUILD_VERSION cmdsize 32 platform MACOS minos 11.0 sdk 11.1 ntools 1 tool LD version 609.8 $ vtool -set-build-version 1 10.0 26.0 -output a.out java /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/vtool warning: code signature will be invalid for a.out $ vtool -show-build-version a.out a.out: Load command 22 cmd LC_BUILD_VERSION cmdsize 24 platform MACOS minos 10.0 sdk 26.0 ntools 0 Adding back the tool definition didn't seem to matter. When I try to run the revised executable (in the context of the JDK bundle), it works on macOS 15, but on macOS 26, it is rejected as damaged. If I run the revised executable outside the JDK bundle, it runs (but fails because it can't find the rest of the JDK, which is expected). In all cases, GateKeeper rejects the revised executable because it has not been notarized, but that doesn't seem to stop the program from executing.

Hello, Thank you for taking the time to read this and hopefully helping me. https://apps.apple.com/gb/app/gdl-graded-darts-leagues/id1592502150 I created a mobile app using AppPresser that is connected to my WordPress website. The iOS app is logging users out when they close the app and go back to it. The login session does not persist, and users are forced to log in again frequently. This happens at any time period between closing and opening the app. This only happens on iOS — Android keeps the session active as expected. I don't know if I've included this post in the correct topic, sorry. Thanks again for any ideas and assistance!

We have a .ipa file that we need to side load on iPhone via USB connected to a MAC. IPA file will be on MAC. We can't use enterprise license. We have a business use case where we need to side load the app. Any way to do that or can be reach apple support for this? Please help. Note: The iPhones attached will not have the Apple ID logged in. There are companies who are side loading the app for business purpose on the customers phone.