I have two repeating DeviceActivitySchedules running in my app and noticed a super strange behavior: whenever I modify Screen Time API permission settings (granting an additional app permission, or removing permission for a different app (completely different unrelated screen time apps from App Store)) all my DeviceActivitySchedules are cancelled and the intervalDidEnd callbacks are called my permission is not modified in this scenario this is a super strange and unexpected behavior is anyone able to reproduce this? for me this happens 100% of the times I do this any known workarounds?

I am currently debugging an issue with DeviceActivityMonitor where the threshold is reached even though the target app (e.g. Instagram) is not being used actively. I noticed that the device with the unexpected behavior had the instagram.com website opened in the Safari web browser (among hundreds of other tabs). That tab was not actively used either (not in foreground, Safari app neither used). However, I was wondering if it can happen that this website is contributing towards the threshold as well even though it is in background and not used? Otherwise I cannot explain myself this strange behavior.

For an upcoming update of one of my apps, I’m facing an issue: The .rate parameter of a AVAudioUnitTimePitch allows me to slow down an audio track without any issues: setting .rate to 0.7 or 0.8 results in an almost perfect playback without changing pitch. However, whenever the .rate parameter is greater than 1 (e.g. 1.1 or 1.15), I’m starting to hear audio artifacts (“flattering”) in the audio output which is not so nice (even at .overlap = 32). Intuitively, I’d’ve thought that speeding up the file should contain less artifacts than slowing it down?? I’ve tried different sample rates (44.1 kHz and 48 kHz), but same result. Grateful for any input on this 🙏

Hello, I am unable to figure out how I tell the FamilyActivityPicker whether it should show apps installed on my personal device (to be used with AuthorizationCenter.shared.requestAuthorization(for: .individual)) or apps installed on my child’s device (authenticated their phone via AuthorizationCenter.shared.requestAuthorization(for: .child)). Is there any parameter or SwiftUI modifier I need to apply? Otherwise, how does the user or the app know which token belongs to them and which token belongs to their child’s device? Radar: FB17020977 Thanks a lot for your help!

Hello! I am excited to try out the new continueInForeground API with iOS 26. I was wondering, what is the suggested way to transport meta data to the main app? Before, with SiriKit intents I would use the .onContinueUserActivity() API and were able to pass a NSUserActivity from the Shortcut to the Main app. Now, with the continueInForeground() call I am not sure – what would be your suggestion? Of course, I can store some data in UserDefaults, but that feels like a workaround. Happy to get some input on this! Thanks a lot and have a great day!

Dear App Store Connect Team! Since Passkeys have been introduced as login option on https://appstoreconnect.apple.com, I am unable to to make use of this new sign in option. I have attached sysdiagnoses, screen recordings, and .har exports in my feedback requests: FB22167539 FB17622414 FB22403813 When I select "Sign in with Passkey", the spinner just keeps spinning. Signing in with password works without issues. I can sign into my Apple ID on other Apple websites using my passkey without problems. Hope that helps! – Frederik

Dear TestFlight Team! I am observing an increasing misuse of TestFlight public and private invites to distribute scam, spam, and potentially malicious builds: I had reported this already in December last year via Feedback assistant, but since the malicious behavior has not stopped, I hope that you can forward my bug reports to the right team: FB21379977, FB21845307 In multiple cases, these builds impersonate well-known apps (e.g. ChatGPT, OpenAI, Meta) by changing the app name and icon after an initial TestFlight approval, misleading users into installing software from unrelated developer accounts. I believe this represents a systemic weakness in the TestFlight review and update flow, enabling targeted phishing or malware distribution outside the App Store review process. My bug reports have attached: TestFlight invitation emails (.eml) Screenshots from TestFlight documenting impersonation behavior ⸻ Steps to reproduce Create a new Apple Developer account. Upload an initial, benign app (e.g. a calculator) as version 1.0.0 and obtain TestFlight approval. Upload a second build: without changing the version number increase build number Change the app name to a well-known product (e.g. “ChatGPT”) Change the app icon to match the impersonated product Invite targeted email addresses to the TestFlight group. Recipients receive an official TestFlight invite and are prompted to install the impersonating app. ⸻ Expected results TestFlight builds that significantly change app identity (name, icon, branding) should: Require additional review, or Be blocked from distribution without re-approval. Developer accounts should not be able to impersonate well-known companies (e.g. “OpenAI Platforms LLC”) without verification. Users should be protected from installing TestFlight builds that materially differ from what was originally reviewed. ⸻ Actual results App name and icon can be changed between TestFlight builds without triggering additional review. TestFlight invites can convincingly impersonate trusted brands. Targeted users may reasonably believe they are installing a legitimate beta. This creates a credible vector for: Phishing (credentials, payment details) Data exfiltration Social engineering attacks I did not install the builds to avoid personal risk, but the attached artifacts should allow Apple’s internal teams to reproduce and analyze the behavior safely. Some more examples: