Hi everyone, We are working on an app that requires access to devices on the local network (Bonjour / LAN discovery + direct socket communication). We are currently struggling with the Local Network privacy permission flow introduced by Apple. From our understanding, there is no dedicated public API to explicitly request Local Network permission or to reliably determine the current authorization state before attempting network activity. We have tried several commonly suggested approaches to trigger the permission dialog, including: Bonjour browsing via NWBrowser Publishing/listening with NetService UDP/TCP socket attempts on local subnet NWConnection / NWListener Triggering discovery after app launch and after foreground transitions We already added the required entries in: NSLocalNetworkUsageDescription NSBonjourServices However, the behavior is inconsistent across devices and OS versions: Sometimes the popup appears immediately Sometimes it never appears Sometimes network operations silently fail without callback clarity In some cases callbacks are delayed or ambiguous Reinstalling/resetting permissions changes behavior unpredictably Our main challenges are: What is currently considered the most reliable Apple-approved method to trigger the Local Network permission prompt? Is there any officially recommended way to determine whether permission is: not determined denied granted Is there any reliable callback or state transition API developers should use? Are there known differences between: NWBrowser NetService BSD sockets NWConnection when it comes to triggering the permission dialog? Are there recommended retry/timing patterns to avoid race conditions during app launch? Is Apple planning to introduce a dedicated authorization API similar to: AVAuthorizationStatus CLAuthorizationStatus PHPhotoLibrary.authorizationStatus() Right now it feels difficult to provide a reliable UX because there is no deterministic way to: proactively request access observe authorization state recover gracefully when the prompt does not appear Any guidance, DTS references, WWDC sessions, or recommended implementation patterns would be greatly appreciated. Thanks!

Connected x out in stores 🤖❤️

เนื่องจากได้อ่านรายละเอียดเกี่ยวกับแล้วตรงและสิ่งที่เจอทั้งหมดหลังจากได้ทีการแจ้งไปเรื่องโดนแฮ็กข้อมูลและถูกโจรกรรมข้อมูลส่วนบุคคลทั้งหมด เจอสถานณ์ตรงตามส่วน คำเตือนเนื้อหาที่ละเอียดอ่อนทั้งหมด ตอนนี้สภาพจิตใจย้ำแย่เป็นอย่างมากและท้อใจอย่างที่สุดเพราะโดเดี่ยวสู้กับปัญหาและพยายามหาหลักฐานเพียงผู้เดียวซึ่งไม่เหลืแคนที่ไว้วางใจได้แม้แต่คนเดียว เพราะโดนใส่ร้ายทุกรูปแบบจนเสียงชื่อเสียงเหมือนกับผลักทุกคนออกไปจากชีวิตจนไม่เหลือแม้คนเดียวที่รับฟังทำให้พูดความจริงทั้งหมดไม่มีใครเชื่อและรับฟังแม้แต่คนเดียว เหตุที่แจ้งไปก่อนหน้านี้เป็นเวลาเกือบ 8 เดือนกว่าๆแล้วจนถึงปัจจุบันนี้ ยังไม่ได้รับกาคช่วยเหลือหรือไม่มีการช่วยเหลือใดๆทั้งสิ้น

Hi, I created an app and want to use Google Admob to show ads. I am a little bit confused how exactly tracking, more specifically, the ATT-framework and Google Admob relate to each other. The current work flow is: ATT-permission given -> show google ad mob consent form However, I am confused what I should do if the ATT permission is denied. Can I still show the consent form of google admobs or is that forbidden? If so what do I need to then? Thank you!

Hi, we have an app which used DeviceID to track users. We had implemented ATT and setup our privacy declaration in ASC accordingly. Now in our new version we decided to not track users anymore. We removed NSUserTrackingUsageDescription, removed ATT permission code and submitted the new version. Now, reviewer has complained that our privacy declaration in ASC still says we are tracking users and refused app acceptance. They told us to update the privacy declaration in ASC. We tried to do so, but ASC does not allow us to remove device ID tracking. It is showing a warning that our app still uses NSUserTrackingUsageDescription and in fact that is true for the production version. We are now in a chicken egg problem. We can't change our privacy declaration in ASC because the production version still uses the feature AND we do not get the new version accepted as long as our privacy declaration is not changed. How can we fix that ? Pls advise !

Hello, so basically I’m trying to upload a build to App Store Connect but it gets flagged for a potential rejection thus unable to submit. The icon tells me there is a problem with tracking-related code in my app but I can’t seem to remove it. Need urgent support from a technical expert preferably.

Hi, We’re building an iOS app that uses the Screen Time APIs (FamilyControls and DeviceActivity) to display a user’s own usage metrics inside the app. With the appropriate permissions granted, we are successfully reading and presenting metrics such as: Total screen time Device pickups These metrics are already visible to the user inside our app. We would now like to introduce a user-initiated “Share” feature. The idea is to: Render selected Screen Time metrics into a shareable image card generated locally on device. Present the standard iOS share sheet (UIActivityViewController). Allow the user to share that image to Messages, social apps, etc., if they choose. Important clarifications: This is fully user-initiated. The app does not automatically transmit Screen Time data. The metrics are already displayed in-app with user permission. The share asset would be generated locally. No background export or server-side posting would occur unless explicitly triggered by the user via the share sheet. We are seeking clarification on whether there are any policy or API restrictions around: Rendering Screen Time-derived metrics into a user-facing share card Allowing user-initiated export of those metrics via the standard iOS share flow Are there any additional privacy requirements, entitlement constraints, or App Review considerations we should be aware of when implementing this? Thanks in advance for any guidance.

Hello, I posted my app for review to the appstore. Reviewers could not find the App Tracking Transparency (ATT) permission request because I did not implement it... I am unsure if my app is tracking user the way ATT means it. The app collects user email, firstname, lastname (+ optional city of residence) and scores. This is used to show hall of fames score page and perform some internal analytics. There are no ads and I do not transmit this information to any third party web site, vendor or library. Do I need to implement ATT then? Thanks a lot. Have a nice day.

Our proposed solution to identify an app user when opening a website operated by app developer is: Apps sends a request to backed with app users auth header Backend fetches a generated authenticated url from website backend, based on users auth header App opens it in browser The browser journey is self contained within domain of the business. Would this interaction require an ATT request given that the users identity cannot be tracked back to the app user ? Thanks

We noticed in multiple apps that readableContentGuide is way too wide on iOS 26.x. Here are changes between iPad 13inch iOS 18.3 and the same device iOS 26.2 (but this affects also iOS 26.0 and iOS 26.1): 13 inch iOS 18 Landscape ContentSizeCategory: XS, Width: 1376.0 , Readable Width: 560.0 S, Width: 1376.0 , Readable Width: 600.0 M, Width: 1376.0 , Readable Width: 632.0 L, Width: 1376.0 , Readable Width: 664.0 XL, Width: 1376.0 , Readable Width: 744.0 XXL, Width: 1376.0 , Readable Width: 816.0 XXXL,Width: 1376.0 , Readable Width: 896.0 A_M, Width: 1376.0 , Readable Width: 1096.0 A_L, Width: 1376.0 , Readable Width: 1280.0 A_XL,Width: 1376.0 , Readable Width: 1336.0 13 inch iOS 26 Landscape ContentSizeCategory: XS, Width: 1376.0 , Readable Width: 752.0 S, Width: 1376.0 , Readable Width: 800.0 M, Width: 1376.0 , Readable Width: 848.0 L, Width: 1376.0 , Readable Width: 896.0 XL, Width: 1376.0 , Readable Width: 1000.0 XXL, Width: 1376.0 , Readable Width: 1096.0 XXXL,Width: 1376.0 , Readable Width: 1200.0 A_M, Width: 1376.0 , Readable Width: 1336.0 The code I used: class ViewController: UIViewController { lazy var readableView: UIView = { let view = UIView() view.backgroundColor = .systemBlue view.translatesAutoresizingMaskIntoConstraints = false return view }() override func viewDidLoad() { super.viewDidLoad() view.addSubview(readableView) NSLayoutConstraint.activate([ readableView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor), readableView.leadingAnchor.constraint(equalTo: view.readableContentGuide.leadingAnchor), readableView.trailingAnchor.constraint(equalTo: view.readableContentGuide.trailingAnchor), readableView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor) ]) } override func viewDidLayoutSubviews() { super.viewDidLayoutSubviews() if readableView.frame.width > 0 { let orientation = UIDevice.current.orientation print(""" ContentSizeCategory: \(preferredContentSizeCategoryAsString()) Width: \(view.frame.width) , Readable Width: \(readableView.frame.width), Ratio: \(String(format: "%.1f", (readableView.frame.width / view.frame.width) * 100))% """) } } func preferredContentSizeCategoryAsString() -> String { switch UIApplication.shared.preferredContentSizeCategory { case UIContentSizeCategory.accessibilityExtraExtraExtraLarge: return "A_XXXL" case UIContentSizeCategory.accessibilityExtraExtraLarge: return "A_XXL" case UIContentSizeCategory.accessibilityExtraLarge: return "A_XL" case UIContentSizeCategory.accessibilityLarge: return "A_L" case UIContentSizeCategory.accessibilityMedium: return "A_M" case UIContentSizeCategory.extraExtraExtraLarge: return "XXXL" case UIContentSizeCategory.extraExtraLarge: return "XXL" case UIContentSizeCategory.extraLarge: return "XL" case UIContentSizeCategory.large: return "L" case UIContentSizeCategory.medium: return "M" case UIContentSizeCategory.small: return "S" case UIContentSizeCategory.extraSmall: return "XS" case UIContentSizeCategory.unspecified: return "U" default: return "D" } } } Please advise, it feels completely broken. Thank you.

I've been rejected multiple times for App Tracking Transparency issues, but I'm stuck due to an App Store Connect bug. ISSUE: When I try to edit "Advertising Data" in App Privacy settings to uncheck "Used for tracking purposes," I get an error: "An error has occurred. Try again later." This has persisted for 2 weeks across multiple browsers and devices. MY SITUATION: My app uses AdMob for rewarded video ads (users watch ads to earn in-game currency) I do NOT want to track users across apps/websites I want to declare: "Advertising Data: Used for Third-Party Advertising" (NOT for tracking) But I cannot save these privacy setting changes due to the App Store Connect error. Apple Review keeps rejecting my app saying to "update privacy settings," but their system won't let me. QUESTIONS: Is there a workaround for this App Store Connect bug? Can Apple manually update my privacy settings? Any help appreciated. I've been stuck for 2 weeks.

Recently I noticed an app called “Lookus”. Even if I force‑kill it, it still seems to obtain information such as my charging status and network status, and it can even send real‑time notifications. I’m curious how this is technically possible. Does anyone know how this could be achieved?

I have reached out to support and they simply tell me they are unable to help me, first redirecting me to generic Apple support, after following up they provided the explanation that they only handle administrative tasks and to post on the forums. I am unable to change my App Tracking Transparency it provides no real error, though network traffic shows a 409 HTTP response from the backend API when trying to save. Here is a screenshot of the result when trying to save. Does anyone have any suggestions on how to get this resolved? I've commented back to the reviewers and they simply provided help documentation. I have a technical issue and am unable to get anyone to help resolve this.

Hello, I am looking to develop a relationship with a developer that has experience running through the IOS build approval process. To elaborate, my team and I have designed and built a software application which is working through the Apple Developer review process to have the app approved and released to the App Store. Unfortunately, there has been some challenges, simple challenges in my eyes with our interface preventing Apple from approving our application. Happy to elaborate further. A primary problem and solution I have seen is the software build was testing solely on the iPhone but as recently directed it seem the application must be accessible on iPad as well. With this the case, I have experience some software platforms where on the ipad the interface is not displayed on the whole screen. I am looking for direction on how to implement this setup for the 1st IOS build. Another concern from Apples Developer Review team is the App Tracking Transparency kit may need to be implemented.

Hello everyone, I've noticed some unusual behavior while debugging my application on the iOS 26 beta. My standard testing process relies on the App Tracking Transparency (ATT) authorization status being reset whenever I uninstall and reinstall my app. This is crucial for me to test the permission flow. However, on the current beta, I've observed the following: 1 I installed my app on a device running the iOS 26 beta for the first time. The ATTrackingManager.requestTrackingAuthorization dialog appeared as expected. 2 I completely uninstalled the application. 3 I then reinstalled the app. Unexpected Result: The tracking permission dialog did not appear. And more importantly, the device's advertisingIdentifier appears to have remained unchanged. This is highly unusual, as the IDFA is expected to be reset with a fresh app installation. My question: Is this an intentional change, and is there a fundamental shift in how the operating system handles the persistence of the IDFA or the authorization status? Or could this be a bug in the iOS 26 beta? Any information or confirmation on this behavior would be greatly appreciated.

Hi everyone, I'm facing a frustrating App Store rejection that I can't seem to resolve. My app was rejected under Guideline 2.1 - Information Needed with the following message: "The app uses the AppTrackingTransparency framework, but we are unable to locate the App Tracking Transparency permission request when reviewed on iPadOS 18.5." However, in my latest version (2.9 Build 18), I have: Removed all SDKs that collect IDFA or perform tracking. Removed the AppTrackingTransparency framework entirely. Removed the NSUserTrackingUsageDescription key from Info.plist. Confirmed that no third-party SDKs are accessing IDFA or similar. Not using the app_tracking_transparency package (I'm using Flutter). I included a detailed review note explaining all of this, yet the app still gets rejected for not showing the ATT prompt — even though ATT is not used at all. Also, I can't update the App Privacy section until this new version is approved, which still reflects tracking from a previous live version (2.3). Has anyone faced something similar? Questions: Is there a way to confirm what part of the build might still be triggering ATT detection on Apple's side? Could an unused pod or leftover reference be the issue? How do I fully verify that ATT is not linked anywhere in the final binary? Any guidance or tips from others who’ve resolved this would be hugely appreciated! Thanks

We are experiencing a significant issue with the SKStoreReviewController.requestReview(in: scene) API that may be affecting our app's rating collection on the App Store. Issue Details: Development Environment Behavior: The rating popup displays consistently in development builds (as expected per documentation) API calls are functioning correctly in our test environment Production Environment Issue: We have observed a major drop in App Store ratings received between January and July 2025 The same codebase that works in development is deployed to production Analytics Confirmation: Before calling SKStoreReviewController.requestReview() in production, we fire analytics tags to track API invocations Our analytics show no drop in the number of times this API is being called This confirms the API is being invoked correctly in production Discrepancy: Despite consistent API calls (confirmed by analytics), we see a major drop in actual ratings received on the App Store This suggests the rating popup may not be displaying to users in production, even though the API call is successful Questions: Are there any known issues with SKStoreReviewController.requestReview() API between January-July 2025? Are there any iOS version-specific issues that might prevent the popup from appearing in live app? What debugging steps do you recommend to identify why the API calls aren't resulting in visible rating prompts?

When presenting a cookie banner for GDPR purposes, should ATT precede the cookie banner? It seems that showing a Cookie Banner and then showing the ATT permission prompt afterwards (if a user elects to allow cookies/tracking) would be more appropriate. Related question: Should the “Allow Tracking” toggle for an app in system settings serve as a master switch for any granular tracking that might be managed by a 3rd party Consent Management Platform? If ATT is intended to serve as a master switch for tracking consent, if the ATT prompt is presented before a cookie banner, should the banner even appear if a user declines tracking consent? I’m not finding any good resources that describe this flow in detail and I’m seeing implementations all over the place on this. Help! Thanks!!!

Hi Apple Devs & WebKit Team, We operate https://excnum.com — a personal website currently under reconstruction. It's HTTPS-secure, hosted on a clean VPS, and now features a simple placeholder page with no active forms, scripts, or external redirects. However, Safari on both iOS and macOS is flagging it as a “deceptive website”, blocking all access. This warning appears even though: The site uses a valid SSL certificate via Cloudflare There are no redirects, tracking scripts, or dynamic code We serve a static landing page (“under maintenance”) with zero interaction No malware, phishing, or obfuscation exists — verified with multiple tools A review request has already been submitted at: https://websitereview.apple.com We believe the site may have been blacklisted previously under past ownership or prior configurations. It has since been completely restructured and cleared, but the Safari warning persists. This false flag is harming visibility and trust for an otherwise neutral website. Any advice on how to expedite re-evaluation or request a manual delisting from the deceptive site list would be much appreciated. Thank you! — Alex Admin, EXCNUM.COM

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!