Hi, Our app (Tenkobo) received a rejection notice after review due to the fact that we use Gemini AI since 3 builds ago. Since then, we have been improving the disclosure of the data we collect, explicitly stating all the data, introducing a new feature that checks granular consent and syncs consent state for the user to the backend, and controls for whether to send to the Gemini API service for that feature depending on consent state for the user. Moreover, this feature is a premium add-on to a module that already does most things locally on the device and sends to our cloud infrastructure to allow storage and sync when users use multiple devices. It is a multi-platform app. However, despite every improvement, we keep getting the same Rejection reason that "The issues we identified still need your attention. I have asked for help or even that the rejection reason be more specific, but nothing. I have send pictures, and in this last rejection about 8 hours ago, I had to reply with a video showing that what they are asking for is already there. Why does the system work like this? It is frustrating, especially if a development team needs to be guessing how much is too much. We feel we are now close to removing the feature completely out of frustration, and it is very useful feature for our users based on the feedback we received from the android users (the android app has been live since about 6 weeks ago.) Please, what else can we do? We have requested a review meeting with App Review, the entire product plans are now on the verge of being irredeemably disrupted, and the company could go bankrupt just because our reviewer does not deem it fit to tell us exactly what they are expecting to see. Anyone with experience in this area should kindly provide some advise on what to do now. Thank you.

I have a desktop application developed in SwiftUI that shows property locations on the map. That's NOT the main feature. IF you give the application permission to access your location, the blue dot will appear on the map. If you don't, the blue user dot won't appear. That's the only difference with location services. In other words, the application has no use of user's current position beyond showing it on the map. Since it's just the matter of showing or not showing the blue dot on the map, the application doesn't really need to use the location service. Anyway, the reviewer is talking about something else by rejecting the application in two aspects. Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage Guideline 5.1.5 - Legal - Privacy - Location Services As I said earlier, the application only wants to show the blue dot on the map so that you can see your property locations relative to your current location. In code, it's something like the following. Map(position: $propertyViewModel.mapPosition) { ForEach(propertyViewModel.properties) { property in Annotation("", coordinate: CLLocationCoordinate2D(latitude: property.lat, longitude: property.lon)) { ... } } UserAnnotation() } So I'm hit with two rejection reasons with this one line. UserAnnotation() And the reviewer is talking about something like the app is not functional when Location Services are disabled. To resolve this issue, please revise the app so that the app is fully functional without requiring the user to enable Location Services. Well, I can remove the UserAnnotation() line if I want to put this application through the review process. Nothing will become dysfunctional, though, if you decide to reject permission request. So would you remove it or would you play along with this reviewer if you were me? It's been three or four days since rejection. As you can imagine, the reviewer doesn't bother to answer as to What are the exact coordinates that the application has allegedly collected What won't work as a result of location permission request refusal. This isn't the first time I get my app rejected. I've probably had 150 to 200 of them rejected in the past 15 years. And just because a reviewer rejects your app for a bizarre reason, would you give in? Remove this feature and that feature because the reviewer is incompetent such that he or she makes his or her decision based on imagination? What do you think?

Our app (Tenkobo) received a rejection notice after review due to the fact that we use Gemini AI since 3 builds ago. Since then, we have been improving the disclosure of the data we collect, explicitly stating all the data, introducing a new feature that checks granular consent and syncs consent state for the user to the backend, and controls for whether to send to the Gemini API service for that feature depending on consent state for the user. Moreover, this feature is a premium add-on to a module that already does most things locally on the device and sends to our cloud infrastructure to allow storage and sync when users use multiple devices. It is a multi-platform app. However, despite every improvement, we keep getting the same Rejection reason that " ... Review Device: iPad Air 11-inch (M3) ... The issues we previously identified still need your attention. Guidelines 5.1.1(i) - Legal - Privacy - Data Collection and 5.1.2(i) - Legal - Privacy - Data Use The app appears to share the user’s personal data with a third-party AI service but the app does not clearly explain what data is sent, identify who the data is sent to, and ask the user’s permission before sharing the data. Apps may only use, transmit, or share personal data after they meet all of the following requirements: Disclose what data will be sent Specify who the data is sent to Obtain the user’s permission before sending data Identify in the privacy policy what data the app collects, how it collects that data, all uses of that data, and confirm any third party the app shares data with provides the same or equal protection Next Steps Revise the app to explain what data is sent, identify who the data is sent to, and ask the user’s permission before sharing personal data with a third-party AI service. If it does not already, the app’s privacy policy must also identify what data the app collects, how it collects that data, and all uses of that data, including if it is shared with a third-party AI service. " I have asked for help or even that the rejection reason be more specific, but nothing. I have send pictures, and in this last rejection about 8 hours ago, I had to reply with a video showing that what they are asking for is already there. Please, what else can we do? We have requested a review meeting with App Review, the entire product plans are now on the verge of being irredeemably disrupted, and the company could go bankrupt just because our reviewer does not deem it fit to tell us exactly what they are expecting to see. Anyone with experience in this area should kindly provide some advise on what to do now. Thank you.

I have a desktop application that shows some real estate properties chosen by the user. The application shows those GPP locations on the map. The SwiftUI code is something like the following. import SwiftUI import MapKit struct ContentView: View { var body: some View ZStack { mapView } } private var mapView: some View { Map(position: $propertyViewModel.mapPosition) { ForEach(propertyViewModel.properties) { property in Annotation("", coordinate: CLLocationCoordinate2D(latitude: property.lat, longitude: property.lon)) { Button { } label: { VStack { Image(systemName: "house.circle.fill") .resizable() .scaledToFit() .frame(width: 48) .foregroundStyle(colorScheme == .light ? .white : .black) ... } } .buttonStyle(.borderless) } } UserAnnotation() } .mapControls { MapUserLocationButton() } .mapControlVisibility(.visible) .onAppear { CLLocationManager().requestWhenInUseAuthorization() } } } The application only wants to use the CLLocationManager class so that it can show those locations on the map relative to your current GPS position. And I'm hit with two review rejections. Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage Issue Description One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Guideline 5.1.5 - Legal - Privacy - Location Services The app uses location data for features that are not relevant to a user's location. Specifically, the app is not functional when Location Services are disabled. So I wonder if the application is even required to have 'NSLocationWhenInUseUsageDescription' and/or 'NSLocationUsageDescription'? just in order to show user's current location so that they can see property locations relative to it? The exact location privacy statement is the following. The application needs your permission in accessing your current location so that it will appear on the map

We are having an issue with the Local Network permission pop-up not getting triggered for our apps that need to communicate with devices via local network interfaces/addresses. As we understand, apps using UDP should trigger this, causing macOS to prompt for access, or, if denied, fail to connect. However, we are facing issues with macOS not prompting this popup at all. Here are important and related points: Our application is packaged as a .app package and distributed independently (not on the App Store). The application controls hardware that we manufacture. In order to find the hardware on the network, we send a UDP broadcast with a message for our hardware on the local network, and the hardware responds with a message back. However, the popup (to ask for permission) never shows up. The application is not able to find the hardware device. It is interesting to note that data is still sent out to the network (without the popup) but we receive back the wrong data. The behaviour is consistent macOS Sequoia (and above) with both Apple And Intel silicon. Workarounds that have been tried: Manual Authorization: One solution suggested in various blogs was to go to "Settings → Privacy and Security-> Local network", find your application and grant access. However, the application never shows up in the list here. Firewall: No difference is seen in behaviour with firewall being ON OR OFF. Setting NSLocalNetworkUsageDescription: We have also tried setting the Info.plist adding the NSLocalNetworkUsageDescription with a meaningful string and updating the NSBonjourServices. Running Via terminal (WORKS): Running the application via terminal sees no issues. The application runs correctly and is able to send UDP and receive correct data (and find the devices on the network). But this is not an appropriate solution. How can we get this bug/issue fixed in macOS Sequoia (and above)? Are there any other solutions/workarounds that we can try on our end?

We're trying to implement Cross-domain session check for SSO by making CORS request. is Intelligent Tracking Prevention blocks all cookies in CORS requests? I saw all cookies are blocked in CORS requests. We are not able to check the auth session in source domain. Are there anyway to bypass this without user interaction? benefitier.com -> source.com

I just spend the morning debugging LocationButton and the associated CLLocationManagerDelegate only to realise that it works perfectly in iOS 18.5 but no longer works for me in iOS 26.0, 26.2 or 26.2.1 (the latter on-device). It does work when I run my app on macOS 26.2 (Designed for iPad). Is there a change in behaviour or requirements on iOS I am missing? On iOS 18.5 I observe that the authorisation status changes from .notDetermined to .authorizedWhenInUse after the LocationButton has been tapped and my delegate is able to obtain the location through locationManager(_ , didUpdateLocations:). On iOS 26.x the authorisation status remains .notDetermined and my delegate receives locationManager(_:didFailWithError:) with error code .denied. Setting NSLocationWhenInUseUsageDescription in my Info.plistdid not help. Just in case ;) FB21798098 (SwiftUI LocationButton fails to acquire authorization on iOS 26)

Hello App Review Team, I am writing to seek clarification regarding repeated review feedback received via App Store Connect (Resolution Center) for my app: App Name: Animal Sounds & Insects 90+ App ID: 6741077718 Team ID: 24MTF8NJ6Q Over the past two weeks, this app update has remained in review with multiple rejections referencing similar concerns, despite detailed responses and clarifications already provided in the Resolution Center. Unfortunately, I have not received follow-up responses or specific guidance there, which has prevented me from releasing even a minor update. To ensure clarity and avoid further delays, I am summarizing the key points below. Parental Gate (Guideline 1.3 – Kids Category) The review feedback indicates that the app may include links, commerce, or ad interactions without parental permission. I would like to clarify that the app implements a mandatory, non-dismissible parental gate, which is required before: Opening any external links Engaging in any form of commerce, including in-app purchases Interacting with any advertisements This parental gate cannot be bypassed or disabled and is triggered consistently across all applicable user flows. No child user can access links, purchases, or ad interactions without successfully completing the parental gate. If there is a specific screen, flow, or scenario where this behavior was interpreted differently during review, I would greatly appreciate precise details so I can verify and address it immediately. Advertising Experience (Guideline 4.0 – Design) The review also notes that users are required to view advertisements prior to using the app. I would like to clarify that the app does not require users to view advertisements before accessing its core functionality. Specifically: There are no forced ads No launch or entry interstitials No ads that block or gate access to the app’s main features Advertising within the app is passive and non-intrusive. This setup has been live for over one year, and no recent changes were introduced that would alter this behavior. Request for Guidance I fully respect and support the App Review Guidelines and am committed to complying with them. Given the repeated rejections and lack of actionable feedback so far, I kindly request: Clear and specific guidance on the exact screen, flow, or behavior being flagged Confirmation on whether the current parental gate implementation is being detected correctly during review My goal is to resolve any remaining concerns as quickly and accurately as possible so the review process can move forward. Thank you very much for your time and support. I appreciate the work of the App Review team and look forward to your guidance. Kind regards, Jiyan Aslan Developer, Animal Sounds & Insects 90+

My application needs local network access. When it is started for the first time, the user gets a prompt to enable local network access (as expected). The application is then shown as enabled in Privacy & Security / Local Network and local network access is working. If macOS is then shutdown and restarted, local network access is blocked for the application even though it is still shown as enabled in Privacy & Security / Local Network. Local network access can be restored either by toggling permission off and on in Privacy & Security / Local Network or by disabling and enabling Wi-Fi. This behaviour is consistent on Sequoia 15.1. It happens sometimes on 15.0 and 15.0.1 but not every time. Is my application doing something wrong or is this a Sequoia issue? If it is a Sequoia issue, is there some change I can make to my application to work around it?

https://developer.apple.com/news/?id=j9zukcr6 starting from Jan 2026 there is change in requirements for account notifications for Sign in with Apple. Does this apply only to developers based in South Korea or all apps which are avai via the korean App Store?

We have a very strange issue that I am trying to solve or find the best practice for. We have a SwiftUI View that uses the Camera to preview. So as suggested in Apples Docs we check authorisation status and then if it's not determined we request authorisation. We also have the privacy entry in the info.plist case .notDetermined: AVCaptureDevice.requestAccess(for: .video) { accessStatusAuthorised in if !accessStatusAuthorised { self.cameraStatus = .notAuthorised } else { self.isAuthorized = true self.cameraStatus = .authorised self.startCameraSession(cameraPosition: cameraPosition) } } case .restricted: cameraStatus = .notAuthorised isAuthorized = false case .denied: cameraStatus = .notAuthorised isAuthorized = false case .authorized: cameraStatus = .authorised isAuthorized = true startCameraSession(cameraPosition: cameraPosition) break @unknown default: isAuthorized = true cameraStatus = .notAuthorised } However when we call this code it freezes the Camera feed, even when allow has been tapped. However and this is the confusing part. If we do not call the code above, we still get the permission for camera access pop up and the camera works fine after allowing. What im concerned about is changing the code to do this and its a possible apple bug that gets fixed and hey then none of the Apps allow the camera function. I cannot see any where that the process has changed for iOS 26 / Xcode 26. Can anyone shed any light on this or had similar experience ?

I am building a macOS utility using SwiftUI and Swift that records and displays keyboard shortcuts (like Cmd+C, Cmd+V) in the UI. To achieve this, I am using NSEvent.addGlobalMonitorForEvents(matching: [.keyDown]). I am aware that global monitoring usually requires the app to be non-sandboxed. However, I am seeing some behavior I don't quite understand during development: I started with a fresh SwiftUI project and disabled the App Sandbox. I requested Accessibility permissions using AXIsProcessTrustedWithOptions, manually enabled it in System Settings, and the global monitor worked perfectly. I then re-enabled the App Sandbox in "Signing & Capabilities." To my surprise, the app still records global events from other applications, even though the Sandbox is now active. Is this expected behavior? Does macOS "remember" the trust because the Bundle ID was previously authorized while non-sandboxed, or is there a specific reason a Sandboxed app can still use addGlobalMonitor if the user has manually granted Accessibility access? My app's core feature is displaying these shortcuts for the user's own reference (productivity tracking). If the user is the one explicitly granting permission via the Accessibility privacy pane, will Apple still reject the app for using global event monitors within a Sandboxed environment? Code snippet of my monitor: // This is still firing even after re-enabling Sandbox eventMonitor = NSEvent.addGlobalMonitorForEvents(matching: [.keyDown]) { event in print("Captured: \(event.charactersIgnoringModifiers ?? "")") } I've tried cleaning the build folder and restarting the app, removing the app from accessibility permission, but the events keep coming through. I want to make sure I'm not relying on a "development glitch" before I commit to the App Store path. Here is the full code anyone can use to try this :- import SwiftUI import Cocoa import Combine struct ShortcutEvent: Identifiable { let id = UUID() let displayString: String let timestamp: Date } class KeyboardManager: ObservableObject { @Published var isCapturing = false @Published var capturedShortcuts: [ShortcutEvent] = [] private var eventMonitor: Any? // 1. Check & Request Permissions func checkAccessibilityPermissions() -> Bool { let options: NSDictionary = [kAXTrustedCheckOptionPrompt.takeUnretainedValue() as String: true] let accessEnabled = AXIsProcessTrustedWithOptions(options) return accessEnabled } // 2. Start Capture func startCapture() { guard checkAccessibilityPermissions() else { print("Permission denied") return } isCapturing = true let mask: NSEvent.EventTypeMask = [.keyDown, .keyUp] eventMonitor = NSEvent.addGlobalMonitorForEvents(matching: mask) { [weak self] event in self?.processEvent(event) } } // 3. Stop Capture func stopCapture() { if let monitor = eventMonitor { NSEvent.removeMonitor(monitor) eventMonitor = nil } isCapturing = false } private func processEvent(_ event: NSEvent) { // Only log keyDown to avoid double-counting the UI display guard event.type == .keyDown else { return } var modifiers: [String] = [] var symbols: [String] = [] // Map symbols for the UI if event.modifierFlags.contains(.command) { modifiers.append("command") symbols.append("⌘") } if event.modifierFlags.contains(.shift) { modifiers.append("shift") symbols.append("⇧") } if event.modifierFlags.contains(.option) { modifiers.append("option") symbols.append("⌥") } if event.modifierFlags.contains(.control) { modifiers.append("control") symbols.append("⌃") } let key = event.charactersIgnoringModifiers?.uppercased() ?? "" // Only display if a modifier is active (to capture "shortcuts" vs regular typing) if !symbols.isEmpty && !key.isEmpty { let shortcutString = "\(symbols.joined(separator: " ")) + \(key)" DispatchQueue.main.async { // Insert at the top so the newest shortcut is visible self.capturedShortcuts.insert(ShortcutEvent(displayString: shortcutString, timestamp: Date()), at: 0) } } } } PS :- I just did another test by creating a fresh new project with the default App Sandbox enabled, and tried and there also it worked!! Can I consider this a go to for MacOs app store than?

Hi, I am in need of your help with publishing my game. I got the following explanation for the negative review of my app/game. Issue Description One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Next Steps Update the local network information purpose string to explain how the app will use the requested information and provide a specific example of how the data will be used. See the attached screenshot. Resources Purpose strings must clearly describe how an app uses the ability, data, or resource. The following are hypothetical examples of unclear purpose strings that would not pass review: "App would like to access your Contacts" "App needs microphone access" See examples of helpful, informative purpose strings. The problem is that they say my app asks to allow my app to find devices on local networks. And that this needs more explanation in the purpose strings. Totally valid to ask, but the problem is my app doesn't need local access to devices, and there shouldn't be code that asks this?? FYI the game is build with Unity. Would love some help on how to turn this off so that my app can get published.

For Local network access, Chrome prompts the user to allow access and adds it to Settings --> Privacy & Security --> Local Network. However, for Safari, no prompt appears. How do I force Safari to authorise these local network access requests if it won't trigger the permission dialogue? Is there a specific WKWebView configuration or Safari-specific header required to satisfy this security check?

On macOS 26.1 (25B78) I can't give Full Disk Access to sshd-keygen-wrapper. Now my Jenkins jobs do not work because they do not have the permission to execute the necessary scripts. Until macOS 26.1 everything worked fine. I restarted the machine several times and tried to give access from Settings -> Privacy & Security -> Full Disk Access but it just does not work. I tried logging with ssh on the machine and executing a script but again nothing happened.

Summary I am investigating a change in macOS 26.1 (Tahoe) where plain (non-bundled) executables that request screen recording access no longer appear under: System Settings → Privacy & Security → Screen & System Audio Recording This behavior differs from macOS Sequoia, where these executables did appear in the list and could be managed through the UI. Tahoe still prompts for permission and still allows the executable to capture the screen once permission is granted, but the executable never shows up in the UI list. This breaks user expectations and removes UI-based permission management. To confirm the behavior, I created a small reproduction project with both: a plain executable, and an identical executable packaged inside an .app bundle. Only the bundled version appears in System Settings. Observed Behaviour 1. Plain Executable (from my reproduction project) When running a plain executable that captures the screen: macOS displays the normal screen-recording permission prompt. Before granting permission: screenshots show only the desktop background. After granting permission: screenshots capture the full display. The executable does not appear under “Screen & System Audio Recording”. Even when permission is granted manually (e.g., dragging the executable into the pane), the executable still does not appear, which prevents the user from modifying or revoking the permission through the UI. If the executable is launched from inside another app (e.g., VS Code, Terminal), the parent app appears in the list instead, not the executable itself. 2. Bundled App Version (from the reproduction project) I packaged the same code into a simple .app bundle (ScreenCaptureApp.app). When running the app: The same permission prompt appears. Pre-permission screenshots show the desktop background. Post-permission screenshots capture the full display. The app does appear under “Screen & System Audio Recording”. This bundle uses the same underlying executable — the only difference is packaging. Hypothesis macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI. Plain executables: still request and receive permission, still function correctly after permission is granted, but do not appear in the System Settings list. This may be an intentional change, undocumented behavior, or a regression. Reproduction Project The reproduction project includes: screen_capture.go A simple Go program that captures screenshots in a loop. screen_capture_executable Plain executable built from the Go source. ScreenCaptureApp.app/ App bundle containing the same executable. build.sh Builds both the plain executable and the app bundle. Permission reset and TCC testing scripts. The project demonstrates the behavior consistently. Steps to Reproduce Plain Executable Build: ./build.sh Reset screen capture permissions: sudo tccutil reset ScreenCapture Run: ./screen_capture_executable Before granting: screenshots show desktop only. Grant permission when prompted. After granting: full screenshots. Executable does not appear in “Screen & System Audio Recording”. Bundled App Build (if not already built): ./build.sh Reset permissions (optional): sudo tccutil reset ScreenCapture Run: open ScreenCaptureApp.app Before granting: screenshots show desktop. After granting: full screenshots. App bundle appears in the System Settings list. Additional Check I also tested launching the plain executable as a child process of another executable, similar to how some software architectures work. Result: Permission prompt appears Permission can be granted Executable still does not appear in the UI, even though TCC tracks it internally → consistent with the plain-executable behaviour. This reinforces that only app bundles are listed. Questions for Apple Is the removal of plain executables from “Screen & System Audio Recording” an intentional change in macOS Tahoe? If so, does Apple now require all screen-recording capable binaries to be packaged as .app bundles for the UI to display them? Is there a supported method for making a plain executable (launched by a parent process) appear in the list? If this is not intentional, what is the recommended path for reporting this as a regression? Files Unfortunately, I have discovered the zip file that contains my reproduction project can't be directly uploaded here. Here is a Google Drive link instead: https://drive.google.com/file/d/1sXsr3Q0g6_UzlOIL54P5wbS7yBkpMJ7A/view?usp=sharing Thank you for taking the time to review this. Any insight into whether this change is intentional or a regression would be very helpful.

I have a binary executable which needs to be given Accessibility Permissions so it can inject keypresses and mouse moves. This was always possible up to macOS 15 - when the first keypress arrived the Accessibility Permissions window would open and allow me to add the executable. However this no longer works in macOS 26: the window still opens, I navigate to the executable file and select it but it doesn't appear in the list. No error message appears. I'm guessing that this may be due to some tightening of security in Tahoe but I need to figure out what to change with my executable to allow it to work.

Apple's Image Playground primarily performs image generation on-device, but can use secure Private Cloud Compute for more complex requests that require larger models. Private Cloud Compute (PCC) For more complex tasks that require greater computational power than the device can provide, Image Playground leverages Apple's Private Cloud Compute. This system extends the privacy and security of the device to the cloud: Secure Environment: PCC runs on Apple silicon servers and uses a secure enclave to protect data, ensuring requests are processed in a verified, secure environment. No Data Storage: Data is never stored or made accessible to Apple when using PCC; it is used only to fulfill the specific request. Independent Verification: Independent experts are able to inspect the code running on these servers to verify Apple's privacy promises.

Hi team, I’m having an issue with my iOS app related to local network communication and connecting to a Wi-Fi speaker. My app works similar to the “4Stream” application. The speaker and the mobile device must be on the same Wi-Fi network so the app can discover and connect to the speaker. What’s happening: When I run the app directly from Xcode in debug mode, everything works perfectly. The speaker gets discovered. The speaker gets connected successfully. The connection flow completes without any problem. But when I upload the same build to TestFlight, the behaviour changes completely. The app gets stuck on the “Connecting…” screen. The speaker is not discovered. But the same code is working fine on Android It never moves forward from that state. So basically: Debug Mode: Speaker is detected and connected properly TestFlight: Stuck at “Connecting…”, speaker does NOT get connected This makes me believe something related to local network access, multicast, Wi-Fi info permissions, or Bonjour discovery is not being applied correctly in the release/TestFlight environment. Below is my current Info.plist and Entitlements file, which already include Local Network Usage, Bonjour services, Location usage for SSID, multicast entitlements, wifi-info, etc. My Info.plist <key>CADisableMinimumFrameDurationOnPhone</key> <true/> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleDisplayName</key> <string>Wanwun</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>$(MARKETING_VERSION)</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>$(CURRENT_PROJECT_VERSION)</string> <key>LSRequiresIPhoneOS</key> <true/> <!-- Allow HTTP to devices on LAN --> <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> <key>NSExceptionDomains</key> <dict> <key>local</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> <key>localhost</key> <dict> <key>NSExceptionAllowsInsecureHTTPLoads</key> <true/> <key>NSIncludesSubdomains</key> <true/> </dict> </dict> </dict> <!-- Local Network Usage --> <key>NSLocalNetworkUsageDescription</key> <string>This app needs local network access to discover and control your sound system device over Wi-Fi.</string> <!-- Bonjour services for discovery --> <key>NSBonjourServices</key> <array> <string>_http._tcp.</string> <string>_wrtn._tcp.</string> <string>_services._dns-sd._udp.</string> </array> <!-- Location for SSID Permission --> <key>NSLocationWhenInUseUsageDescription</key> <string>This app requires location access to read the connected Wi-Fi information.</string> <!-- Camera / Photos --> <key>NSCameraUsageDescription</key> <string>This app needs camera access to capture attendance photos.</string> <key>NSPhotoLibraryAddUsageDescription</key> <string>This app saves captured photos to your gallery.</string> <key>NSPhotoLibraryUsageDescription</key> <string>This app needs access to your gallery to upload existing images.</string> <!-- Bluetooth --> <key>NSBluetoothAlwaysUsageDescription</key> <string>This app uses Bluetooth to discover nearby sound system devices.</string> <key>NSBluetoothPeripheralUsageDescription</key> <string>This app uses Bluetooth to connect with your sound system.</string> <!-- Launch screen --> <key>UILaunchStoryboardName</key> <string>LaunchScreen</string> <!-- Device Capabilities --> <key>UIRequiredDeviceCapabilities</key> <array> <string>arm64</string> </array> <!-- Orientation --> <key>UISupportedInterfaceOrientations</key> <array> <string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationLandscapeLeft</string> <string>UIInterfaceOrientationLandscapeRight</string> </array> <key>UIViewControllerBasedStatusBarAppearance</key> <false/> My Entitlements What I need help with: I want to understand why the app behaves correctly in debug mode (where the speaker connects without issues), but the same functionality fails in TestFlight. Is there something additional required for: Local network discovery on TestFlight? Multicast networking? Reading the Wi-Fi SSID? Bonjour, service scanning? Release build / TestFlight network permissions? If any extra entitlement approval, configuration, or specific service type is needed for TestFlight builds, please guide me. Thank you for your help.

I've been writing about the DeclaredAgeRange a bit on LinkedIn and now it is time to take to the developer forums. In my efforts to prepare my apps for new local requirements, I've run across some rough edges. The DeclaredAgeRange API is missing on several platforms, and extension types. First and foremost, watchOS. An Apple Watch is a clear single user platform and for standalone apps, the DeclaredAgeRange being absent is felt by developers. FB20954931 - DeclaredAgeRange: Framework not available on watchOS making compliance a challenge for watchOS standalone apps In the same vein of thinking, while users on Apple Vision Pro are far fewer numbers than Apple Watch, it is also a miss. The tricky part would be testing on the simulator. So far I haven't gotten the simulator and sandbox testing to work and give real values across any platform. I don't think an Apple Store will let me try my app out via TestFlight on their devices and they're still too expensive to reasonably buy for most developers. Too bad Feedbacks are not a currency that developers can trade in for gear. FB20955020 - DeclaredAgeRange: Framework not available on visionOS making compliance a challenge for visionOS apps I'll recognize that the user model is different on tvOS, and that as a user while I have family group setup, I don't have any children on the account. I have to imagine that child accounts on an Apple TV exist and would be able to account for the sharing of age ranges to apps. Yes, the user could just switch profiles, but, app developers could still integrate the age range into their apps. Maybe it needs more robust system level support but here is the feedback just the same. FB20955029 - DeclaredAgeRange: Framework not available on tvOS making compliance a challenge on tvOS apps And finally, let's not forget about App Clips. While the App Clips might not be 'downloaded' from App Store itself, it is powered by App Store technologies to an extent. I'd rather not bifurcate my code more than it already is for the shared code between my apps and app clips. Rounding out platform support to App Clips, since it is iOS, would close the loop. FB20954846 - DeclaredAgeRange / App Clips: Add support for DeclaredAgeRange framework for App Clip targets - capability exist, Xcode cannot generate entitlement for it Oh wait, actually, not quite. To fully close the loop, make the DeclaredAgeRange work fully on macCatalyst. The documentation says it is compatible, but from my experiments trying to get it to even compile when targeting macCatalyst apps simply doesn't build. FB21117325 - DeclaredAgeRange: API documentation states available on mac catalyst - but fails to compile in Xcode 26.2