I received this message "Your app provides a limited user experience as it is not sufficiently different from a web browsing experience." It needs to be more robust and native. When submitting this the app had: Push Notifications Core Location Phone Contact access So now I am adding: Haptic feedback Quick touch actions A more robust add to calendar function. (the app does scheduling) But is this enough for resubmission? I am not really sure what is considered "robust" and "more native".... that is vague.

Does our app need to check the location or can we fully reply on this API to decide whether we wanna comply for the law of places that requires age range information? Looks like it's only covering Texas now..? would it add other places by apple..? And also this API is really hard to test a user in other places, Iike I don't know a user in Brazil gonna return true for false now, but the law in Brazil also requires the age information.

Reference: FB21797091 / Related to thread 807695 Hello, I have already submitted a report regarding this issue via Feedback Assistant (FB21797091), but I would like to share the technical details here to seek further insights or potential workarounds. We are experiencing a technical regression where Universal Links and Shared Web Credentials fail to resolve for Internationalized Domain Names (IDN) specifically on iOS 16 and later. This issue appears to be identical to the one discussed in thread 807695 (https://developer.apple.com/forums/thread/807695). Technical Contrast: What works vs. What fails On the exact same app build and iOS 16+ devices, we observe a clear distinction: Standard ASCII Domain (onelink.me): Works perfectly. (Proves App ID and Entitlements are correct) Internal Development Domain (Standard ASCII): Works perfectly. (Proves our server-side AASA hosting and HTTPS configuration are correct) Japanese IDN Domain (xn--[punycode].com): Fails completely. (Status: "unspecified") Note: This IDN setup was last confirmed to work correctly on iOS 15 in April 2025. Currently, we are unable to install the app on iOS 15 devices for live comparison, but the regression starting from iOS 16 is consistent. This "Triple Proof" clearly isolates the issue: the failure is strictly tied to the swcd daemon's handling of IDN/Punycode domains. Validation & Diagnostics: Validation: Our Punycode domain passes all technical checks on the http://Branch.io AASA Validator (Valid HTTPS, valid JSON structure, and Content-Type: application/json). sysdiagnose: Running swcutil on affected iOS 16+ devices shows the status as "unspecified" for the IDN domain. Symptoms: Universal Links consistently open in Safari instead of the app, the Smart App Banner is not displayed, and Shared Web Credentials for AutoFill do not function. Request for Resolution: We request a fix for this regression in the swcd daemon. If this behavior is a specification for security reasons, please provide developers with a supported method or workaround to ensure IDN domains function correctly. We have sysdiagnose logs available for further investigation. Thank you.

Memory leak in CarPlay when using CPTabBarTemplate Reproduced using the code example "Integrating CarPlay with Your Music App" from the official Apple documentation - https://developer.apple.com/documentation/carplay/integrating-carplay-with-your-music-app Steps to reproduce the leak: Download and run the example on CarPlay. Select the Settings tab. Click the first item in the list "Use Apple Music". Click Back button. Repeat steps 3 and 4 several times. Open Debug Memory Graph in xCode and search for "CPGridTemplate" - the count will be greater than 0. Conditions under which the memory leak disappears: If you open and switch to all tabs one by one, the leak disappears.

I've tried pass different value like 13,16,18, but I don't see any difference..? could anyone tell what could happen differently if I pass a different value here?

Subject: iOS Fails to Fetch AASA File for Internationalized Domain Names (IDN) in Unicode or Punycode Format Dear Apple Developer Relations Team And Community Members, We are reporting a critical bug in the iOS Associated Domains feature that prevents Universal Links from working for apps using Internationalized Domain Names (IDN). Problem Description: The iOS operating system does not attempt to download the apple-app-site-association (AASA) file for domains containing non-ASCII characters (e.g., diacritics, Cyrillic). This failure occurs regardless of whether the domain is specified in the app's entitlements in its human-readable Unicode format (e.g., montréal.ca) or its encoded Punycode format (e.g., xn--montral-fya.ca, xn--e1afka0abm4b.xn--p1ai). Without fetching and validating this file, Universal Links are not activated, and the system fails to establish a connection between the website and our app. Steps to Reproduce: Create an app with the Associated Domains entitlement enabled. Add an IDN to the entitlement. We tested both formats: Format A (Unicode): applinks://montréal.ca Format B (Punycode): applinks://xn--montral-fya.ca Host a valid AASA file on our server at the correct, accessible well-known URLs for both domain representations: For montréal.ca: https://montréal.ca/.well-known/apple-app-site-association and https://xn--montral-fya.ca/.well-known/apple-app-site-association Install the app on a device running the latest iOS version. Monitor network traffic using a tool like Charles Proxy. Observed Result: No HTTP GET request is made to any of the AASA URLs for the domains montréal.ca (in either Unicode or Punycode format) upon app installation. The system does not initiate the domain validation process. In contrast, for a standard ASCII domain (e.g., applinks://example.com), the AASA fetch is triggered immediately and is observed in the network log. Expected Result: iOS should correctly resolve the Internationalized Domain Name (whether specified in Unicode or Punycode format in the entitlement) and perform an HTTP GET request to fetch the AASA file from the /.well-known path, identical to its behavior for ASCII domains. Evidence & Configuration: Our server is configured correctly: SSL certificates are valid, the AASA file is served with the correct application/json MIME type, and is directly accessible via a browser or curl. The AASA file's syntax has been validated and is correct. The issue is reproducible on the latest versions of iOS. Impact: This bug blocks a core platform feature for millions of users in regions that use non-Latin scripts (e.g., France, Russia, China, Arab states). It makes it impossible to use Universal Links with our primary domains, severely degrading the user experience and forcing us to seek suboptimal workarounds like registering separate ASCII domains. Request: We kindly request that you investigate and log this issue as a bug in iOS and forward it to the appropriate engineering team for a fix in an upcoming update. We are prepared to provide any additional information, demo projects, or server access to assist in diagnostics. Thank you for your attention to this serious matter.

Hello Apple Developer Community, I'm working on implementing App Clips for a restaurant platform and need guidance on configuring custom App Clip experiences using URL redirects. Context: We have multiple restaurant locations, each needing branded App Clip cards (custom image, title, subtitle). With hundreds of tables across many venues, creating individual App Clip experiences for each table in App Store Connect isn't scalable. Currently: Using a single, generic App Clip experience for all locations => https://example.com Desired Flow: Customer scans QR code at restaurant table ↓ https://example.com/123 ↓ iOS fetches URL ↓ Server responds with 302 redirect ↓ https://example.com/brands/le-pain-quotidien?venue=abc123 ↓ iOS displays App Clip card with "Le Pain Quotidien" branding ↓ User taps "Open" → App Clip launches with correct context What I've Tried: Configured multiple App Clip experiences in App Store Connect Implemented 302 redirects from short URLs to branded URLs Tested various redirect configurations without success Questions: Does iOS fetch and follow redirects before displaying the App Clip card, or does it only use the originally scanned URL? What App Clip experience URLs should be configured in App Store Connect for this redirect scenario? Are there specific HTTP headers or redirect requirements for iOS to properly recognize the final destination? Should the App Clip experience be registered for example.com/123 or example.com/brands/le-pain-quotidien? Reference: Apple's documentation suggests this is possible: https://developer.apple.com/documentation/AppClip/configuring-the-launch-experience-of-your-app-clip#Use-short-URLs-or-redirects Has anyone successfully implemented custom App Clip cards using URL redirects? Any guidance on the correct configuration approach would be greatly appreciated. Thank you!

Environment: Xcode 26 iOS 26 Also tested on iOS 18 (working correctly) Description: I'm experiencing a behavior change with URL(fileURLWithPath:) when the filename starts with a tilde (~) character. On iOS 18, passing a filename like ~MyFile.txt to URL(fileURLWithPath:) treats the tilde as a literal character. However, on iOS 26, the same code resolves the tilde as the home directory, resulting in unexpected output. Minimal Example: let filename = "~MyFile.txt" let url = URL(fileURLWithPath: filename) print(url.lastPathComponent) Expected Result (iOS 18): ~MyFile.txt Actual Result (iOS 26): 924AF0C4-C3CD-417A-9D5F-733FBB8FCF29 The tilde is being resolved to the app's container directory, and lastPathComponent returns the container UUID instead of the filename. Questions: 1. Is this an intentional behavior change in iOS 26? 2. Is there documentation about this change? 3. What is the recommended approach for extracting filename components when the filename may contain special characters like ~? Workaround: Using NSString.lastPathComponent works correctly on both iOS versions: let filename = "~MyFile.txt" let result = (filename as NSString).lastPathComponent // Returns: "~MyFile.txt" ✅ Is this the recommended approach going forward?

I found currently there is no way to revoke sharing age to an app after I shared to it, no matter in testing or in app settings

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

My app is configured with the App Clip experiences, and a Clip App card pops up when an NFC tag is scanned—whether the host app is not launched, running in the background, or active in the foreground. I want to prevent the App Clip card from popping up when the host app is in the foreground; how can this be achieved?

In a class, I call the following (edited to simplify, but it matches the real case). If I do this: func getData() -> someClass? { _ = someURL.startAccessingSecurityScopedResource() if let data = NSData(contentsOf: someURL as URL) { do { let unarchiver = try NSKeyedUnarchiver(forReadingFrom: data as Data) print((unarchiver.decodeObject(of: [NSArray.self, someClass.self /* and few others*/], forKey: oneKey) as? someClass)?.aProperty) if let result = unarchiver.decodeObject(of: [NSArray.self, someClass.self /* same other types*/], forKey: oneKey) as? someClass { unarchiver.finishDecoding() print("unarchived success") return result } else { unarchiver.finishDecoding() print("unarchiving failed") return someClass() } } catch { return nil } } I get a failure on log : unarchiving failed But if I comment out the print(unarchiver.decodeObject) - line 8, it works and I get unarchived success // print((unarchiver.decodeObject(of: [NSArray.self, someClass.self /* and few others*/], forKey: oneKey) as? someClass)?.aProperty) However, when I do exactly the same for another class (I've compared line by line to be sure), it works even with the print statement. What could be happening here ?

Hello, We are using a Message Filter Extension (ILMessageFilterExtension) to classify SMS/iMessage content (junk vs allow) in our app. After testing on iOS 26.1, we want to confirm whether there are any behavioral, performance, or API-level changes that impact message filtering, such as: Changes in how often the filter extension is invoked Differences in classification accuracy or system overrides New privacy, entitlement, or permission-related restrictions Execution time limits or memory constraints Any changes specific to iMessage vs SMS filtering We did not find any explicit mention of Message Filter Extensions in the iOS 26.1 release notes and would like to confirm whether the existing behavior from previous iOS versions remains unchanged. Has Apple introduced any known or undocumented changes in iOS 26.1 that developers should be aware of when supporting Message Filter Extensions? Sometime I also found unpredictable behaviour on iOS version 18.5 or below, like sometime it works but sometimes starts working. Thanks in advance for any guidance.

How should i write and not show this sensitive error?

There is an inconsistent issue when views are rendered from the Device Activity Report Extension. This issue is noticeable only on release versions and it works fine in debug mode. Around 80% of the times, the Report Views return blank screen and this is only the case when a weekly/monthly filter is used. Although, it works as expected for daily report views. My questions are: How are all the Report Activity Views working fine in debug mode but not in release mode? How the daily activity filter works fine in the release mode but the weekly/monthly filters don't work? Is this because of a memory limit issue in the extension? As of now, I have the family-controls(distribution) entitlement only for the app and for the extensions I only have family-controls(development) entitlement. Do I need to request for family-controls(Distribution) entitlement even for the extensions? I have seen threads on the forum mentioning the blank screen issue associated with the DeviceActivityReport but haven't found a solution to it. Any suggestions/feedback would be of great help, thanks.

The documentation says: The caching behavior of the NSURL and CFURL APIs differ. For NSURL, all cached values (not temporary values) are automatically removed after each pass through the run loop. You only need to call the removeCachedResourceValueForKey: method when you want to clear the cache within a single execution of the run loop. The CFURL functions, on the other hand, do not automatically clear cached resource values. The client has complete control over the cache lifetimes, and you must use CFURLClearResourcePropertyCacheForKey or CFURLClearResourcePropertyCache to clear cached resource values. https://developer.apple.com/documentation/foundation/nsurl/removeallcachedresourcevalues()?language=objc Is this really true? In my experience I've had to explicitly remove cached resource values via -removeAllCachedResourceValues or removeCachedResourceValueForKey: otherwise the URL contains stale values. For example on a URL that no longer exists I attempted to read NSURLIsHiddenKey and the last value was already cached. Instead of getting a NSFileNoSuchFileError I get the old cache value unless explicitly call -removeCachedResourceValueForKey: first and I'm fairly certain the value was cached on a previous run loop churn.

Hello I'm using this sdk DeclaredAgeRange to get the user age range When I'm doing in debug mode using sandbox account it is working as expected and I can get the user age range But when I tried in TestFlight build using sandbox account it is not working and it is always return the age range 18+ and also isEligibleForAgeFeatures API is always returning false Any advise on this?

I am having an app in which we are using NEHotspotHelper to detect wifi changes. when I try to kill the app and network change detected, we are seeing logs in NEHotspotHelper* module and after that we are able see the logs indicating app launched in background. [Application] application(_:didFinishLaunchingWithOptions:), UIApplicationState: 2 But when I checked in the app stack, I couldn't find the app. Then I clicked icon to launch the app, it launched without splash screen as if it came from background. Need your support to understand this is expected behaviour.

I would like to share an issue observed during app development. When changing Bluetooth settings from the system Settings app without using multitasking, the app does not terminate but instead logs the user out. However, when changing Bluetooth settings while using multitasking, the app terminates completely. In this context, I would like to understand: Whether there is any system behavior that causes the app to refresh or restart when Bluetooth settings are changed And why the app behavior differs in a multitasking environment, particularly in terms of app lifecycle handling Any insights into these behaviors would be greatly appreciated.

Hey there, I’m wondering if there is a CRUD API for Apple Notes? I just saw once that it’s possible through a Apple Script on Mac. But the problem for me is that the app should also run on iOS. Does someone have an idea how to approach this?