Hi, I want to build an ios app that uses static c libraries. For reference, i did the following as a test: Compiled a simple c date and time program with clang -c -arch arm64 -sysroot <iPhoneOSSDK_path> date.c -o date_arm64.o Created the static lib ar rcs libdatetime_arm64.a date_arm64.o Added the lib in my Xcode project. Added the (.a) file in Build Rules -> Link Binary With Libraries Included the (.a) and (.h) file path in Build Settings -> Search Paths -> Header and Library Search Path Created a Bridging-Header.h file where I added #import "date.h" In my App.swift file, I called the function for getting the date and time let dateTimeStr = String(cString: get_current_datetime()) print("Current Date and Time: \(dateTimeStr)") After doing all the steps above, I am met with the error - Cannot find 'get_current_datetime' in scope Is there any other method to use static c libraries in xcode?

Currently, if as a library author you are shipping dependencies as code, you can use the #if DEBUG preprocessor check to execute logic based on whether app is being built for Debug or Release. My concern is more about the approach that should be taken when distributing frameworks/xcframeworks. One approach I am thinking of using is checking the presence of {CFBundleName}.debug.dylib in the main bundle. Is this approach reliable? Do you suggest any other approach?

Dear Apple,I'm an iOS developer and provided feedback in the good old online bug tracker for many years.Decent conversations with Apple egnineers often resulted in bug fixes or updated documentation.The fact that my contributions helped to improve the products was rewarding.So I kept adding reports in the new Feedback Assistant app in macOS Catalina.But ever since (September 2019) I never ever got any response on any ticket.1 month ago I even added a report if Apple even read my reports. Again, no response ever since.So my question on this forum: Is Apple actually reading reports in the new Feedback Assistant?This can either be answered by Apple, or by other Developers that hopefully did response feedback from Apple. Or did not.Best regards,Martijn

Calling dlopen then dlclose causes an increase in the amount of memory used by the program. If I create a loop that calls dlopen / dlclose repeatedly on the same dynamic library, memory usage increases continuously. Is this a bug, or am I using dlopen / dlclose incorrectly? I can reproduce this by modifying the sample code in the Apple Developer docs Creating Dynamic Libraries. If I modify Runtime.c, changing the line void *lib_handle = dlopen(lib_name, RTLD_NOW); to add the infinite loop, as below: void *lib_handle = dlopen(lib_name, RTLD_NOW); for (int ii = 0; ; ++ii) { printf("loop %i\n", ii); int close_err = dlclose(lib_handle); printf("close error: %i\n", close_err); printf("dlopen(%s, RTLD_NOW)\n", lib_name); lib_handle = dlopen(lib_name, RTLD_NOW); } then opening and closing the dynamic library will succeed, but memory usage (as reported by top) will rapidly increase. I'm running on x86_64 macOS 13.6.6. Full code for the modified Runtime.c is attached, the rest of the code is available in the Apple Developer docs. Any suggestions? Many thanks, Chris Runtime.c

What is the recommended approach for distributing an XCFramework that uses common third-party dependencies (like Google Maps) when client apps may also use the same dependencies, resulting in duplicate symbol conflicts? I'm developing a closed-source SDK distributed as an XCFramework. My SDK internally uses Google Maps for mapping functionality. However, when clients integrate my XCFramework into their apps that also use Google Maps, we encounter duplicate symbol errors. What I've Tried: Static vs Dynamic Linking: Both approaches result in conflicts Static linking: Google Maps symbols compiled into my binary Dynamic linking: GoogleMaps.framework bundled with my XCFramework Build Configuration: Set "Build Libraries for Distribution" = YES Tried various linking strategies Architecture Changes: Used @implementation_only import Wrapped code with #if canImport(GoogleMaps) However, the dependencies still get linked at build time

My App cordova based hubrid app , which work fine till ios-17, On iOS 18 , it shows blank screen untill the user touch or scroll the view

We are trying to setup Apple Unity Plugins, in out project we have a handful of developers who contribute to the project via git. When building and importing plugins via tarball (as instructed in the Github repo) the package clearly points to local path, so once pushed all members encounter the error: An error occurred while resolving packages: Project has invalid dependencies: com.apple.unityplugin.accessibility: Tarball package [com.apple.unityplugin.accessibility] cannot be found at path ..... When trying to actually move content to the package folder (same way as any other unity plugins is setup) and add it as "embedded", it works fine on local machine, but team members will get a few of errors: [Apple Unity Plug-ins] No Apple native plug-in libraries found. DLLNotFoundException: AppleCoreNativeMac assembly ... No Apple Native plug-in libraries found. Moreover AppleCoreNativeMac.bundle is flag as not verified and deleted by macOS. What is the right way to setup unity plugins in a project used by multiple members via sourcetree ?

I was just having a look at some crash reports downloaded by Xcode, and I noticed the same wrong pattern I already mentioned here: the crash reports indicate that method A calls method B, which is impossible. In the first crash report below, method MainViewController.showSettings seems to be called by ConfirmMoveViewController.openSourceInFinder, which is impossible. ConfirmMoveViewController.openSourceInFinder is a context menu action in a modal window, and MainViewController.showSettings is in a completely different window and the two methods have no relation whatsoever. In the second crash report below, MainViewController.setSortMode is triggered by the press of a button (and nothing else) but seems to be called by OtherViewController.copy that can be triggered by a context menu (or keyboard shortcut). The two methods have no relation whatsoever. The rest of the stack trace confirm that it's indeed the button that was pressed. This seems to me like a quite serious bug in how macOS creates crash reports. 1.crash 2.crash

For my app Find Any File, of which both releases and TestFlight betas were released many times, the TestFlight page tells me that several users have submitted crash reports. And I'm sure the same is true for the MAS releases: (Yes, this shows quite recent ones, but I've seen similar supposed crash report submits in this list before.) However, the actual "Crashes" listing on the appstoreconnect sites hasn't show any new crash reports for many months now: (This is the entirety of crash reports I can get listed, even when removing all filters.) Something appears to be stuck, on Apple's end. The same issue is with Xcode's Organanizer window, for "Crashes": It also used to list only the same very old reports and nothing since May 2024. And just now, when I retried this in Xcode, I'm shown a weird error message I never saw before: Error Downloading Crashes List An error occurred… Access Restricted with adam id: 1207815783 And yes, I'm logged in just fine, under Prefs / Accounts. How am I going to get this investigated? I had already sent an email about this to the Review team, who didn't react to it at all. DTS is only for Code level support, which this isn't. Any help?

Hi everyone, I’m encountering an issue with Firebase Dynamic Links in my app that I’m hoping someone can help me with. Everything was working perfectly before, but recently, I’ve run into a problem. Here’s the scenario: If the app is not installed and a Firebase Dynamic Link is clicked, the user is correctly redirected to the app store to install the app. Once the app is installed and opened for the first time, the dynamic link doesn't work. The app doesn't open to the correct content or link that was clicked. I’ve tried the following troubleshooting steps with no success: Verified that the app is configured properly in Firebase and that the Dynamic Links settings are correct. Checked the app's deep linking settings and ensured everything matches with the Firebase setup. Confirmed that the Firebase SDK is up-to-date. Attempted to clear app cache and reinstall. Tested the links in both debug and production modes. Despite trying all these steps, the issue persists. Has anyone else faced this issue before or have any suggestions for how to fix it? Any insights would be greatly appreciated! Thanks in advance!

Hi, I am trying to bring an existing Unity app to vision pro, and am trying to make all of the librairies compatible (the project loads native libs at runtime). For some of them, there is an arm64 IOS .framework file that seems to build and be found easily in the device, but for one of them I only got a .dylib. When building on xcode, it tells me it can't find it. So I added it to the lib search path in build settings, and it built. But on the device, it still can't seem to find the .dylib : Library not loaded: ./libpdfium.dylib Referenced from: <59B1ACCC-FFFD-3448-B03D-69AE95604C77> /private/var/containers/Bundle/Application/0606D884-CB09-44CA-8E4F-4A309D2E7053/[...].app/Frameworks/UnityFramework.framework/UnityFramework Reason: tried: '/usr/lib/system/introspection/libpdfium.dylib' (no such file, not in dyld cache), './libpdfium.dylib' (no such file), '/usr/lib/system/introspection/libpdfium.dylib' (no such file, not in dyld cache), '//libpdfium.dylib' (no such file) I am not used to Apple environment, is there a way to correctly reference this .dylib (not talking about compatibility here, just the first "lib found" step) ? Thanks.

I've got a large and complex app which has several dependencies upon 3rd party libraries (installed as pods). The app is structured according to Model-View-Controller design and there is a requirement to implement the Model part as an .xcframework so it can be included and used in the original app along with a few new apps. However, Apple documentation states that umbrella frameworks are not supported (Technical Note TN2435). The Model code has several dependencies which would be totally unfeasible to replace or remove, for example it uses RealmSwift for database storage. Obviously it would be impossible to write one's own database storage scheme in place of using Realm. However, if my framework uses Realm as a dependency, then its now become an umbrella framework. So therefore not supported according to Apple documentation. So what are options/solutions?

I'm trying to rewrite an old AppleScript mail rule that I used extensively as a Mail extension using the MailKit framework and I've run into an issue. Previously, when developing the script, it was possible to debug it by selecting the message I wanted it applied to and choosing the Mail.app menu item "Message/Apply Rules" This would re-execute my script and I could iterate over it as many times as I liked while developing. I haven't found any great way of doing this for my extension with a MEMessageActionHandler. The closest I've found is to forward the message to myself and wait for it to come back in again over the internet, at which point the extension would get executed again. Needless to say, this makes debugging my MEMessageAction handler much slower. I've tried a number of things in Mail.app to try and get it to re-execute my extension with a particular message without any luck. Does anyone know of a good process for debugging a MEMessageActionHandler that doesn't involve forwarding the message to myself over and over and waiting for it to come in each time?

Hi, anyone managed to make this work? https://developer.apple.com/documentation/backgroundassets Trying for past few days and can't make it work. Following their official documentation, also this video https://www.youtube.com/watch?v=M3jpgZrB1uo, but it seems I am stuck at: try await AssetPackManager.shared.ensureLocalAvailability(of: assetPack) What I did: Manifest files created, info.plist configured, asset pack created and uploaded to appstoreconnect via transporter, successfully assigned to app and ready for internal testing. Added to my code: let assetPack = try await AssetPackManager.shared.assetPack(withID: "Tutorial") try await AssetPackManager.shared.ensureLocalAvailability(of: assetPack) let videoData = try AssetPackManager.shared.contents(at: "Videos/Introduction.m4v") but no luck at all.... is anywhere any demo project available to download to compare with my project?

Looking for a dynamic table that displays the latest supported CLI versions with the version of macOS. Specifically, is CLI 15.3 supported on Ventura 13.7.8? More generally, what is the lastest version of CLI supported on macOS <version_goes_here>

I want to test different types of journaling suggestions, like for example photo/video containing ones but as a developer I have no control over what's shown in the Journaling Suggestions sheet. And this makes it really difficult to develop or test any suggestion type other than "reflection". Please let us have a fake suggestions sheet that includes all kinds of suggestion types so we can test. We could toggle it under Developer settings I think.

I have one iOS device running iOS 16.7.10. When I run xcrun devicectl list devices I can't see that device at all. Is that know limitation (devicectl only work in iOS 17 and above) or is something wrong with my setup. Also is there some documention about devicectl. I can't seem to find anything about in the offical apple sites.

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?

I am experiencing an issue with PHP on macOS where errors and warnings are not displayed, either in the terminal or when running scripts through the built-in PHP server.

Our app has an old codebase, originating in 2011, which started out as purely Objective-C (and a little bit of Objective-C++), but a good amount of Swift has been added over time as well. Lots of Objective-C and Swift inter-op, but in general very few 3rd party libraries/frameworks. Like many other codebases of this size and age, we have a good amount of accumulated tech debt. In our case, that mostly comes in the form of using old/deprecated APIs (OpenGL primary amongst them), and also using some ‘tricks’ that allowed us to do highly customized UI popups and the like before they were officially supported by iOS, but unfortunately are still in use to this day (i.e. adding views directly to the UIWindow such that that are ‘on top’ of everything, instead of presenting a VC). Overall though, the app is very powerful and capable, and generally has a relatively low crash rate. About two months ago, we started seeing some new crashes that seemed to be totally unrelated to the code changes that were made at the time. Moreover, if a new branch with a feature or bug fix was merged in, the new crash would either disappear entirely, or move somewhere else. These were not ‘normal’ crashes either - when hooked up to the debugger in Xcode, often times the crashes would happen when calling into system library (e.g. initializing a UIColor object). Some of the steps taken to try and mitigate or eliminate these crashes include: Rolling back merges Often worked, but then most future merges would cause a new and different crash to appear Using the TSan and ASan tools to try and diagnose thread or memory issues TSan reported a couple of issues near launch that have been fixed, and there are others in some areas of the app, but they have been around a long time and don’t appear to correlate with any recent changes, nor did fixing the ones at launch (and throughout testing to try and reproduce crashes) result in elimination of the new crashes ASan does not identify any issues Modifying the code changes in a branch before merging it in In one case where the changes were limited to declaring ‘@objc static var: Bool’ in a Swift class and setting a value to it in a couple of places, simply removing the @objc from the declaration would result in the crash going away. Since the var had to be exposed to Objective-C, it was eventually moved to a pure Objective-C class that already existed and is a singleton (not ideal, but it’s been around a long time and has not yet been refactored) in order to preserve the functionality and the crash was no longer reproducible Removing all 3rd party libraries or frameworks Not a long-term solution, and this mostly worked in that the crashes went away, but it also resulted in removal of long-existing features expected by our users Updating 3rd party libraries and frameworks when possible (there were some very old ones) Updating these did not have any effect on the crashes, except that the crashes moved around in the same way as when merging in a branch, and again, where the crash actually occurred was uncorrelated with the library/framework that was updated Changes to the App’s Build Settings in Xcode Set supported/valid architectures to arm64 exclusively Stripping of all architectures other than arm64 from 3rd party binaries Cleaning up of old/outdated linker flags Removal of other custom build flags that were needed at one point, but are no longer relevant Generally trying to make all the build settings in our (quite old/outdated) app match those of a newly created iOS app Code signing inject base entitlements is set to YES Removal of old/deprecated BitCode flag These changes seemed to help and the codebase was more ‘stable’ (non-crashing) for a while, but as we tried to continue development, the crashes would reappear Getting crash reports off of test devices and analyzing them based on the various documents about crash reports provided by Apple This was helpful and pointed to new things to investigate, but ultimately did not help to identify the root cause of these crashes Throughout all of the above, the crashes would come and go, very reproducibly for a given branch being merged in, but if a subsequent branch is merged in, the crash may go away, or simply move somewhere else - sometimes it would crash in our code that calls other parts of our code, and other times when calling system frameworks (like the UIColor example above). One thing that is consistent though, is that the crash would never happen anywhere near the code that was changed or added by a branch that was merged in. Additional observations when trying to figure out the cause of these crashes: Sometimes the smallest code change would result in a crash happening or not The crash reports generated on-device vary quite a bit in terms of the type and reason for the crash All crashes have an Exception Type of EXC_BAD_ACCESS, but vary between (SIGABRT) (SIGBUS) (SIGKILL) (SIGSEV) The crashing thread is often (but not always) on Thread 0 (main thread), and often the first line in the backtrace would be just ‘???’, sometimes followed by a valid memory address and file, but often times just ‘0x0 ???’ Most crash reports have an exception subtype of KERN_PROTECTION_FAILURE Many also state that the Termination Reason is ‘CODESIGNING 2 Invalid Page’ This in particular was investigated thoroughly, including looking at the Placing Content In A Bundle document but after further changes to ensure that everything is in the right place, the crashes were still observed Another odd thing in most of the crash reports is in the Binary Images section, there is a line that once again is mostly ???s or 000s - specifically ‘0x0 - 0xffffffffffffffff ??? unknown-arch <00000000000000000000000000000000> ???’ The crashes occur on different physical devices, typically the same crash for a given branch, and regardless of iOS version This includes building from different Macs. We did observe some differences between versions of Xcode (crashed similarly when built from an older version of Xcode, but not from a newer one), but we recently had all developers ensure they are running Xcode 16.4 - we also tried Xcode 26, but the crashes were still observed Overall, it seems like there is something very strange going on in terms of how the App binary is constructed such that a small code change somehow affects the binary in such a way that memory is not being accessed correctly, or is not where it is expected to be. This level of what appears to be a build-time issue that manifests in very strange run-time crashes is both confusing and difficult to diagnose. Despite the resources provided by Apple for investigation and diagnosis, we cannot seem to find a root cause for these crashes and eliminate them for good.