I had a simulator crash developing bluetooth IOS app on a Sonoma 14.5 M2 MacBook Air. Since the crash bluetooth on the MacBook Air no longer functions. Systems Settings/Bluetooth Turned on shows: 'My Devices' shows none of the 5+ devices I use 'Nearby Devices' shows constantly searching. A Bluetooth scanner 'LightBlu" by puchthrough run on a iPhone shows no signal from the Mac Air. I tried deleting: /Users/~/Library/Preferences/com.apple.bluetoothuserd.plist and then LightBlue could connect for a little while but the System/Settings never change. What can I do. Should I reinstall the simulator, xCode the system or all the above?

Running Xcode 16b4 on Apple silicon. Create a fresh Swift package, it will be using swift-tools-version: 6.0. Add a Swift Test to the test target with some basic assertion like #expect(true). Run the test against the target My Mac and the test will compile, run and pass. Run the test against the target My Mac (Mac Catalyst) and the test will compile and crash with EXC_BAD_ACCESS. If you create an equivalent XCTest, it will compile, run and pass against both destinations. Has anyone else experienced this? Is this already being tracked? Is this possibly related? https://github.com/swiftlang/swift/pull/75432

Does Swift Testing support using ‘any’ values as parameters like seen here for ‘any ChartDataPoint.Type’ @Test(arguments: [ (expectedBodyFatValues, HKQuantityTypeIdentifier.bodyFatPercentage, HKUnit.percent(), BodyFatPoint.self), (expectedActiveEnergyValues, HKQuantityTypeIdentifier.activeEnergyBurned, HKUnit.kilocalorie(), ActiveCaloriesPoint.self), (expectedBodyMassValues, HKQuantityTypeIdentifier.bodyMass, HKUnit.pound(), BodyMassPoint.self), (expectedBasalEnergyValues, HKQuantityTypeIdentifier.basalEnergyBurned, HKUnit.kilocalorie(), BasalEnergyPoint.self) ]) func healthKitDataReading( expectedData: [Double], identifier: HKQuantityTypeIdentifier, unit: HKUnit, dataChartType: any ChartDataPoint.Type ) async throws {...} Currently I can’t get this code to work, and see the error … Conflicting arguments to generic parameter 'C' ('[([Double], HKQuantityTypeIdentifier, HKUnit, BodyFatPoint.Type)]' vs. '[([Double], HKQuantityTypeIdentifier, HKUnit, ActiveCaloriesPoint.Type)]' vs. '[([Double], HKQuantityTypeIdentifier, HKUnit, BodyMassPoint.Type)]' vs. '[([Double], HKQuantityTypeIdentifier, HKUnit, BasalEnergyPoint.Type)]') Also, I can’t seem to use variables like ‘expectedBodyFatValues’ due to the error Instance member 'expectedBodyFatValues' cannot be used on type 'Health_Mix_Swift_Tests'; did you mean to use a value of this type instead? Only way I’ve found around this is including the entire array of values as the parameter, but it’s very cumbersome.

I am new to app development. When setting up forecast, I downloaded the libraries and updated the code in my main app, but when I entered import FirebaseCore, I receive an error that says “No such module 'FirebaseCore'" Dies anyone know why it is not working?

Hi! I am having a strange issue when I try to build my react native project in an eas managed workflow (including dependencies just in case). The error I get is: Provisioning profile "[profile]" doesn't include the com.apple.developer.proximity-reader.payment.acceptance entitlement. Profile qualification is using entitlement definitions that may be out of date. Connect to network to update. (in target '[project_name]' from project '[project]') I find this weird because I have enabled the entitlement in my identifier and my provisioning profile reflects this fact. I have set up an entitlements file where I have set up the kv pair for the entitlement. Any help would be much appreciated!

We have implemented a NEFilterDataProvider in our Network Extension. We want to utilize the WebContentFilter payload within the Device Management Configuration profile to allow the functionality of our content filter. In the Device Management Profile documentation, there are three properties that are related and seems to have some conditions around them: FilterBrowsers, FilterPackets and FilterSockets. It stated that "At least one of FilterBrowsers or FilterSockets needs to be true" for FilterBrowsers, "At least one of FilterPackets or FilterSockets needs to be true" for FilterPackets, and At least one of FilterBrowsers or FilterSockets needs to be true" for FilterSockets. Based on the above conditions, if we only set FilterPackets to true and ignore the other two properties, it would not satisfy the condition for FilterSockets as both FilterBrowsers and FilterSockets are false. However, during testing we found out that this still works and our content filter is filtering traffic as expected. Does this mean only ONE of the THREE properties need to be true? Or should we make changes according to the documentation to have it align with all conditions and requirements? Any clarifications of the properties and their requirements are much appreciated!

XCTest can not get ios 18 contacts permission page elements, can not click "Allow Full Access" button.

I am getting this error after packaging the xyz.app however the xyzzy.app runs well and good in my Mac - MINI whenever I try to package and install I am getting this error. in the package contents of the application I am able to see FlutterMacOS.framework Can you help me with it

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

Hi, I am currently trying to install and run a watchOS App I developed in Xcode on an Apple watch series 9. I would like to add the Apple watch as a registered device to a developer account. I need to provide the device name and the device ID or UDID to register the Apple watch. I am not sure how I can get the UDID for the Apple watch. I would appreciate your help with information on how I can get the UDID for the Apple watch and if the watch needs to be registered with a developer account for installing and running a watchOS app from Xcode on the Apple watch. Thank you.

Hello, We have an app built with a hybrid framework called NativeScript, and deployed on iPad devices. Since the update to iOS 17.4, we're experiencing crashes that seem to be caused by an out of memory problem. I was able to retrieve crashes reports in .ips format that seem to confirm the out of memory hypothesis, but by lack of experience and knowledge in iOS environment, I couldn't find the origin of the problem yet. One of the most difficult point is that we haven't been able yet to reproduce the bug at home, even with the concerned tablets. Our app crashes randomly on customer's sites, this is manifested by the app getting frozen, with graphic artifacts in the form of vertical gray stripes onto the whole screen. For now, the remedy is to reboot the tablet remotely. I've tried to launch the app on a problematic tablet in profiling mode with Xcode, with the Leaks tools from Instruments, but even after navigating in the whole app, I can't see any suspicious growth in memory usage. Is there someone here that can help me to read the .ips file to understand and isolate the cause of the problem ? Thanking you by advance. P.S : I formatted ips file in valid JSON format

The root plist is not reading variables after upgrading my iPad to iOS 18 beta. Following the upgrade, the application-specific settings of a native app become empty. Previously, multiple variables were visible.

I've been working on a Swift PM wrapper for the libtiff library, which I installed on my Mac via Brew. So far so good. But I just tried adding it to my visionOS project. and it complained that it was trying to link against a library built for macOS: building for 'visionOS-simulator', but linking in dylib (/opt/homebrew/Cellar/libtiff/4.6.0/lib/libtiff.6.dylib) built for 'macOS' I wish Brew would build universal libraries, but it doesn’t, and they have no interest in doing so. What are my options? If I build libtiff from sources, it’s still a bit of a pain to build against a different SDK. libtiff has its own Makefile I’d rather not try to edit. Can I make an xcframework out of it? Can I statically link it into my Swit wrapper library? Do I need to hack together a C build target in my Package and copy the source files over to it?

During updating my Ipad (2024 pro 11 inch) with beta IOS 18, it stopped working, only a black screen. A hard reset (with volume controls and top button) does not work..

Reporter 3.1.6 has been reporting the following error since 7/18/2024: "Report is unexpectedly not available. Try again later"

I'm new to Xcode and have built a simple widget that runs on my macOS. The simulator opens whenever I run the project, and I can see my widget. However, when I close the simulator, it crashes, and I get the error message "WidgetKit Simulator quit unexpectedly". I run Xcode 16 beta 3 Any ideas?

I'm running a MacOS15 beta 3 VM on a MacOS15 beta 3 Host (M2 Pro Mac Mini) using the Apple Virtualization Framework (via https://github.com/s-u/macosvm). For building my app inside the VM I need Rosetta 2, since flutter still uses some Intel binaries. But when I want to install Rosetta 2 I'm always getting the message, that installing Rosetta 2 is not allowed on this system. Digging in the log files I found a message from the installer, that the system is not supported. Searching online I just find a method for using Rosetta 2 inside Linux VM's using the Virtualization Framework. Am I missing something or is it not possible to use Rosetta 2 with MacOS guests?

I want to use sftp functionality in my SwiftUI app and I have decided to try and do it using plain libssh2 (ie. without an initial wrapper or anything). libssh2 is written in C. What are the steps I need to take in order to start calling the libssh2 C functions in my SwiftUI app?

I am using an iPhone 15 Pro as my iOS simulator, and the IDE that I am using is Android Studio. This issue is happening on a 2019 MacBook Pro 16 inch, running the latest version of Xcode, and running macOS Sonoma 14.5. I've never had this issue on other, older/newer Macs with Android Studio. Everytime I interact with the simulator, it shows green bars and distorts the view quite a bit (See screenshots below). I tried all that I could think of, including, but not limited to: Restarting simulator, restarting MacBook, restarting Android Studio, using different iOS simulators (same problem), and so forth. I have not found any such occurrence to anyone else while looking online for answers. One interesting thing that I noticed is that for Xcode projects, the simulator runs perfectly, but when I use Android Studio, the simulator doesn't work properly at all. Any solutions to this? All input is greatly appreciated. P.S.: I have tested the app on an actual iOS device, and it works perfectly. Here are some screenshots. This show what happens when you scroll or interact with the app: (Each screenshot is a different interaction)

Hello, My app often crashes when I use simulators. I would like some help with reading the crash report that is generated. Especially with the part below Thread 0 Crashed. Based on other posts I understand that the 0x8BADF00D in the crash report is a WatchDog crash that basically says that WatchDog terminated the app because the main thread was blocked for a significant time. Many processes can block the main thread so it's hard to find out what it is in our specific case. Can someone help me reading through the crash report? Short_crash_report.txt Background information The application is Xamarin Native and I use Rider as an IDE. When I use Visual Studio, the simulators run just fine. No crash occurs while using my app on a device. The crash happens on multiple simulators with different OS versions. I already deleted XCode cache, erased content and settings of several simulators and deleted iOS DeviceSupport files.