I am reporting what appears to be a serious integrity flaw in Safari under iPadOS 26.3 (and lower) that materially undermines the reliability of Screen Time parental controls. This is not merely a UX inconsistency but a functional contradiction within a system explicitly marketed and positioned as secure parental control infrastructure. Device / Environment Device: iPad Air M3 13" (2025) OS: iPadOS 26.3 Safari (system version) Screen Time enabled with active restrictions Child account (10 years old) Background We deliberately chose an Apple device for school use based on the expectation that Apple’s system-level parental control mechanisms — especially Screen Time — are robust, tamper-resistant, and technically consistent. Screen Time is configured with: App limits Downtime Parental controls enabled with limited web content restrictions (school requirements prevent strict blocking) Safari enabled (mandatory for educational use) further parental control restrictions Because aggressive website blocking would interfere with legitimate school activities, monitoring Safari browsing history is a central supervisory mechanism. When Screen Time is active: Clearing the entire browsing history via Safari is correctly blocked. Clearing history via system settings is correctly blocked. The system explicitly communicates that deletion is not permitted due to Screen Time restrictions. This behavior establishes a clear user expectation: Browsing history is protected against manipulation. The Issue Despite the above safeguards, individual browsing history entries can be deleted easily and silently through the address bar suggestion interface. This creates a structural contradiction: Full deletion is blocked. Selective deletion — which is arguably more problematic — remains possible. Steps to Reproduce Enable Screen Time with restrictions that prevent deletion of browsing history (for example on a student device with a child account). Open Safari and visit any website. Confirm it appears in Safari history. Tap the Safari address bar. Type part of the URL or page title. Safari suggests the previously visited page below the address bar. Swipe left on that suggestion. A red “Delete from History” button appears. Tap it. Actual Result The entry disappears immediately: No Screen Time PIN required No authentication request No warning No restriction triggered No parental notification No audit trace visible Deletion occurs silently and irreversibly. Expected Result When Screen Time is configured to prevent browsing history deletion: Individual entries must not be deletable Deletion must require Screen Time authentication Anything else defeats the protective purpose of the restriction. Real-World Impact In practical use, this allows minors to selectively sanitize browsing history while preserving a seemingly intact record. In our case, this method is widely known among classmates and routinely used to conceal visits to gaming or social media platforms during school hours. The technical barrier to exploitation is negligible. This results in: A false sense of security for parents A discrepancy between advertised functionality and actual system behavior A material weakening of parental control integrity When a system explicitly blocks full history deletion but permits silent selective deletion, the protection mechanism becomes functionally inconsistent and unreliable. Given that Screen Time is publicly positioned as a dependable parental control framework, this issue raises concerns not only about implementation quality but also about user trust and reasonable reliance on advertised safeguards. Request Please classify this as a parental control integrity and trust issue. Specifically: Disable individual history deletion while Screen Time restrictions are active OR Require Screen Time passcode authentication for deleting single entries Screen Time is presented as a secure supervisory environment for minors. In its current implementation under iPadOS 26.3 and before, that expectation is technically not met. This issue warrants prioritization.

Title: App stuck in Kids Category review loop — never intentionally published as Kids Our education app has been on the App Store since 2020 under the Education category. We recently submitted an update and it keeps getting rejected under Guideline 1.3 - Kids Category. The problem: we have never intentionally published our app under the Kids Category. Our current App Store Connect configuration is: Age Categories and Override: Not Applicable Calculated Age Rating: 4+ Primary Category: Education Secondary Category: Games No "Made for Kids" designation is selected anywhere. Here is the timeline: Feb 13: Rejected — "You have selected the Kids Category for your app" — asked us to add parental gates for links, purchases, etc. Feb 18: Rejected again — "Your app does not appear to be designed for kids aged 11 and under" — told us to resubmit without Kids Category designation. We replied with screenshots showing "Not Applicable" is selected and asked what else needs to change. Feb 19: Rejected again — "Your app was previously approved for the Kids category" — told us to resubmit under a new App ID. We replied explaining that we never published under Kids Category and that creating a new App ID would mean losing years of reviews, ratings, and user history. Feb 20: Same rejection, same template response about Kids Category. We have scheduled a Meet with Apple appointment but it is not available soon. Meanwhile our update is blocked. Our questions: Has anyone experienced a similar situation where their app was flagged as "previously approved for Kids" when it was never intentionally submitted under that category? Is there a way to verify which version (if any) was approved with the Kids designation? We cannot find this information in App Store Connect. Has anyone successfully had this flag removed without creating a new App ID? If we did have to comply with Kids Category guidelines, would that remain a permanent requirement even though "Not Applicable" is now selected? Any advice or similar experiences would be appreciated. We have been going back and forth with the review team for over a week and the responses do not address our specific situation.

Hi! Our app has been rejected several times now. We first selected the "made for kids" category because that was the age recommended by apple. Everything went fine at first but now, two updated later, we are starting to get rejected. We unchecked the made for kids box but even after that we are still not getting approved. We have tried to explain our issue to apple support but they aren't giving us any good answers. Is there any way to resolve this issue? We are really in the need of help.

Hi Community, I'm excited to share R Helper, a speech practice app I built with accessibility as the core focus from day one. App Store: https://apps.apple.com/app/speak-r-clearly/id6751442522 WHY I BUILT THIS I personally struggled with R sound pronunciation growing up. It affected my confidence in school and job interviews. That experience taught me how important accessible practice tools are. R Helper helps children and adults practice R sounds with full accessibility support. ACCESSIBILITY FEATURES IMPLEMENTED VoiceOver - complete navigation and feedback Voice Control - hands-free operation Dynamic Type - scales to large accessibility sizes Reduce Motion - respects user preference Dark Mode - user controllable High Contrast compatibility Differentiate Without Color THE CHALLENGE Most speech practice apps ignore accessibility. I wanted to change that and prove that specialized educational apps can be fully accessible. KEY FEATURES Works 100% offline, no internet needed Zero data collection, privacy first Generous free tier with all accessibility features included 10 story missions with gamification 7 languages supported including RTL for Arabic LESSONS LEARNED Accessibility is not hard when you prioritize it from the start. VoiceOver labels and hints make a huge difference. Testing with accessibility features enabled is essential. Standard SwiftUI components handle most accessibility automatically. Reducing motion significantly helps users with vestibular issues. TECHNICAL DETAILS Built with SwiftUI, targets iOS 17 and up. Universal app for iPhone and iPad. Fully offline using CoreData and local storage. No third party analytics, privacy focused. QUESTIONS FOR THE COMMUNITY What accessibility features do you find users request most? How do you test accessibility features efficiently? WHATS NEXT I'm currently working on expanding the word library, adding more story content, improving haptic feedback Thanks for reading. Nour

We have a STEM learning app for kids, and I've been exploring ways to get it listed under the Education Ecosystem Partner (K–12) collection on the App Store. I couldn’t find a clear pathway or guidelines for eligibility. Could you please point me to the relevant documentation or let me know if there's someone I should reach out to for this?

"If your app includes any links outside the app, or offers any in-app or other purchasing opportunities, make sure these are behind a parental gate" Super Awesome and Kidoz are proving with a parental gate on ad click and they also claim that all ads are manually approved (another criteria for ads in Kids apps). So these two are the only ad networks we can use moving forward. Or we can use ad networks like Admob as well? I dont intend not to be in Kids category - so leaving Kids category is not a choice.

We're using RealityKit to create a science education AR app for iOS, iPadOS, and visionOS. In the WWDC25 session video "Bring your SceneKit project to RealityKit" https://developer.apple.com/videos/play/wwdc2025/288 at 8:15, it's explained that when using RealityKit, RealityView should be used in all cases, whereas in the past, SceneKit required SCNView, SceneView, or ARSCNView, depending on an app's requirements. Because the initial development of our app on iOS predates iOS 18's RealityView, our app currently uses ARView to render RealityKit AR content on iOS and iPadOS. Is it recommended that we migrate to RealityView, or can we safely continue using our existing ARView implementation? We'd prefer to avoid unnecessary development cost. If migrating from ARView to RealityView is recommended, what specific benefits should we expect from this transition? Thank you.

I am creating a prototype with the new Screen Time API introduced by Apple. The issue I am facing is, Applications installed in child device is not showing in parent device with FamilyActivityPicker. It is showing in Child device and apps can be shielded from child's device. Can some one describe, how to list the apps in parent's device. Both Device are running in iOS 15.3. Both falls in same family group Child is under 13 yrs old Screen Time enabled in both device and parent device can see child in Screen Time.