App Icon created with Icon Composer is empty for visionOS app We are developing a universal app, and the app’s icon was created using Icon Composer. Xcode 26, RC visionOS 26 and visionOS 2.5 App Icons on macOS, iOS, and iPadOS are correct We have archived the app for macOS and iOS and successfully uploaded it to the App Store. This strongly suggests that the App Icon configuration in our project settings is correct for these platforms. App Icon issue on visionOS However, the visionOS app icon is not working as expected: When testing on the Vision Pro simulator (versions 2.x and 26.0), the app icon appears empty. When archiving and submitting to the App Store, the process fails with the following error: The app’s Info.plist file is missing the CFBundleIcons.CFBundlePrimaryIcon key for the visionOS App Icon. This suggests that the project’s App Icon settings may not be correctly applied for visionOS builds. Request for assistance We are preparing to release our app, one of the first to support Liquid Glass, and would greatly appreciate guidance on how to resolve this issue with the visionOS app icon. FB20184218

I can see that iOS beta 2 was released yesterday. I'm not running the beta yet on my actual iPhone, but I wanted to see if an issue I reported in beta 1 was fixed. Is there a way to update my iOS 26 simulator for beta 2? Usually, there's a new Xcode download that includes the new simulator, but it looks like the most recent Xcode beta release was June 9.

Q. Is there a plan to finally document the PackageInfo file format used in .pkg flat package? The man page for pkgbuild is not really useful to understand the different options. It does not seem to make sense to have an official documentation for the Distribution Definition file but not for the PackageInfo file.

I am building an iOS app with the App ID: com.echo.eyes.app I have a paid Apple Developer membership and have followed all correct procedures, including: Adding com.apple.developer.speech-recognition manually to the App.entitlements file Setting Info.plist keys for microphone and speech permissions Assigning my Apple Developer Team to the project Setting App/App.entitlements under Code Signing Entitlements Despite all this, Xcode automatic signing fails, and I receive the error: vbnet Copy Edit Provisioning profile 'iOS Team Provisioning Profile: com.echo.eyes.app' doesn't include the com.apple.developer.speech-recognition entitlement. I am unable to add the entitlement via the Capabilities section, and no method I try will allow provisioning to succeed. Please update this App ID to include the required entitlement in the provisioning profile. This issue is preventing all voice recognition functionality. Thank you.

In the archived documentation for Distribution Definition files (https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html), the allowed-os-versions and os-version element are partially documented. I have a few questions about these elements: allowed-os-versions The documentation states: Availability: Available in OS X v10.6.6 and later. Has this element always worked correctly in the past? I'm asking because it does not seem to work correctly on OS X v10.14 for the min attribute of a sub os-version element. os-version The documentation states: This element is designed for you to use a specific OS version number for the min attribute, and a major OS version number for the before attribute. The expectation is that you will know an exact minimum version but not an exact major version. This keeps you from having to guess the last minor revision before the next major revision, as you would have to do if the before attribute were inclusive. This is quite confusing because the documentation never explicitly says what a specific or major OS version number is. Is specific major.minor.patch or major.minor? What is major? major or major.minor? As the documentation was created at a time where the OS version scheme was: 10.minor.patch (and minor was actually the major) and we are now in an era where the OS version is major.minor.path, this is even more confusing. I would also be curious to know what the major version is officially supposed to be for macOS Tahoe in this case. 16 or 26? Generally speaking, this documentation is missing examples for a lot of the elements. Also why is there a tag for InstallerJS and not one for Installation in the Developer Forums?

My experience with Swift 6 strict concurrency so far doesn't match my understanding of implicit MainActor isolation semantics. This is a cross-post from StackOverflow. I will link answers between both forums. TL;DR Build succeeds when testing a struct declared in the test module, but fails when the struct is moved to the main module: Main actor-isolated property … cannot be accessed from outside the actor. Steps to reproduce Open up Xcode 26 beta 2 on macOS 26 (probably also ok on current stables). Create a new Swift app with Swift testing, no storage. Call it WhatTheSwift. Set the Swift Language Version on all three targets to Swift 6. Update the default test file to be this: import Testing @testable import WhatTheSwift struct WhatTheSwiftTests { @Test func example() async throws { let thing = Thing(foo: "bar") #expect(thing.foo == "bar") } } struct Thing { let foo: String } That should build fine, and the tests should pass. Now, move the Thing declaration into its own Thing.swift file in the WhatTheSwift module, and try running the test again. You should see this: Observations Marking the test @MainActor allows the test to pass, suggesting the compiler actually wants to isolate Thing.foo to the main actor. My question Why? And why only when Thing is in a different module?

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.

How can I get the macOS version from the Mac Catalyst version? We're building Info.plist files ourselves but we need a way to programatically (using shell scripts) derive the LSMinimumSystemVersion key needed from the iOS deployment target.

I try to distribute my App again, but receive now the error that the Minimum IOS is not supported by Info.plist with Runner. i have latest XCode and the error stays whatever IOS I Set in General and in the building rules. Any one has an idea or had same issue since recent Xcode / project Updates ? thanks so much

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?

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.

I am a solo developer building a cross-platform voice assistant app using Capacitor (with HTML, JS) and Xcode for the iOS version. The app is called "Echo Eyes," and it already functions well as a Progressive Web App (PWA). However, the iOS build has been completely blocked due to persistent sandbox permission errors from macOS during the CocoaPods framework embedding phase. This issue has caused severe disruption to my project and personal well-being, and I am writing to formally request assistance in identifying a clear solution. I am not a beginner and have followed all known best practices, forums, and Apple guidance without success. What I’ve Built So Far: Fully working PWA version of the app (voice input, HTML/JS interface) Capacitor initialized with ID: com.echo.eyes.voice Capacitor iOS platform added with CocoaPods App runs fine until Xcode reaches: [CP] Embed Pods Frameworks The Exact Problem: Sandbox: bash(12319) deny(1) file-read-data /Users/Shared/projects/Echo_Mobile/ios/App/Pods/Target Support Files/Pods-App/Pods-App-frameworks.sh Command PhaseScriptExecution failed with a nonzero exit code Clarification: This is not an HTML/JS issue. The failure occurs in Xcode long before web assets are embedded into the bundle. The shell script /Pods-App-frameworks.sh cannot be read due to macOS sandbox restrictions. Everything I’ve Tried: Gave Xcode and Terminal Full Disk Access Ran: sudo xattr -rd com.apple.quarantine on the entire Pods directory Added /bin/bash and /bin/sh to Full Disk Access (after confirming the exact shell via $SHELL) Attempted to disable Gatekeeper via Terminal: sudo spctl --master-disable (confirmed not effective without GUI toggle) Tried relocating project to /Users/Shared/projects/ Cleaned build folder, removed derived data, reinstalled pods Debugged shell usage with: echo "▶️ Embedding under shell: $SHELL" in the [CP] Embed Pods Frameworks script Attempted to grant shell access to Documents Folder, Desktop, and more via Files &amp; Folders Current State: Despite following all known and recommended steps, Xcode continues to return the same sandbox error. The shell script that embeds the CocoaPod frameworks is denied permission to read its own contents by macOS. What I Am Asking For: Is this a known issue in current versions of macOS or Xcode regarding sandbox denial for shell execution inside Pods? Is there a recommended method to grant /bin/bash or /bin/sh permission to read and run these scripts under Xcode without compromising system security? Is moving the project outside /Users (e.g. to /Projects) the only real workaround? Are there official Apple workarounds or entitlements available for developers encountering this? Personal Note: This issue has caused significant emotional and physical distress. I’m building this app as a personal healing tool and companion. I’ve poured months of work into this and done everything I can to follow Apple’s development guidelines. I’m not asking for hand-holding — only a clear, respectful response confirming whether this is expected behavior and what can be done to resolve it. Thank you for your time and understanding.

Hello, currently I am having trouble releasing an app because it crashes/does not launch on iOS 26.0.1. We have uploaded apps in the past so I tried building one of them with our current toolchain. I use Xcode 16.4, Kotlin version 2.0.0, LibGDX 1.13.1 and robovm/MobiVM 2.3.23. I uploaded the build to TestFlight and tested with physical devices running iOS 18.5 and 26.0.1. It runs fine on 18.5 but refuses to launch on the 26.0.1 device. I cannot retrieve a crash log or .ips file because none is written. When I write a Console log while the app crashes/does not launch I get no hints as to why it does so. Do you maybe have additional ideas as to why it keeps not launching on iOS 26.0.1?

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?

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?

So I can see from the documentation that XCTAssertEqual(x, y) becomes #expect(x == y), but what about XCTAssertEqual(x, y, accuracy: 0.2)? Does something already exist or do we need to write a more involved statement to see if x is less than y plus z and more than y minus z?

Hi Apple Engineers and fellow developers, I'm a student developer working on an educational focus management app that helps users hide distracting apps during study sessions. The app consists of: macOS app: Simple "Hide apps" button that triggers app hidding sessions iOS app: Uses Screen Time API to temporarily hide selected apps from home screen Communication: Bonjour networking between Mac and iPhone for session coordination The Challenge My app requires two entitlements that aren't available with Personal Developer Teams: com.apple.developer.family-controls (for Screen Time API) com.apple.developer.networking.multicast (for Bonjour device discovery) Current Error Messages text Cannot create a iOS App Development provisioning profile for "focuser.focuser-app". Personal development teams, including "My Name", do not support the Family Controls (Development) capability. Provisioning profile doesn't include the com.apple.developer.family-controls and com.apple.developer.networking.multicast entitlements. My Question for Apple Engineers Is there any legitimate way to test these privacy-sensitive APIs on my own devices for educational/learning purposes without purchasing the $99/year Apple Developer Program membership? I understand the security reasons behind these restrictions, but as a student just learning iOS development, it creates a significant barrier to experimenting with these technologies.

Does anyone know where I can get to the API diffs for iOS 18 -> iOS 26?

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

Hello, I've encountered unexpected behavior related to version information in our app logs, and I'd like to ask for some advice. We reviewed logs collected from a user running our app (currently available on the App Store). The logs are designed to include both the build number and the app version. Based on the build number in the logs, we believe the installed app version on the user's device is 1.0.3. However, the app version recorded in the logs is 1.1.5, which is the latest version currently available on the App Store. In our project, we set the app version using the MARKETING_VERSION environment variable. This value is configured via XcodeGen, and we define it in a YAML file. Under normal circumstances, the value defined in the YAML file (MARKETING_VERSION = 1.0.3) should be embedded in the app and reflected in the logs. But in this case, the version from the current App Store release (1.1.5) appears instead, which was unexpected. We'd like to know what might cause this behavior, and if there are any known factors that could lead to this. Also, is it possible that MARKETING_VERSION might somehow dynamically reflect the version currently available on the App Store? yaml: info.plist: