Hi team, we have a large-scale application in use that sends bulk emails to thousands of users. We adhere to all standard guidelines and protocols, and our email addresses are whitelisted to ensure they are not considered spam. Our users create email alerts on our platform and receive notifications on their respective email addresses. These communications are not unknown, spam, or unsolicited marketing. To maintain trust with our users, we provide an unsubscribe feature as per RFC2369-compliant. We have added list unsubscribe headers with mailTo implementation and sent it to outlook/gmail accounts. However, when unsubscribed, the email seems to be having the encoded characters as is. Whereas the same is working fine in other email clients without any encodings. The headers were implemented according to the List-Unsubscribe headers as specified in the IETF RFC and our emails are purely transactional in nature. This is a critical issue for a large organization like ours and while it works properly on Gmail web and mobile, it is essential for us to check with Apple Mail client as well. This situation undermines our commitment to user trust and compliance. Can anybody assist me why the encoding is showing up? Would like to know whats the process involved to enable the unsubscribe button in Apple mail client application?

How to replicate: Design a icon in icon composer Save it and put the .icon file in your project, then in your targets put the name of the .icon file in there. Either clean build folder or restart IDE One Error: unable to open dependencies file (/Users/user/Library/Developer/Xcode/DerivedData/project-fqrfzzkwgrutdabmcqjeupvyetci/Build/Intermediates.noindex/project.build/Debug/project.build/assetcatalog_dependencies_thinned) And one warning: Icon export exited with status 255, signal 0 Is this a known issue or a easy fix? Or is it a issue on my end? Thanks

Good day, everyone. I've already spent two days trying to figure out if this is even possible: I have a working project with a huge number of SPM dependencies. We need to wrap all of this into a framework that can be easily connected to another project. Currently, following the instructions on Apple's documentation, I've done everything step by step. However, after connecting the library to a new project and writing import Framework, I get the error: Missing required modules: [list of all SPM from Framework] I thought that a static framework implied that all dependencies would be bundled into the project, but that didn't happen. Are there any ways to solve this problem? Thank you!

I have an MAUI based application build and ready for the distribution. The application is working perfectly in the debug environment on the simulator. So the app logic is working correctly as expected without any errors. But when a release build is created the application crashes on the simulator and physical device. I'm developing the application using .Net 10 framework with target device iOS 26. The Supported OS Platform is set to 15.0 in csproj file. Also have the entitlements. plist file set in the csproj. The IDe used is Visual Studio Code for Mac (MAC OS). The application uses MSAL for the login / authentication purpose (Microsoft.Identity.Client) and SQLite Database (Sqlite-net-pcl) Message: Kindly guide me to build the application correctly in release version and get the ipa file ready for the in house distribution that could be deployed correctly on the physical device with iOS 18 / 26.

Hi all, I'm trying to integrate Apple’s DeviceCheck API into my Flutter iOS app. I already have everything set up on the backend — the Apple private key, key ID, team ID, and DeviceCheck capability. The backend is generating and signing the JWT correctly and making requests to Apple. However, I’m currently stuck on the frontend (Flutter): 👉 How can I generate the device_token required by the DeviceCheck API (via DCDevice.generateToken) in a Flutter iOS app? I understand that DCDevice.generateToken() must be called from native Swift code. I previously attempted to use a MethodChannel to bridge this in Swift, but would prefer not to write or maintain native Swift code if possible. I've looked for a prebuilt Flutter package to handle this, but nothing exists or is up-to-date on pub.dev. Main Question: Is there any Apple-supported way to generate the device_token for DeviceCheck from a Flutter app without writing Swift code manually? If not, is DCDevice.generateToken() the only possible approach, and must I implement this via Swift and Flutter platform channels? Thanks!

First time user here. Trying to build my React-Native app on xcode. I keep getting "Could not build Module" and "missing package product" and tried many combination for my Podfile. I am on macbook pro M2, XCode version 16.2, building on iphone 16 v18.3.1. Pod version 1.16.2, react-native-cli:2.0.1, Here is my Podfile. I tried to assign modular_headers to individual Firebase packages but then I cant pod install. require_relative '../node_modules/react-native/scripts/react_native_pods' require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules' use_modular_headers! platform :ios, '18.0' prepare_react_native_project! target 'plana' do config = use_native_modules! use_react_native!( :path => config[:reactNativePath], :fabric_enabled => false, :app_path => "#{Pod::Config.instance.installation_root}/.." ) post_install do |installer| react_native_post_install( installer, config[:reactNativePath], :mac_catalyst_enabled => false, ) end end

Hello, According to documentation, the App Store does not re-download the entire app when updating, but instead generates an update package containing only the changed content compared to the previous version. I’d like to clarify the following points: 1. Granularity of file changes If only part of a large file changes, does the update package include the entire file, or does it patch only the modified portions within that file? 2. Guideline on separating files The documentation recommends separating files that are likely to change from those that are not. How should this be interpreted in practice? 3. Verifying the diff result Is there a way for developers to check the actual diff result of the update package generated by the App Store without submitting the app? Is there a diff command tool or comparison method closer to the actual App Store update process? 4. Estimating update size during development For apps with large-scale resources, minimizing update size is critical. Are there any tools or best practices to estimate the size of the update package before submitting to the App Store? Any clarification or reference materials would be greatly appreciated. Thank you.

Subject: Assistance Needed with Enabling Speech Recognition Entitlement for iOS App Hi everyone, I’m seeking guidance regarding the Speech Recognition entitlement for my iOS app using Capacitor. Our App and we submitted a request to Apple Developer Support four days ago, but have not yet received a response. 🧩 Summary of the issue: Our app uses the Capacitor speech recognition plugin (@capacitor-community/speech-recognition) to listen for native voice input on iOS. We have added both of the required keys in Info.plist: NSSpeechRecognitionUsageDescription NSMicrophoneUsageDescription We previously had a duplicate microphone key, which caused the system to silently skip the permission request. After removing the duplicate, we did briefly see the microphone permission prompt appear. However, in our most recent builds, the app launches without any prompts, even on a fresh install. The plugin reports: available = true permissionStatus = granted Despite this, no speech input is ever received, and the listener returns nothing. We believe the app is functioning correctly at a code level (plugin loads, no errors, correct Info.plist), but suspect the missing Speech Recognition entitlement is blocking actual access to the speech system. 🔎 What we need help with: How can we confirm whether the Speech Recognition entitlement is enabled for our App ID? If it’s not enabled, is there a way to escalate or re-submit the request? Our app is currently stuck until this entitlement is granted. Thank you for your time and any guidance you can offer!

My application targets iOS 15+. Attempting to build and run it on my iPhone SE (orphaned at iOS 15.6) results in "Failed to prepare the device for development." I'm building with Xcode 15.2. What is the expected procedure here?

We are experiencing an issue where our app gets stuck during launch. The splash screen appears for some time, and then the app either becomes unresponsive or closes unexpectedly. However, there are no crash logs captured in Xcode or Firebase Crashlytics, indicating that the app is not crashing but rather being terminated. This issue is preventing affected users from properly launching the app. Additionally, some users have reported occasional lag and slow performance when using the app. The issue occurs only for a specific subset of users and appears to be related to other Electronic Logging Device (ELD) apps running in the background. When these apps are active, our app struggles to launch and sometimes becomes unresponsive. We suspect that this behavior could be related to system resource allocation, such as high memory consumption by background apps, which might be affecting our app's ability to launch correctly. However, we have been unable to reproduce the issue on our end despite multiple attempts. Actions Performed During App Launch: Firebase configuration API requests, including: Fetching account details Registering the FCM token with the server Asynchronous background requests to fetch POI details Creating a local database and storing POI data in local storage We would like guidance from Apple regarding potential causes and debugging strategies, especially in scenarios where the app does not produce crash logs but still fails to launch properly. Any insights into memory management, conflicts with background applications, or system resource constraints would be highly appreciated. Steps to Reproduce: Install and launch the app on an affected device. Observe that the app gets stuck on the launch screen. After some time, the app terminates unexpectedly. Issue is inconsistent and occurs only for certain users. Presence of other ELD apps running in the background appears to influence the issue.

Just recently, any pkg file that I create with pkgbuild will install the Payload's application as a zero-byte file in the /Applications directory. This has been working for years without issue for me. Here are the commands I am using with company specific items replaced: pkgbuild --analyze --root MyApplicationRootDirectory standalone.plist plutil -replace BundleIsRelocatable -bool NO standalone.plist pkgbuild --identifier MyIdentifier --version 1.0 --install-location /Applications --root MyApplicationRootDirectory --component-plist standalone.plist --sign 'Developer ID Installer: MyCompany (MySignId)' --timestamp installer.pkg Any ideas on what could be causing the issue? I have verified the following: The application being added to the pkg is both signed and notarized using the correct Developer ID Application certificate. The resultant pkg file is both signed and notarized using the Developer ID Installer certificate. Verified the pkg contents using "pkgutil --expand" to dump the contents. Verified the pkg's Payload contents by extracting the data using "cat Payload | gunzip | cpio -1". This results in an application file that is a binary match for file added in the "pkgbuild --root" argument. My application is the only file within the directory passed to the "pkgbuild --root" argument. There are no warnings in the System Settings / Privacy & Security Panel when running the package installer. I have a valid Mac Developer account. I am building the application and the pkg file on the same computer. Thank you for any insight.

For the Linux version of my application which is written in C++ using Qt, I display the CHM format help files with this code: QString helpFile{ QCoreApplication::applicationDirPath() + "/Help/" + tr("DeepSkyStacker Help.chm","IDS_HELPFILE") }; QString program{ "kchmviewer" }; QStringList arguments{ "-token", "com.github.deepskystacker", helpFile }; helpProcess->startDetached(program, arguments); (helpProcess is a pointer to a QProcess object) The -token com.github.deepskystackerpart of that ensures that only a single instance of the viewer is used for any code that uses that invocation. Are there any chm file viewers for macOS that are capable of that sort of trick? The ones I've found on the App Store give minimal information and appear to be very simple minded tools that are not not intended for integration into an application as above. I know that MacPorts offers ports of kchmviewer but I'd prefer not to use either that or HomeBrew ... David

I am running Appium tests on an iOS 18 simulator, and I am encountering an intermittent issue where the device screen gets locked unexpectedly during the tests. The Appium logs show no errors or unusual activity, and all commands appear to be executed successfully. However, upon reviewing the device logs, I see entries related to the lock event, but the exact cause remains unclear. SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] lockUIFromSource:Boot options:{ SBUILockOptionsLockAutomaticallyKey: 1, SBUILockOptionsForceLockKey: 1, SBUILockOptionsUseScreenOffModeKey: 0 } SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] -[SBTelephonyManager inCall] 0 SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] LockUI from source: Now locking Has anyone experienced similar behavior with Appium on iOS 18, or could there be a setting or configuration in the simulator that is causing this issue?

Hello, I have created a .NET MAUI application in Windows Visual Studio 2022. Also I have a MAC fully configured with latest Visual Studio for MAC and Xcode Installed. When pairing the MAC for windows machine I am able to run the simulators for various IPhone devices(as they are attached to MAC) but when I try to run for the MacCatalyst from my Windows machine it doesnt work. Is it possible to create a build for the MAUI application for MacCatalyst from my windows machine.The build should be created in my Windows folder directory.?

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.

Hey, Since I set up push notifications for my Flutter app following this tutorial https://documentation.onesignal.com/docs/flutter-sdk-setup, my Flutter app no ​​longer builds for iOS in the CD pipeline. I get the following error: [17:24:47]: ▸ ProcessException: Process exited abnormally with exit code -6: [17:24:47]: ▸ Command line invocation: [17:24:47]: ▸ /Applications/Xcode_15.4.app/Contents/Developer/usr/bin/xcodebuild -list [17:24:47]: ▸ User defaults from command line: [17:24:47]: ▸ IDEPackageSupportUseBuiltinSCM = YES [17:24:47]: ▸ 2025-03-10 17:24:46.855 xcodebuild[13337:34491] [MT] DVTAssertions: ASSERTION FAILURE in DevToolsCore/Xcode3Core/LegacyProjects/Frameworks/DevToolsCore/DevToolsCore/ProjectModel/DataModel/References/SynchronizedGroups/PBXFileSystemSynchronizedAbstractGroup.m:28 [17:24:47]: ▸ Details: Assertion failed: IDEFileSystemSynchronizedGroupsAreEnabled() [17:24:47]: ▸ Object: <PBXFileSystemSynchronizedRootGroup> [17:24:47]: ▸ Method: +allocWithZone: [17:24:47]: ▸ Thread: <_NSMainThread: 0x60000026c200>{number = 1, name = main} [17:24:47]: ▸ Hints: [17:24:47]: ▸ Backtrace: [17:24:47]: ▸ 0 -[DVTAssertionHandler handleFailureInMethod:object:fileName:lineNumber:assertionSignature:messageFormat:arguments:] (in DVTFoundation) [17:24:47]: ▸ 1 _DVTAssertionHandler (in DVTFoundation) [17:24:47]: ▸ 2 _DVTAssertionFailureHandler (in DVTFoundation) [17:24:47]: ▸ 3 _DVTAssertionWarningHandler (in DVTFoundation) My pipeline looks like this: name: iOS Build and Deploy to App Store with Custom Version on: workflow_dispatch: inputs: version: description: 'Version number' required: true default: '1.0.0' env: FLUTTER_CHANNEL: "stable" RUBY_VERSION: "3.2.2" jobs: build_ios: name: Build iOS runs-on: macos-latest timeout-minutes: 20 steps: - name: Checkout uses: actions/checkout@v4 - name: Set up Ruby uses: ruby/setup-ruby@v1 with: ruby-version: ${{ env.RUBY_VERSION }} bundler-cache: true working-directory: 'daytistics/ios' - name: Clean up vendor working-directory: 'daytistics/ios' run: rm -rf vendor - name: Install Bundler Gems working-directory: 'daytistics/ios' run: bundle install - name: Run Flutter tasks and get pub packages uses: subosito/flutter-action@v2.16.0 with: flutter-version-file: 'daytistics/pubspec.yaml' channel: ${{ env.FLUTTER_CHANNEL }} cache: true - name: Get Flutter Packages working-directory: ./daytistics run: flutter pub get - name: Install Bundler Gems working-directory: 'daytistics/ios' run: | bundle install bundle exec pod repo update # Add this line # Remove the "Reinstall CocoaPods" step entirely - name: Pod Install working-directory: 'daytistics/ios' run: bundle exec pod install - name: Clean Flutter build working-directory: ./daytistics run: flutter clean - name: Create .env file working-directory: ./daytistics run: touch .env - uses: maierj/fastlane-action@v3.1.0 with: lane: 'release_app_store' subdirectory: daytistics/ios options: '{ "version_number": "${{ github.event.inputs.version }}", "env_vars": ["SUPABASE_URL", "SUPABASE_ANON_KEY", "POSTHOG_API_KEY", "SUPABASE_AUTH_EXTERNAL_GOOGLE_CLIENT_ID", "SENTRY_DSN"] }' env: ASC_KEY_ID: ${{ secrets.ASC_KEY_ID }} ASC_ISSUER_ID: ${{ secrets.ASC_ISSUER_ID }} ASC_KEY_P8_BASE64: ${{ secrets.ASC_KEY_P8_BASE64 }} MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }} MATCH_GIT_BASIC_AUTHORIZATION: ${{ secrets.MATCH_GIT_BASIC_AUTHORIZATION }} APP_BUNDLE_ID: ${{ secrets.APP_BUNDLE_ID }} GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} SUPABASE_URL: ${{ secrets.SUPABASE_URL }} SUPABASE_ANON_KEY: ${{ secrets.SUPABASE_ANON_KEY }} POSTHOG_API_KEY: ${{ secrets.POSTHOG_API_KEY }} SUPABASE_AUTH_EXTERNAL_GOOGLE_CLIENT_ID: ${{ secrets.SUPABASE_AUTH_EXTERNAL_GOOGLE_CLIENT_ID }} SENTRY_DSN: ${{ secrets.SENTRY_DSN }} Everything works as expected in the simulator. However, I think that the problem isn't related to the pipeline. Instead I think it is related to the "Signing Capabilities" in X-Code: https://i.sstatic.net/E0tSetZP.png https://i.sstatic.net/oC1xG0A4.png Thanks for your help!

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

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.

I wanted to rollback a commit. So I shifted to the commit before it. Then I added new commits on the one I switched to, not realising this is not happening on the main branch. Now what do I do? Neerav

I am on a windows computer using visual studio 2026 for developing .NET Maui apps for Android and iOS. Am I able to connect my iPhone to my windows computer and deploy my .NET Maui app to my connected iPhone during deveoplemt?