Overview

In the official explanation, "deployment targets" refers to "the OS range supported by this version of Xcode for uploading apps to App Store Connect." On the Xcode Support page (https://developer.apple.com/support/xcode/), I can find the deployment targets supported by each Xcode version. My question is: can I use a newer version of Xcode to build an IPA with an older deployment target that isn’t listed? For example, can I use Xcode 26 to build an iOS 12 IPA (just build, not debug)? In my opinion, since the new SDKs still contain many old macros restricted to earlier iOS versions, it should be possible, but I’m not sure if that’s correct. Thanks.

Hi all, I have set up a trivial test project to try Apple-hosted background assets following the instructions in the three articles at https://developer.apple.com/documentation/backgroundassets. When I run the local mock server with xcrun ba-serve and set the URL override in Settings as described in the "Testing asset packs locally" article, I am able to download a test pack on my iOS devices. On the Mac that I use to run the mock server, however, the same call to AssetPackManager.shared.assetPack(withID: "TestAssetPack") that works on iOS always reports The asset pack with the ID “TestAssetPack” couldn’t be looked up: No asset pack with the ID “TestAssetPack” was found. even when not running the mock server, which led me to believe that it may not be hitting it at all. In fact, the macOS app will download asset packs uploaded to App Store Connect even when running the local server and setting the xcrun ba-serve url-override to the exact same string as in Settings on iOS. My initial suspicion was that something is wrong with the URL override, so I have tried all combinations of the Mac's hostname, IP address or "localhost" (with the corresponding SSL certificates) with and without port 443, always prefixing with "https://" for the url-override. All the same. Does anyone have an idea what may be the issue here? My asset pack has the following manifest: { "assetPackID": "TestAssetPack", "downloadPolicy": { "onDemand": {} }, "fileSelectors": [ { "file": "TestAsset.txt" } ], "platforms": [ "iOS", "macOS" ] } I am running v26.1 for macOS, iOS & Xcode. Edit: Just to be clear, my assumption here is that the URL overrides (in Settings on iOS or via ba-serve on macOS) is what should cause the app to hit the mock server. Is that correct or am I missing something?

I am trying to create a new app using IOS-26.1, macOS Tahoe 26.1 and Xcode 26.1 with Swift6. Is this a bug that is going to be addressed. This is in the Debug Console...Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) ( "<NSAutoresizingMaskLayoutConstraint:0x10bb18870 h=--& v=--& _TtCC5UIKit19NavigationButtonBar15ItemWrapperView:0x115da48c0.width == 0 (active)>", "<NSLayoutConstraint:0x115ac2ee0 _TtCC5UIKit19NavigationButtonBar15ItemWrapperView:0x115da48c0.leading == _UIButtonBarButton:0x115d40c80.leading (active)>", "<NSLayoutConstraint:0x115ac30c0 H:[_UIButtonBarButton:0x115d40c80]-(0)-| (active, names: '|':_TtCC5UIKit19NavigationButtonBar15ItemWrapperView:0x115da48c0 )>", "<NSLayoutConstraint:0x115ac2df0 'TB_Leading_Leading' H:|-(12)-[_UIModernBarButton:0x115d20a80] (active, names: '|':_UIButtonBarButton:0x115d40c80 )>", "<NSLayoutConstraint:0x115ac2fd0 'TB_Trailing_Trailing' H:[_UIModernBarButton:0x115d20a80]-(12)-| (active, names: '|':_UIButtonBarButton:0x115d40c80 )>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x115ac2fd0 'TB_Trailing_Trailing' H:[_UIModernBarButton:0x115d20a80]-(12)-| (active, names: '|':_UIButtonBarButton:0x115d40c80 )> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful.

When I tap on one of the buttons in the ShieldAction extension I want to close the shield and open the parent app instead of the shielded app. Is there any way of doing this using the Screen Time API? class ShieldActionExtension: ShieldActionDelegate {      override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) {     // Handle the action as needed.           let store = ManagedSettingsStore()               switch action {     case .primaryButtonPressed:       //TODO - open parent app       completionHandler(.defer)     case .secondaryButtonPressed:       //remove shield       store.shield.applications?.remove(application)       completionHandler(.defer)         @unknown default:       fatalError()     }   }   }

(I truly appreciate all the responses you all have written for me :bow: ) I was under the assumption that for Live Activity, in order for you to be able to update the Activity, you need an update token. And for the OS to issue you the update token, user must hit the "Allow" from the lock screen. However based on these screenshots it seems that you don't need to hit "Allow" to be able to update the Live Activity. Live Activity was updated — even without the user hitting "Allow" So now I'm wondering if: Is hitting Allow required for the update token to get issued? Or that assumption is incorrect? In our tests (when connected to Proxyman, the OS emits the update token after user hits "Allow" / "Always Allow") If you don't hit allow, are there alternate ways to update the Live Activity without having the update token? I'm guessing you could set a short stale time and then when the OS launches the app in the background you query the server and then update the Live Activity. Is that a worthy approach? I also noticed that the "The Philly Inquirer" App has 'Background App Refresh" enabled, but this happened in 2 minutes. In our architecture assessments, after reviewing Apple's docs on 'Background Processing", we didn't think of it as a viable option, because it can't guarantee if the OS is given time in the next 2 minutes or 10 hours later when the phone is getting charged again. Are any of these workarounds viable or are there alternate approaches? Our requirement is: be able to use Live Activity between 2-72hrs after app install. (I mention this because perhaps Apple may impost some restrictions for new installs) be able to update an active Live Activity within 1-2 minutes after it has began.

Sidebars for mac Catalyst apps running with UIDesignRequiresCompatibility flag render their active items with a white bg tint – resulting in labels and icons being not visible. mac OS Tahoe 26.1 Beta 3 (25B5062e) FB20765036 Example (Apple Developer App):

I am trying to migrate an app to use Network framework for p2p connection. I came across this great article for migrating to Network framework however this doesnt use the new structured concurrency. This being introduced with iOS 26, there doesnt seem to be any sample code available on how to use the new classes. I am particularly interested in code samples showing how to add TLS with PSK encryption support and handling of switching between Wifi and peer to peer interface with the new structured concurrency supported classes. Are there any good resources I can refer on this other than the WWDC video?

Previously I was able to "snapshot" view that were not part of any window hierarchy using the following: NSImage *buttonImage = [NSImage imageWithSystemSymbolName:@"49.circle.fill" accessibilityDescription:nil]; NSButton *aButton = [NSButton buttonWithImage:buttonImage target:nil action:nil]; [aButton sizeToFit]; NSBitmapImageRep *rep = [aButton bitmapImageRepForCachingDisplayInRect:aButton.bounds]; if (rep == nil) { NSLog(@"Failed to get bitmap image rep."); return; } [aButton cacheDisplayInRect:aButton.bounds toBitmapImageRep:rep]; NSData *tiffData = rep.TIFFRepresentation; NSImage *snapShotOfImage = [[NSImage alloc]initWithData:tiffData]; Now on macOS Tahoe I get a non nil image, but the image is blank. However if I add aButton NSWindow's view hiearchy just before the call to -cacheDisplayInRect:toBitmapImageRep: I do get a proper image. Is this behavior intended or is this considered a bug? Is it documented anywhere that a view must be in a NSWindow for -cacheDisplayInRect:toBitmapImageRep: to work? Thanks

My app (FindAnyFile) provides a Finder-like interface in which it also offers a QuickLook preview command, which invokes [[QLPreviewPanel sharedPreviewPanel] makeKeyAndOrderFront:nil]; Now, if it shows .abcdp files, it often, but not always, crashes. This has been happening for many macOS versions, at least since 10.15, up to 26.1. Also, it does not seem to matter which SDK/Xcode I build with, as I used several and all versions lead to the crash. The issue rather appears to be inside the QLplugin for the AB file (ABCardCollectionView etc.). I am able to trace this crash in Xcode. There are a LOT of errors and warnings coming up, and eventually the qlplugin throws an ObjC exception which in turn brings down my entire app (and here I thought that the XPC system was designed to expressly avoid such crashes). Possibly significant errors are: CNAccountCollectionUpdateWatcher 0x6000025cf800: Update event received, but store registration failed. This event will be handled, but the behavior is undefined. Error using remote object proxy when fetchAnonymousXPCEndpoint: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller" UserInfo={NSDebugDescription=connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller} connection to service named com.apple.coreduetd.people … CNPropertyNotFetchedException: A property was not requested when contact was fetched. I've attached the (mostly) complete console output from such a debug run. I have also an open bug report regarding this kind of crash (back then I was not able to reproduce it myself): FB15553847 Also, when I "Quick Look" the same file in Finder, I get a "Preview not permitted" for the same items that crash in my app. If I copy the same items to the Desktop, then Finder can QL them and my app doesn't crash when viewing the item on the Desktop. So, the crash only happens with the items inside ~/Library/Application Support/AddressBook/Sources/…/Metadata/. Now, here is the weirdest part: You might think: So, if the Finder shows "Preview not permitted", then my app trying to view those items is the result of that condition (even if that's not supposed to crash). However: I have a clean 26.1 install (in an Apple ARM VM) where Finder also says "Preview not permitted" for these items in the user's Library/AB/Metadata folder, but my app can QL those items without crashing! Also, I have one user who uses 26.1 and gets the crash with files in the same location. So, the "Preview not permitted" is probably not the cause of this crash, though it's suspicious that a user gets this at all - why can't a user QL the abcdp files in the Metadata folder but when copied to the Desktop, QL works? You'd think that Finder has the necessary entitlements to access the AB, or doesn't it? Of course, my app has permission enabled under Privacy & Security / Contacts (if it's disabled, then the app can't show anything but will also not crash). And it has the "Address Book" entitlement. Would be nice if this could be looked into and eventually be fixed. Alternatively, I'd welcome any suggestions on how to prevent my app from crashing if the qlplugin throws. But if you look at the stack trace you'll see that there's no method of my own app involved where I could insert an exception catcher. I added code to my previewItemURL delegate method to make sure the NSURL item is readable, and it is, even Of course, apart from the issue with .abcdp files, the QL operation in my app works flawlessly, i.e. I have never received any other crash reports relating to any other QL plugins. QuickLook for AddressBook crash messages

Hi, I developed a Platform Single Sign-On extension and a corresponding extension for my IdP, which is Keycloak based. The code for both projects are here: https://github.com/unioslo/keycloak-psso-extension and https://github.com/unioslo/weblogin-mac-sso-extension I realized that, when using the Secure Enclave as the AuthenticationMethod, and according to Apple's documentation, the Extension doesn’t obtain fresh ID Tokens when they expire if the refresh token is still valid. When using password as the Authentication Method, it fetches new ID tokens when they expire, without prompting the user for credentials, by using the refresh token. My suggestion is that the same behavior should be implemented for Secure Enclave keys. The thing here is that usually, on OIDC flows, the ID/Access tokens are short-lived. It would make sense for the extension to provide fresh ID tokens. It doesn’t seem to make sense for me that, when using passwords, the extension would fetch these tokens, and not when having the Secure Enclave key. By not doing this, Apple almost forces the developer of an extension to fetch new ID tokens themselves, which doens’t make sense when it clearly provides fresh tokens when using passwords. It almost forces the developers to either implement that logic themselves, or to issue longer tokens, which is not so nice. How so you deal with this? Do you simply use the refresh token as an authentication token, or do you do some sort of manual refresh on the extension?

Hi, I am trying to add a custom (create) button next to the automatic "toggle sidebar" button in a NavigationSplitView. When the sidebar is collapsed that button should be displayed in a group with that automatic toggle button. Basically I want exact the same behaviour as in the Apple "Reminders" App. How could I archive that? Thanks for your help :-) Jan

On macOS Tahoe 26 activating GUI apps from command-line often fails. It launches the app but not brings to the foreground as expected. For example, running the following commands in Terminal is expected to launch Pages and bring it to the foreground. open /Applications/Pages.app or osascript -e `tell application "Pages" to activate` Moreover, they sometimes not return in Terminal. These commands worked as expected until macOS 15 but no more in macOS 26. The tricky part is that this failure doesn't happen 100% of the time; it occurs randomly. However, since multiple users of my app have reported the same symptoms, and I can reproduce it not only with my app but also with apps bundled to macOS, I don't believe this is an issue specific to my environment alone. I’ve already filed this issue: FB21087054 Open version: https://github.com/1024jp/AppleFeedback/issues/87 However, I’d like to know if any workaround exists or my understanding is wrong, especially for case with osascript.

When I try to get a new API Key I get the following error. "API Keys cannot be created due to an invalid Program License Agreement. Please update this agreement and try your request again." I have been to the agreement section, and it says: "Issued October 8, 2025. Accepted November 19, 2025." Any idea why I still get this error?? Not sure if that makes a difference. I had a paid account, but I didn't renew it because I don't need it anymore, and I was told that I can still use this account for free for app testing.

Hello, I’m experiencing an issue with StoreKit 2 when passing a new appAccountToken for each purchase request. Case-ID: 15948169 (for DTS reference) Description of the Problem When initiating a purchase, I generate a new UUID to use as the appAccountToken: let serverTransactionId = UUID() let options: Set<Product.PurchaseOption> = [ .appAccountToken(serverTransactionId) ] let result = try await product.purchase(options: options) Expected Behavior: Each new purchase should return the updated appAccountToken that I pass into the purchase options. Actual Behavior: The payload response after success always contains the same appAccountToken from the very first transaction. It ignores subsequent UUIDs I pass and keeps reusing the original one. This causes issues because the same identifier is being reused across multiple transactions, making it difficult to map purchases to the correct user session. Steps to Reproduce Generate a fresh UUID using UUID(). Pass it as .appAccountToken when calling purchase(). Complete the transaction in the sandbox environment. Inspect the payload response → The appAccountToken value is always the same as the first one used, not the newly provided one. Additional Info I do have a focused test project that reproduces this issue. The issue appears specific to appAccountToken persistence across multiple transactions. Has anyone else experienced this behavior with StoreKit 2? Is this expected (Apple caching the first token) or could this be a bug?

Hello, I would like to clarify how link association and app-opening preferences work in iOS, specifically when a user opens a URL in a browser that can be handled by an installed application. I have noticed the following behavior: When a user taps a URL that can be opened by an app, iOS sometimes asks whether to open the link in the app or continue in the browser. After choosing an option once (for example, "Open in App" or "Stay in Browser"), it seems that this preference becomes persistent. Even after deleting the application and reinstalling it, the browser (Safari or third-party browsers) sometimes continues to open the link directly in the browser without asking the user again. In some cases, it appears impossible to reset or clear this association, and the user is not prompted again to choose how the link should be opened. My questions are: How exactly does iOS store link-handling preferences between apps and browsers? Are these preferences saved on the system level, inside Safari, or associated with the app installation itself? Is there a way for a user to manually reset or clear these link-opening associations? Should deleting and reinstalling the app reset these preferences, or is the behavior expected to persist? Is this behavior different for Universal Links, App Clips, or for regular URL scheme associations? This situation is important for us because it affects user experience, and at the moment it is difficult to understand or reproduce the internal logic behind these link associations. Thank you in advance for your clarification.

Is foundation models matured enough to take input from the Apple Vision framework to generate responses? Something similar to what google's gemini does although in a much smaller scale and for a very specific niche.

Hi, After enabling the new Enhanced Security capability in Xcode 26, I’m seeing install failures on devices running < iOS 26. Deployment target: iOS 15.0 Capability: Enhanced Security (added via Signing & Capabilities tab) Building to iOS 18 device error - Unable to Install ...Please ensure sure that your app is signed by a valid provisioning profile. It works fine on iOS 26 devices. I’d like to confirm Apple’s intent here: Is this capability formally supported only on iOS 26 and later, and therefore incompatible with earlier OS versions? Or should older systems ignore the entitlement, meaning this behavior might be a bug?

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?

Hi, We have several Apps that use CEF internally for real-time offscreen HTML rendering. Specifically, we have a framework with an embedded XPC service that itself uses CEF to render HTML and sends the resulting IOSurface back to the host App via XPC for rendering in a Metal pipeline. So far our Apps have only been available as a direct download, but recently we have been trying to submit one of them to the MAS and have run into several issues, CEF being one of them. The core of the issue seems to be that submission to the MAS requires that all executables, including XPC services, be signed with the sandbox entitlement. After enabling the sandbox on the host App, my XPC service with CEF continued to function as before. However, after signing the XPC service with the sandbox entitlement, it stopped working. After some research, it seems that the issue here is that the XPC service once signed with the entitlement is running in its own sandbox, and because CEF uses global Mach ports for internal communication, this then fails. Further, I have read from other developers that even if these issues are overcome by e.g. modifying CEF, they have been rejected by the review team because CEF uses some private API calls. So my question is, does anyone have concrete information on whether or not it will be possible to successfully submit an App using CEF in this way (App > Framework > XPC > CEF) for publication on the MAS? Further, as an alternative I have been looking at WebKit, specifically WKWebView and calling "takeSnapshot", as this seems to be the only documented way to retrieve pixels. However, it seems that this method is not designed for real-time rendering. Assuming that CEF is a non-starter for the MAS, is there anything specific that Apple recommends for real-time offscreen HTML rendering? Cheers, Dave Lincoln

I have an iOS/iPadOS app and 'm trying to communicate with usb smart card reader using CryptoTokenKit on all platforms (ios/ipados/macos). Minimal Repro Code import CryptoTokenKit import SwiftUI struct ContentView: View { @State var status = "" var body: some View { VStack { Text("Status: \(status)") } .padding() .onAppear { let manager = TKSmartCardSlotManager.default if manager != nil { status = "Initialized" } else { status = "Unsupported" } } } } And my entitlement file has only one key: com.apple.security.smartcard = YES Behavior • iPadOS (on device): status = "Initialized" ✅ • macOS (native macOS app, with the required CryptoTokenKit entitlement): status = "Initialized" ✅ • macOS (Designed for iPad, regardless of CryptoTokenKit entitlement): status = "Unsupported" → TKSmartCardSlotManager.default is nil ❌ Expectation Given that the same iPadOS build initializes TKSmartCardSlotManager, I expected the iPad app running in Designed for iPad mode on Apple silicon Mac to behave the same (or to have a documented limitation). Questions Is CryptoTokenKit (and specifically TKSmartCardSlotManager) supported for iPad apps running on Mac in Designed for iPad mode? If support exists, what entitlements / capabilities are required for USB smart-card access in this configuration? If not supported, is Mac Catalyst the correct/only path on macOS to access USB smart-card readers via CryptoTokenKit? Are there recommended alternatives for iPad apps on Mac (Designed for iPad) to communicate with USB smart-card readers (e.g., ExternalAccessory, DriverKit, etc.), or is this scenario intentionally unsupported? Thanks!