Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for

In iOS 18, TabView with .tabViewStyle(.sidebarAdaptable) introduced a powerful adaptive pattern — tabs in compact, sidebar in regular. However, the current Tab API only supports a title and an image (icon). There is no way to provide a trailing accessory view (e.g., a secondary icon or indicator) for sidebar rows. This is a meaningful gap in the API, because trailing accessories are a well-established pattern throughout UIKit and SwiftUI. Precedent in Apple's own design language Apple already supports trailing accessories in many analogous contexts: UITableViewCell / UICollectionViewListCell — support accessories (disclosure indicators, checkmarks, custom views) via UICellAccessory. UIListContentConfiguration — allows leading and trailing content in list rows. SwiftUI List rows — support Label, HStack with trailing elements, .badge(), and swipeActions. NavigationLink — automatically renders a disclosure chevron as a trailing accessory. UITabSidebarItem (UIKit, iOS 18) — supports configuratio

Hi everyone, I would like to know how I can get invite with a link to use testflight app. thanks

With the help of Claude and Codex, I've tried upgrading a screen magnification, capture, and pixel peeping app (SnoopX, from Stanford's software repository) to be HDR-aware. For images that are truly HDR (displayed in Apple Photos, Google Photos in Chrome, or Mac Preview), and on an HDR monitor with plenty of EDR headroom (Apple XDR display), I should see pixel values well above 1.0. Apple's Digital Color Meter does. However, my app does not. I think the code is doing all the right things with ScreenCaptureKit, but it never returns values above 1.0. Has anybody gotten this to work? Here is what Codex says about the code it helped me build in my app: • Set captureDynamicRange: We set config.captureDynamicRange = SCCaptureDynamicRangeHDRLocalDisplay (when available). Note: Gemini’s SCCaptureModeHDRLocalDisplay isn’t a real symbol — the actual API is SCCaptureDynamicRange. • Use preset: We try initWithPreset: SCStreamConfigurationPresetCaptureHDRStreamLocalDisplay, but your runtime crashes on initWithPr

We have been using this API call to set the In-App Provisioning capability for 2+ years and it just recently started returning errors. To set the In-App Provisioning capability we had been using the App Store Connect API directly: curl https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities -X POST --header Authorization: Bearer #{appleApiToken} --header Content-Type: application/json -d '{data: {type: bundleIdCapabilities, attributes: {capabilityType: IN_APP_PASS_PROVISIONING}, relationships: {bundleId: {data: {id: #{appStoreBundleIdentifier}, type: bundleIds}}}}}' The IN_APP_PASS_PROVISIONING capability type is shown, by getting the bundle ID capabilities, when In-App Provisioning is set on a bundle ID: curl https://api.appstoreconnect.apple.com/v1/bundleIds/#{appStoreBundleIdentifier}/bundleIdCapabilities --header Authorization: Bearer #{appleApiToken} After manually setting the In-App Provisioning capability via the Apple Developer portal you will see the new capabilityType: { type : bundleIdCapabi

On our public Apple account we have distribution certificates that work for all Apple platforms. On our Enterprise account it will only generate iOS distribution certificates. Apple support did not provide any concrete solutions, only pointing us to the general docs. Any suggestions?

Hello, We are facing an issue with performing a DTLS handshake when our iOS application is in the background. Our app (Vocera Collaboration Suite – VCS) uses secure DTLS-encrypted communication for incoming VoIP calls. Problem Summary: When the app is in the background and a VoIP PushKit notification arrives, we attempt to establish a DTLS handshake over our existing socket. However, the handshake consistently fails unless the app is already in the foreground. Once the app is foregrounded, the same DTLS handshake logic succeeds immediately. Key Questions: Is performing a DTLS handshake while the app is in the background technically supported by iOS? Or is this an OS-level limitation by design? If not supported, what is the Apple-recommended alternative to establish secure DTLS communication for VoIP flows without bringing the app to the foreground? Any guidance or clarification from Apple engineers or anyone who has solved a similar problem would be greatly appreciated. Thank you.

Hi everyone, I’m implementing subscriptions using StoreKit v2, and I’ve noticed a behavior change starting with iOS 26.1. I’d like to ask if anyone else has experienced the same issue. ■ Issue Immediately after purchasing a new subscription, the value of auto_renew_status (or autoRenewStatus) returned in the receipt is 0 (auto-renew OFF). This issue occurs on iOS 26.1. On iOS 26.0 and earlier, the same parameter returned 1 (auto-renew ON) right after purchase. Sometimes, after executing a “restore” operation, the value changes to 1 later. Since we’ve been using this parameter to determine whether a user’s subscription is active or not, the current behavior is causing some difficulties on our end. ■ Questions Has anyone else observed this issue (where autoRenewStatus is 0 immediately after purchase on iOS 26.1 or later)? How are you handling or working around this behavior in your implementation? If autoRenewStatus is unreliable, we’re considering determining the subscriptio

Hello everyone, I’m currently experiencing unusually long wait times for app reviews and wanted to check if others are seeing similar delays this week. Here is the current status of my submissions: App Store Update: Stuck in Waiting for Review much longer than the typical 24–48 hour window. New Version: A newly submitted version also seems to be stalled in the initial phase. TestFlight Processing: Even TestFlight builds are taking longer than usual to process. Expedited Review: I've attempted an expedited review request and direct communication, but the status remains unchanged so far. What’s confusing is that I see other apps in the same category receiving updates, so I’m unsure if this is a localized technical glitch or a broader delay affecting a specific group of developers. I’m not looking to escalate anything just yet; I’m simply trying to gauge if this is a widespread issue at the moment. I would greatly appreciate any insights into your recent experiences or if you've noticed similar patterns

Hi, After the release of macOS Tahoe 26.2. We are seeing memory leaks if our Network Protection Extension is used alongside the Apple Built In Firewall, a second Security Solution that does Network Protection and a VPN. Our NEXT, socketfilterfw and the other security solution consume instead of a few MB of Memory now multiple Gigabytes of Memory. This issue started with the public release of macOS Tahoe 26.2, this issue was not present in earlier versions of macOS and the same set of Software. Just testing our solution by itself will not show this behavior. I unfortunately can't try to reproduce the issue on my test device that runs the latest 26.3 beta as I do not have the third party software installed there and I can't get it. Our Network extension implements depending on the license and enabled features: NEFilterDataProvider NEDNSProxyProvider NETransparentProxyProvider For all man in the middle Use Cases we are using Network Framework, to communicate with the peers. And leaks suggest th

Hello, guys. I am going through a situation in which an open validation appears in the system/developer mode and I would like to understand better if this is something normal in this process. Could someone confirm if this type of validation is expected at this stage? I would also like to know what criteria I can observe to be sure that it is legitimate and that I can trust the activation. Thank you in advance for your attention and help. Thank you