Discuss how to secure user data, respect user data preferences, support iCloud Private Relay and Mail Privacy Protection, replace CAPTCHAs with Private Access Tokens, and more. Ask about Privacy nutrition labels, Privacy manifests, and more.

Posts under Privacy tag

200 Posts

Post

Replies

Boosts

Views

Activity

Is there any ways to Determine the Local Network Permission Status in iOS 18.x
Is There a Reliable Way to Check Local Network Permission Status in 2025? I've read many similar requests, but I'm posting this in 2025 to ask: Is there any official or reliable method to check the current Local Network permission status on iOS 18.x? We need this to guide or navigate users to the appropriate Settings page when permission is denied. Background Our app is an IoT companion app, and Local Network access is core to our product's functionality. Without this permission, our app cannot communicate with the IoT hardware. Sadly, Apple doesn't provide any official API to check the current status of this permission. This limitation has caused confusion for many users, and we frequently receive bug reports simply because users have accidentally denied the permission and the app can no longer function as expected. Our App High Level Flow: 1. Trigger Permission We attempt to trigger the Local Network permission using Bonjour discovery and browsing methods. (see the implementation) Since there's no direct API to request this permission, we understand that iOS will automatically prompt the user when the app makes its first actual attempt to communicate with a local network device. However, in our case, this creates a problem: The permission prompt appears only at the time of the first real connection attempt (e.g., when sending an HTTP request to the IoT device). This results in a poor user experience, as the request begins before the permission is granted. The first request fails silently in the background while the permission popup appears unexpectedly. We cannot wait for the user's response to proceed, which leads to unreliable behavior and confusing flows. To avoid this issue, we trigger the Local Network permission proactively using Bonjour-based discovery methods. This ensures that the system permission prompt appears before any critical communication with the IoT device occurs. We’ve tried alternative approaches like sending dummy requests, but they were not reliable or consistent across devices or iOS versions. (see the support ticket) 2. Wi-Fi Connection: Once permission is granted, we allow the user to connect to the IoT device’s local Wi-Fi. 3. IoT Device Configuration: After connecting, we send an HTTP request to a known static IP (e.g., 192.168.4.1) on the IoT network to configure the hardware. I assume this pattern is common among all Wi-Fi-based IoT devices and apps. Problem: Even though we present clear app-level instructions when the system prompt appears, some users accidentally deny the Local Network permission. In those cases, there’s no API to check if the permission was denied, so: We can’t display a helpful message. We can’t guide the user to Settings → Privacy & Security → Local Network to re-enable it. The app fails silently or behaves unpredictably. Developer Needs: As app developers, we want to handle negative cases gracefully by: Detecting if the Local Network permission was denied Showing a relevant message or a prompt to go to Settings Preventing silent failures and improving UX So the question is: What is the current, official, or recommended way to determine whether Local Network permission is granted or denied in iOS 18.x (as of 2025)? This permission is critical for a huge category of apps especially IoT and local communication-based products. We hope Apple will offer a better developer experience around this soon. Thanks in advance to anyone who can share updated guidance.
1
0
122
Jul ’25
Navigation Directional Information Permissions
I am developing a navigation application. My goal is for this navigation app to also work in the background and provide the user with real-time directional updates. When apps request access to location services, users see a TCC (Transparency, Consent, and Control) prompt. This prompt allows the user to choose under what conditions the app can access location services (for example: “While Using the App”, “Always”, etc.). If the user selects the “While Using the App” option, can the navigation app still access location in the background and provide directional information to the user? Is something like this technically possible? Does Apple allow this behavior for navigation apps or similar use cases?
0
0
50
Jul ’25
Local Network Permission Inconsistencies in iOS 17.x and 18.x (Tested on iOS 18.6 beta)
We are developing an IoT companion app that connects to the IoT device's Wi-Fi network and communicates with it through local network APIs. To support this functionality, we have: Added the necessary keys in the Info.plist. NSLocalNetworkUsageDescription , NSBonjourServices Used a Bonjour service at app launch to trigger the local network permission prompt. Problem on iOS 18.x (including 18.6 beta) Even when the user explicitly denies the local network permission, our API communication still works. This is unexpected behavior, as we assume denying permission should restrict access to local network communication. We tested this with the latest iOS 18.6 beta (as per Thread 789461021), but the issue still persists. This behavior raises concerns about inconsistent permission enforcement in iOS 18.x. Problem on iOS 17.x In iOS 17.x, if the user accidentally denies the local network permission and later enables it manually via Settings, the change does not take effect immediately. The app cannot access the local network unless the device is restarted, which results in a confusing and poor user experience. Expected Behavior If local network permission is denied, local API communication should be strictly blocked. If the permission is later enabled via Settings, the app should regain access without requiring a device restart. Request We request clarification and resolution on: Why local network APIs are accessible even when permission is denied on iOS 18.x. Whether the delayed permission update (requiring restart) in iOS 17.x is expected or a known issue. Best practices to ensure consistent and predictable permission handling across iOS versions.
2
0
196
Jun ’25
Permission requirements for LAContext's canEvaluatePolicy
Hi, I am developing an app that checks if biometric authentication capabilities (Face ID and Touch ID) are available on a device. I have a few questions: Do I need to include a privacy string in my app to use the LAContext's canEvaluatePolicy function? This function checks if biometric authentication is available on the device, but does not actually trigger the authentication. From my testing, it seems like a privacy declaration is only required when using LAContext's evaluatePolicy function, which would trigger the biometric authentication. Can you confirm if this is the expected behavior across all iOS versions and iPhone models? When exactly does the biometric authentication permission pop-up appear for users - is it when calling canEvaluatePolicy or evaluatePolicy? I want to ensure my users have a seamless experience. Please let me know if you have any insights on these questions. I want to make sure I'm handling the biometric authentication functionality correctly in my app. Thank you!
2
0
101
Jun ’25
Is a Read-Only GET Request Without User Data Considered ‘No Data Collection’?
Hi everyone, My iOS app performs only a GET request to an external server to receive a JSON with configuration data (e.g., app settings). It does not send any personal data — it's a read-only request used only to adjust app behavior. Since the app only performs a GET request to the server and does not send any data from the user, no data is collected or stored. In App Store Connect > App Privacy, is it correct to select: "No, we do not collect data from this app"? Just want to confirm this is acceptable before submitting. Thanks!
3
0
116
Jun ’25
Which in-app events are allowed without ATT consent?
Hi everyone, I'm developing an iOS app using the AppsFlyer SDK. I understand that starting with iOS 14.5, if a user denies the App Tracking Transparency (ATT) permission, we are not allowed to access the IDFA or perform cross-app tracking. However, I’d like to clarify which in-app events are still legally and technically safe to send when the user denies ATT permission. Specifically, I want to know: Is it acceptable to send events like onboarding_completed, paywall_viewed, subscription_started, subscribe, subscribe_price, or app_opened if they are not linked to IDFA or any form of user tracking? Would sending such internal behavioral events (used purely for SKAdNetwork performance tracking or in-app analytics) violate Apple’s privacy policy if no device identifiers are attached? Additionally, if these events are sent in fully anonymous form (i.e., not associated with IDFA, user ID, email, or any identifiable metadata), does Apple still consider this a privacy concern? In other words, can onboarding_completed, paywall_viewed, subsribe, subscribe_price, etc., be sent in anonymous format without violating ATT policies? Are there any official Apple guidelines or best practices that outline what types of events are considered compliant in the absence of ATT consent? My goal is to remain 100% compliant with Apple’s policies while still analyzing meaningful user behavior to improve the in-app experience. Any clarification or pointers to documentation would be greatly appreciated. Thanks in advance!
0
0
97
Jun ’25
Local Network Connection is still working even after denied the permission when asked
I've a iOT companion app, in which I'll connect to iOT's Wi-Fi and then communicate the device with APIs, for the above functionality we needed local network permission So we enabled neccessary keys in info.plist and at the time of App Launch we trigger local network permission using the following code info.plist <string>This app needs local network access permission to connect with your iOT device and customize its settings</string> <key>NSBonjourServices</key> <array> <string>_network-perm._tcp</string> <string>_network-perm._udp</string> </array> Network Permission Trigger Methods import Foundation import MultipeerConnectivity class NetworkPermissionManager: NSObject { static let shared = NetworkPermissionManager() private var session: MCSession? private var advertiser: MCNearbyServiceAdvertiser? private var browser: MCNearbyServiceBrowser? private var permissionCallback: ((String) -> Void)? func requestPermission(callback: @escaping (String) -> Void) { self.permissionCallback = callback do { let peerId = MCPeerID(displayName: UUID().uuidString) session = MCSession(peer: peerId, securityIdentity: nil, encryptionPreference: .required) session?.delegate = self advertiser = MCNearbyServiceAdvertiser( peer: peerId, discoveryInfo: nil, serviceType: "network-perm" ) advertiser?.delegate = self browser = MCNearbyServiceBrowser( peer: peerId, serviceType: "network-perm" ) browser?.delegate = self advertiser?.startAdvertisingPeer() browser?.startBrowsingForPeers() // Stop after delay DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { [weak self] in self?.stopAll() // If no error occurred until now, consider permission triggered self?.permissionCallback?("granted") self?.permissionCallback = nil } } catch { permissionCallback?("error: \(error.localizedDescription)") permissionCallback = nil } } func stopAll() { advertiser?.stopAdvertisingPeer() browser?.stopBrowsingForPeers() session?.disconnect() } } extension NetworkPermissionManager: MCSessionDelegate { func session(_: MCSession, peer _: MCPeerID, didChange _: MCSessionState) {} func session(_: MCSession, didReceive _: Data, fromPeer _: MCPeerID) {} func session(_: MCSession, didReceive _: InputStream, withName _: String, fromPeer _: MCPeerID) {} func session(_: MCSession, didStartReceivingResourceWithName _: String, fromPeer _: MCPeerID, with _: Progress) {} func session(_: MCSession, didFinishReceivingResourceWithName _: String, fromPeer _: MCPeerID, at _: URL?, withError _: Error?) {} } extension NetworkPermissionManager: MCNearbyServiceAdvertiserDelegate { func advertiser(_: MCNearbyServiceAdvertiser, didReceiveInvitationFromPeer _: MCPeerID, withContext _: Data?, invitationHandler: @escaping (Bool, MCSession?) -> Void) { invitationHandler(false, nil) } func advertiser(_: MCNearbyServiceAdvertiser, didNotStartAdvertisingPeer error: Error) { print("❌ Advertising failed: \(error)") if let nsError = error as NSError?, nsError.domain == NetService.errorDomain, nsError.code == -72008 { permissionCallback?("denied") } else { permissionCallback?("error: \(error.localizedDescription)") } permissionCallback = nil stopAll() } } extension NetworkPermissionManager: MCNearbyServiceBrowserDelegate { func browser(_: MCNearbyServiceBrowser, foundPeer _: MCPeerID, withDiscoveryInfo _: [String: String]?) {} func browser(_: MCNearbyServiceBrowser, lostPeer _: MCPeerID) {} func browser(_: MCNearbyServiceBrowser, didNotStartBrowsingForPeers error: Error) { print("❌ Browsing failed: \(error)") if let nsError = error as NSError?, nsError.domain == NetService.errorDomain, nsError.code == -72008 { permissionCallback?("denied") } else { permissionCallback?("error: \(error.localizedDescription)") } permissionCallback = nil stopAll() } }``` I want to satisfy this following cases but it's not working as expected # Case1 Working App launches --> trigger permission using above code --> user granted permission --> connect to iOT's Wi-Fi using app --> Communicate via Local API ---> should return success response # Case2 Not working App launches --> trigger permission using above code --> user denied permission --> connect to iOT's Wi-Fi using app --> Communicate via Local API ---> should throw an error I double checked the permission status in the app settings there also showing disabled state In my case case 2 is also return success, even though user denied the permission I got success response. I wonder why this happens the same above 2 cases working as expected in iOS 17.x versions
3
0
133
Jun ’25
Submission rejected - 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. Next Steps Update the camera and photo library 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. I submitted my app to review, and got this review message. When you clcik on you profile picture, you can view it, or change it. When you decide to change it, the app need permission for camera or galler (depending on which one you select) For camera the request message is: ,, In order to take a picture or video, this app requires permission to access the camera" For gallery the request message is: ,, In order to upload data, this app requires permission to access the photo library." I was looking at the guidlines in here: https://developer.apple.com/design/human-interface-guidelines/privacy#Requesting-permission especially the ,,Example 2" unde the Requestion permission section. It seems to me, like I've got basically the same thing as is stated in the example, but the reviewers don't seem to like it. Any idea how I can make my permission requests compliant?
3
0
124
Jun ’25
Behavior differences when using CBCentralManager on different iPhone configurations
Hi, I am developing an app that checks if Bluetooth is available on the device or not (does not actually use any Bluetooth capabilities). The only CoreBluetooth API's that I use are: CBCentralManager the state property of the CBCentralManager centralManagerDidUpdateState When I am testing, I experience different behaviors on my test devices. On an iPhone 15 iOS 18.5, the app works fine. However, on an iPhone 13 iOS 18.3.2, the app crashes with the following error: This app has crashed because it attempted to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothAlwaysUsageDescription key with a string value explaining to the user how the app uses this data. Why is this permission required on my iPhone 13 iOS 18.3.2, but not my iPhone 15 iOS 18.5? Why do I experience different behavior on different iPhone configurations?
3
0
95
Jun ’25
Custom Authorization Plugin in Login Flow
What Has Been Implemented Replaced the default loginwindow:login with a custom authorization plugin. The plugin: Performs primary OTP authentication. Displays a custom password prompt. Validates the password using Open Directory (OD) APIs. Next Scenario was handling password change Password change is simulated via: sudo pwpolicy -u robo -setpolicy "newPasswordRequired=1" On next login: Plugin retrieves the old password. OD API returns kODErrorCredentialsPasswordChangeRequired. Triggers a custom change password window to collect and set new password. Issue Observed : After changing password: The user’s login keychain resets. Custom entries under the login keychain are removed. We have tried few solutions Using API, SecKeychainChangePassword(...) Using CLI, security set-keychain-password -o oldpwd -p newpwd ~/Library/Keychains/login.keychain-db These approaches appear to successfully change the keychain password, but: On launching Keychain Access, two password prompts appear, after authentication, Keychain Access window doesn't appear (no app visibility). Question: Is there a reliable way (API or CLI) to reset or update the user’s login keychain password from within the custom authorization plugin, so: The keychain is not reset or lost. Keychain Access works normally post-login. The password update experience is seamless. Thank you for your help and I appreciate your time and consideration
2
0
115
Jun ’25
IOS App tcp connect and local network permission
Recently, my application was having trouble connecting socket using TCP protocol after it was reinstalled. The cause of the problem was initially that I did not grant local network permissions when I reinstalled, I was aware of the problem, so socket connect interface worked fine after I granted permissions. However, the next time I repeat the previous operation, I also do not grant local network permissions, and then turn it back on in the Settings, and socket connect interfcae does not work properly (connect interface return errno 65, the system version and code have not changed). Fortunately, socket connect success after rebooting the phone, and more importantly, I was able to repeat the problem many times. So I want to know if the process between when I re-uninstall the app and deny local network permissions, and when I turn it back on in Settings, is that permissions have been granted normally, and not fake, and not required a reboot to reset something for socket coonnect to take effect.
5
0
210
Jun ’25
Submission Rejected: Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage
Hello Experts, I am in need of your help with this feedback from the App Reviewer. 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 location 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" Feedback #2 "Regarding 5.1.1, we understand why your app needs access to location. However, the permission request alert does not sufficiently explain this to your users before accessing the location. To resolve this issue, it would be appropriate to revise the location permission request, specify why your app needs access, and provide an example of how your app will use the user's data. To learn more about purpose string requirements, watch a video from App Review with tips for writing clear purpose strings. We look forward to reviewing your app once the appropriate changes have been made." May I know how can I update my purpose string? I appealed on the first feedback by explaining what is the purpose of it but got the Feedback #2. TYIA!!
1
0
197
Jun ’25
Autogenerated UI Test Runner Blocked By Local Network Permission Prompt
I've recently updated one of our CI mac mini's to Sequoia in preparation for the transition to Tahoe later this year. Most things seemed to work just fine, however I see this dialog whenever the UI Tests try to run. This application BoostBrowerUITest-Runner is auto-generated by Xcode to launch your application and then run your UI Tests. We do not have any control over it, which is why this is most surprising. I've checked the codesigning identity with codesign -d -vvvv as well as looked at it's Info.plist and indeed the usage descriptions for everything are present (again, this is autogenerated, so I'm not surprised, but just wanted to confirm the string from the dialog was coming from this app) &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;BuildMachineOSBuild&lt;/key&gt; &lt;string&gt;22A380021&lt;/string&gt; &lt;key&gt;CFBundleAllowMixedLocalizations&lt;/key&gt; &lt;true/&gt; &lt;key&gt;CFBundleDevelopmentRegion&lt;/key&gt; &lt;string&gt;en&lt;/string&gt; &lt;key&gt;CFBundleExecutable&lt;/key&gt; &lt;string&gt;BoostBrowserUITests-Runner&lt;/string&gt; &lt;key&gt;CFBundleIdentifier&lt;/key&gt; &lt;string&gt;company.thebrowser.Browser2UITests.xctrunner&lt;/string&gt; &lt;key&gt;CFBundleInfoDictionaryVersion&lt;/key&gt; &lt;string&gt;6.0&lt;/string&gt; &lt;key&gt;CFBundleName&lt;/key&gt; &lt;string&gt;BoostBrowserUITests-Runner&lt;/string&gt; &lt;key&gt;CFBundlePackageType&lt;/key&gt; &lt;string&gt;APPL&lt;/string&gt; &lt;key&gt;CFBundleShortVersionString&lt;/key&gt; &lt;string&gt;1.0&lt;/string&gt; &lt;key&gt;CFBundleSignature&lt;/key&gt; &lt;string&gt;????&lt;/string&gt; &lt;key&gt;CFBundleSupportedPlatforms&lt;/key&gt; &lt;array&gt; &lt;string&gt;MacOSX&lt;/string&gt; &lt;/array&gt; &lt;key&gt;CFBundleVersion&lt;/key&gt; &lt;string&gt;1&lt;/string&gt; &lt;key&gt;DTCompiler&lt;/key&gt; &lt;string&gt;com.apple.compilers.llvm.clang.1_0&lt;/string&gt; &lt;key&gt;DTPlatformBuild&lt;/key&gt; &lt;string&gt;24A324&lt;/string&gt; &lt;key&gt;DTPlatformName&lt;/key&gt; &lt;string&gt;macosx&lt;/string&gt; &lt;key&gt;DTPlatformVersion&lt;/key&gt; &lt;string&gt;15.0&lt;/string&gt; &lt;key&gt;DTSDKBuild&lt;/key&gt; &lt;string&gt;24A324&lt;/string&gt; &lt;key&gt;DTSDKName&lt;/key&gt; &lt;string&gt;macosx15.0.internal&lt;/string&gt; &lt;key&gt;DTXcode&lt;/key&gt; &lt;string&gt;1620&lt;/string&gt; &lt;key&gt;DTXcodeBuild&lt;/key&gt; &lt;string&gt;16C5031c&lt;/string&gt; &lt;key&gt;LSBackgroundOnly&lt;/key&gt; &lt;true/&gt; &lt;key&gt;LSMinimumSystemVersion&lt;/key&gt; &lt;string&gt;13.0&lt;/string&gt; &lt;key&gt;NSAppTransportSecurity&lt;/key&gt; &lt;dict&gt; &lt;key&gt;NSAllowsArbitraryLoads&lt;/key&gt; &lt;true/&gt; &lt;/dict&gt; &lt;key&gt;NSAppleEventsUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSBluetoothAlwaysUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSCalendarsUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSCameraUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSContactsUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSDesktopFolderUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSDocumentsFolderUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSDownloadsFolderUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSFileProviderDomainUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSFileProviderPresenceUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSLocalNetworkUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSLocationUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSMicrophoneUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSMotionUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSNetworkVolumesUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSPhotoLibraryUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSRemindersUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSRemovableVolumesUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSSpeechRecognitionUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSSystemAdministrationUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;NSSystemExtensionUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;key&gt;OSBundleUsageDescription&lt;/key&gt; &lt;string&gt;Access is necessary for automated testing.&lt;/string&gt; &lt;/dict&gt; &lt;/plist&gt; Additionally, spctl --assess --type execute BoostBrowserUITests-Runner.app return an exit code of 0 so I assume that means it can launch just fine, and applications are allowed to be run from "anywhere" in System Settings. I've found the XCUIProtectedResource.localNetwork value, but it seems to only be accessible on iOS for some reason (FB17829325). I'm trying to figure out why this is happening on this machine so I can either fix our code or fix the machine. I have an Apple script that will allow it, but it's fiddly and I'd prefer to fix this the correct way either with the machine or with fixing our testing code.
9
1
303
Jun ’25
processInfo.hostName requires 'local network' permission on iOS
Either processInfo.hostName should return the same info as UIDevice.name ("iPhone") or it should require the same entitlement that UIDevice.name does to return the actual result. If processInfo.hostName is intended to return the local Bonjour name, why does it need 'local network' permission? Why isn't the 'local network' permission documented for processInfo.hostName as this is hard to track down? Tested on iOS 18.5
2
0
90
Jun ’25
Disable Local Network Access permission check
I'm using a Mac Studio in a homelab context and use Homebrew to manage the installed services. The services include things that access the local network, for example Prometheus which monitors some other servers, a reverse proxy which fronts other web services on the network, and a DNS server which can use another as upstream. Local Network Access permissions make it impossible to reliably perform unattended updates of services because an updated binary requires a GUI login to grant local network permissions (again). I use brew services to manage the services as launchd agents, i.e. they run in a non-root GUI context. I know that I can also use sudo brew services which instead installs the services as launchd daemons, but running services as root has negative security implication and generally doesn't look like a good idea to me. If only there was a way to disable local network access checks altogether…
5
0
179
Jun ’25
Certificate Trust Failing in Latest OS Releases
Trying to apply 'always trust' to certificate added to keychain using both SecItemAdd() and SecPKCS12Import() with SecTrustSettingsSetTrustSettings(). I created a launchdaemon for this purpose. AuthorizationDB is modified so that any process running in root can apply trust to certificate. let option = SecTrustSettingsResult.trustRoot.rawValue // SecTrustSettingsResult.trustAsRoot.rawValue for non-root certificates let status = SecTrustSettingsSetTrustSettings(secCertificate, SecTrustSettingsDomain.admin, [kSecTrustSettingsResult: NSNumber(value: option.rawValue)] as CFTypeRef). Above code is used to trust certificates and it was working on os upto 14.7.4. In 14.7.5 SecTrustSettingsSetTrustSettings() returns errAuthorizationInteractionNotAllowed. In 15.5 modifying authorization db with AuthorizationRightSet() itself is returning errAuthorizationDenied.Tried manually editing authorization db via terminal and same error occurred. Did apple update anything on Security framework? Any other way to trust certificates?
3
0
119
Jun ’25
Title: Sporadical - Permissions Not Cleared After App Uninstallation on iOS18
Title: Sporadical - Permissions Not Cleared After App Uninstallation on iOS18 I install and launch my private MAUI App I ask for example Bluetooth permissions (can be any other permission) I tap Allow button on native settings (or Don't Allow) I unistall app from real phone (we can wait for a while) I install and launch My Private MAUI App I ask for example Bluetooth permissions &lt;- here is an issue. Bluetooth is already granted, so I cannot ask for it again. Occurrence: This issue occurs inconsistently: On iOS 18.5: approximately 5 out of 10 times On iOS 17: approximately 1 out of 50 times Tested using my automated system using Appium latest. After each scenario I unistall app using: "mobile: removeApp" with bundleId
1
1
67
Jun ’25