I have static libraries and headers of a C++ project that I believe are correctly built for iOS and iOS Simulator destinations. The C++ project is built via CMake with something like: cmake dirName \ -G "Unix Makefiles" \ -B buildDir \ -DCMAKE_INSTALL_PREFIX=installDir \ -DCMAKE_SYSTEM_NAME=iOS \ -DCMAKE_SYSTEM_PROCESSOR=arm64 \ -DCMAKE_OSX_ARCHITECTURES=arm64 \ -DCMAKE_OSX_SYSROOT=$(xcrun --sdk iphonesimulator --show-sdk-path) \ -DCMAKE_OSX_DEPLOYMENT_TARGET=15.0 ... cmake --build buildDir --config Release --target install I believe those are all the important parameters. This gives me a static library (.a) and headers that I believe should be compatible with arm64 iOS simulators, and I do this same thing for x86_64 architecture with simulators and for actual iOS non-simulator via the iphoneos SDK path. I'm pretty sure this gives me the correct static lib and headers. Let's assume it does because I'm not able actually create the XCFramework to know if they're right. This does work with a macOS lib and headers, but I need iOS for this library. How do I package this into an XCFramework now? This Apple developer articles says I should be a able to create an xcframework via xcodebuild -create-xcframework -library libName.a -headers include but when I try to do this with my my iOS arm64 simulator static lib I get: error: binaries with multiple platforms are not supported '/Users/.../install/ios-arm64-simulator/libName.a But, when I run: lips -info libName.a I get Non-fat file libName.a is architecture arm64, so, I'm not sure what to do here. Trying to extract arm64 from that static library also produces an error as it it is just an arm64 lib. I'm not really sure what's going on, but from reading online this specific command, xcodebuild -create-xcframework is a consistent pain point in the process of trying to get an XCFramework, and the seemingly only workaround is to archive a framework project and then create the xcframework via xcodebuild -create-xcframework -archive MyFramework.xcarchive -framework[or -library]. However, how am I supposed to get this static lib and headers into a suitable xcodeproj so that I can archive it correctly? Everytime I try to copy the headers and static lib into the Framework xcodeproj and set what I believe are all the correct settings, my .xcarchive is always empty. Does anyone have any advice here on how to get this to work? The main impetus for trying to get this C++ static lib and headers into an XCFramework as that seems like the only valid way to link a 3rd party C++ lib to an SPM package and have the C++ package be interfaceable with Swift.

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

I use CMake for my builds not the XCode GUI. I want to be able to build a single .app that contains both the GUI version and the command line version. I have seen products that ship both as part of the same .app (e.g. CMake) so this is clearly entirely possible, the 64k question is HOW? Right now I am building them as separate apps - lets call them DSS and DSSCL (*). The code base for each is in its own directory - each with its own CMakelists.txt file. My initial thoughts are to change the build for DSSCL so it doesn't create a bundle and then simply copy the DSSCL command and related .qm files into DSS.app/.../MacOS. However that's likely enough totally wrong, so how should I handle this please. As much detail as possible please, I am very new to macOS development -please don't assume knowledge of stuff that's second nature to you Many thanks David (*) Strictly they are DeepSkyStacker and DeepSkyStackerCL

I have command line tools installed: % pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 16.2.0.0.1.1733547573 volume: / location: / install-time: 1739567437 Thus clang is installed here: % whereis g++ g++: /usr/bin/g++ I also have installed gcc from homebrew: % /opt/homebrew/bin/g++-14 --version g++-14 (Homebrew GCC 14.2.0_1) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. However, I still cannot compile any c++ code, even the simplest one: #include <iostream> using namespace std; int main() { cout << "Hello World!" << endl; return 0; } It returned this error: % /opt/homebrew/bin/g++-14 ~/Downloads/try.cpp ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/lib/libSystem.tbd' for architecture arm64 collect2: error: ld returned 1 exit status It seems to be command line tools related. But I've already installed the most recent version of CLT and gcc. Additionally, clang can compile the same code: % /usr/bin/g++ ~/Downloads/try.cpp % ./a.out Hello World! What else shall I do to make this g++ compiler work?

Hello, I currently have a live application in the iOS App Store that needs an update to start functioning again, but I've lost the source code in a hard drive failure. Is there a way to reverse engineer the currently deployed package that is live (and also a way to download it from App Store Connect)⁉️ The development change itself is just a very small change for an API route in the code itself. I could even direct an engineer at Apple to make the change in 5 minutes! Let me know if this is possible. Thanks❗️

About three weeks ago I submitted a DTS ticket (13097367) to receive code level support with a potential SwiftUI bug. At first I did not receive any response at all (beside the automatic confirmation that the ticket has been created). Only after posting the question here, I got a reply from a DTS engineer. However, the proposed solution did not really solve the problem but only circumvents it (UI freezes when ScrollView reaches below SafeArea. Solution: Do not use ScrollView below SafeArea...) I pointed out, that this does not really help me. Since then I did not receive any further response. Is this normal? Is there something wrong with my ticket? Maybe it was closed by accident or something? Thank you very much!

If I build an x64 binary on my M4 Mini, when I try to debug it using Visual Studio remote debugging the connection is closed, which means I cannot debug my code in x64 mode. I need to be able to do this as I have architecture specific code. I have Rosetta installed. FWIW I have the same issue with lldb-mi :( David

Hello everybody! I would like some help to resolve the error "/usr/bin/openssl" x509 -noout. I've tried different ways but it persists. I'm using Delphi (Embarcadero) version 12, I've also tried with 11 and without success. I use MacMini version 15.2. What could be causing this error Thank you in advance

Hi, From App analytics, we found that our app crashed from time to time on users' devices despite that we have tested it thoroughly on our devices. We are doubt that it's the reason why we can't retain them. But how can we get the crash reports for the app installed on user devices? We have no users' emails and can't ask them directly.

Hi everyone, I'm developing a Capacitor plugin to display an RTSP video stream using MobileVLCKit on iOS. The Android side works perfectly, but I can’t get the iOS plugin to work — it seems my Swift file is not being detected or recognized, even though I’ve followed the official steps. What works: I followed the Capacitor Plugin Development Guide. I implemented the Android version of the plugin in Java inside the android/ folder. Everything works perfectly from Angular: the plugin is recognized and calls execute correctly. The issue on iOS: I implemented the iOS part in Swift, using the official MobileVLCKit documentation. I initially placed my RtspVlcPlugin.swift file in the plugin’s iOS folder, as the docs suggest. Then I moved it directly into the main app’s ios/App/App/ folder next to AppDelegate.swift and tried manual registration. The problem: Even though I manually register the plugin with: if let bridge = self.window?.rootViewController as? CAPBridgeViewController { bridge.bridge?.registerPluginInstance(RtspVlcPlugin()) print("✅ Plugin RtspVlcPlugin registered manually.") } It prints the registration message just fine. BUT from Angular, the plugin is not recognized: Capacitor.Plugins.RtspVlcPlugin has no methods, and I get this error: "code":"UNIMPLEMENTED" I also tried declaring @objc(RtspVlcPlugin) and extending CAPPlugin. I’ve verified RtspVlcPlugin.swift is added to the target and compiled. The Swift file doesn’t seem to register or expose any methods to Angular. I even tried adding the code without using a plugin at all — just creating a Swift class and using it via the AppDelegate, but it still doesn't expose any callable methods. My Swift code (RtspVlcPlugin.swift): import Capacitor import MobileVLCKit @objc(RtspVlcPlugin) public class RtspVlcPlugin: CAPPlugin, VLCMediaPlayerDelegate { var mediaPlayer: VLCMediaPlayer? var containerView: UIView? var spinner: UIActivityIndicatorView? @objc func iniciar(_ call: CAPPluginCall) { guard let urlStr = call.getString("url"), let x = call.getDouble("x"), let y = call.getDouble("y"), let w = call.getDouble("width"), let h = call.getDouble("height"), let url = URL(string: urlStr) else { call.reject("Missing parameters") return } DispatchQueue.main.async { self.containerView?.removeFromSuperview() let cont = UIView(frame: CGRect(x: x, y: y, width: w, height: h)) cont.backgroundColor = .black cont.layer.cornerRadius = 16 cont.clipsToBounds = true let sp = UIActivityIndicatorView(style: .large) sp.center = CGPoint(x: w/2, y: h/2) sp.color = .white sp.startAnimating() cont.addSubview(sp) self.spinner = sp self.containerView = cont self.bridge?.viewController?.view.addSubview(cont) let player = VLCMediaPlayer() player.delegate = self player.drawable = cont player.media = VLCMedia(url: url) self.mediaPlayer = player player.play() call.resolve() } } @objc func cerrar(_ call: CAPPluginCall) { DispatchQueue.main.async { self.mediaPlayer?.stop() self.mediaPlayer = nil self.spinner?.stopAnimating() self.spinner?.removeFromSuperview() self.spinner = nil self.containerView?.removeFromSuperview() self.containerView = nil call.resolve() } } public func mediaPlayerStateChanged(_ aNotification: Notification!) { guard let player = mediaPlayer, player.state == .playing, let sp = spinner else { return } DispatchQueue.main.async { sp.stopAnimating() sp.removeFromSuperview() self.spinner = nil } } } In the Angular project, I’m using the plugin by manually registering it with registerPlugin from @capacitor/core. Specifically, in the service where I need it, I do the following: import { registerPlugin } from '@capacitor/core'; const RtspVlcPlugin: any = registerPlugin('RtspVlcPlugin'); After this, I try to call the methods defined in the iOS plugin, like RtspVlcPlugin.iniciar({ ... }), but I get an UNIMPLEMENTED error, which suggests that the plugin is not exposing its methods properly to the Angular/Capacitor environment. That makes me believe the problem lies in how the Swift file is integrated or registered, rather than how it is used from Angular. I’d appreciate any guidance on how to properly expose a Swift-based Capacitor plugin’s methods so that they are accessible from Angular. Is there any additional registration step or metadata I might be missing on the iOS side?

My Xcode project has the following configuration: 1 iOS app target 1 Xcode framework target (mach-o-type "Dynamic Library") 5 static libraries Dependencies: All the static libraries are target dependencies of the framework. The framework is the only target dependency of the iOS app. For the iOS app target, within the General tab > Frameworks, Libraries & Embedded content, I've set the framework as "Do not embed" So now I have a dynamic framework which won't be copied to the .app bundle in the build output. As per my understanding, this should result in a runtime error, dyld should not be able to find the framework files as they were not embedded in the final .app bundle. But regardless, my app runs without any errors, using all the methods exposed by the framework. What is the correct understanding here? What exactly does Embed/Do not embed mean (apart from excluding the files from .app bundle) When both settings are specified, is there any priority or precedence of one setting over the other?

Hi, my server in Melbourne Australia is getting weather forecasts from a few places around Australia. When I look at the daily timesteps that I get back, they might be something like this: "days": [ { "forecastStart": "2025-06-25T00:00:00Z", "forecastEnd": "2025-06-26T00:00:00Z", "daytimeForecast": { "forecastStart": "2025-06-25T07:00:00Z", "forecastEnd": "2025-06-25T19:00:00Z", "overnightForecast": { "forecastStart": "2025-06-25T19:00:00Z", "forecastEnd": "2025-06-26T07:00:00Z",} It doesn't matter where I ask for - Melbourne, Darwin, Perth, it always comes back the same. The documentation says that daytimeForecast is 7 am to 7 pm local and overnightForecast is 7pm to 7 am local. However, in a place like Perth 7-19Z is 3 pm to 3 am, not 7 pm to 7 am like advertised. I can see that for any given date, there are 3 maximum temperature forecasts, a 24 hour max, a daytime max and an overnight max and they differ from each other. Can anyone help me understand what's happening here? And furthermore in the example above, the 24 hour forecasts that have, for example this: "forecastStart": "2025-06-25T00:00:00Z" ... Can the 00:00:00Z be trusted literally? Or is it more the case that it's "2025-06-25" but the HMS got tacked on in a conversion?

Good day everyone. I have a react native app which works on dev mode on my device - Iphone 13 pro version: 18.5, but when deployed to TestFlight and installed on same device it crashes when ever I click on any TextInput. I downloaded the crash file but finding it difficult to pinpoint the problem. I want to know what the problem is, if it's related to an installed package or code base or any other. Any help will be appreciated!!! Thanks. crashlog.crash

I am working on a MAUI application. When I go to archive my build to then release it, my bundle is not including the Assets.car file that apple is seemingly expecting for handling the app icons, which is leading to issues trying to publish my app. The assets are in a AppIcon.appiconset folder in my project (under Platforms>iOS>Resources) with a proper Contents.json file also in there. They are setup as a BundledResource (also have tried ImageAssets for the build type but with the same issue occurring). I am using visual studio 2022 on Windows 11 paired with a Mac (Sequoia 15.5) and Xcode 16.4. I have even tried manually compiling the asset catalog from xcode16.4 and trying to use terminal commands to have actool create the Assets.car but that runs with no files created to the output destination as well as no errors. I believe there may be an issue with actools in my Xcode copy. I have tried uninstalling and reinstalling with no luck. Any suggestions or tips?

I developed (with AI help) using Xcode an app for myself. It logged certain places visited on a list, with photos and notes. It worked, but after a few days my iPhone can't launch it. What do I have to do to get this to last? I didn't think I needed to pay as this is purely for me.

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!

What happen when a deprecated method is used in project submitted to Apple Store Connect ? Generally the Apple documentation give the alternative like "Use ***: instead" but sometime the documentation do not suggest anything. What to do when a such Warning happen ?

It used to work for me (a few months, maybe a year ago). Right now when I run it there is no output (even though I granted it Bluetooth Capture permissions and have working RFCOMM communication in my program). Versions: PacketLogger 2024.03.18 (2024.03.18d1) Sequoia 15.4.1 M2 chip

I have added 2 command line tools in my swiftUI app for macOS, it was working fine locally, but it gives error when i try to make archive of it. I am not sure about the reason, but it was related to sandboxing the command line tools, after this i have tried multiple solutions but i am unable to resolve this issue, how should i handle the helper command line tools

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.