Hello! I am developing an app (Homie) which uses HomeKit to give users access to their HomeKit devices + accessories via the Mac‘s Menu Bar. One feature is also to pin sensors (e.g., temperature) to the Menu Bar: To get updates to sensor values I am using the HMAccessoryDelegate‘s didUpdateValueForCharacteristic method. Some users are reporting that updates to Homie are passed along very infrequently und unreliably. I have set up a test with the HomeKit Accessory Simulator in which values are consistently passed along instantly. This problem is hard to debug for me, that‘s why I‘m asking what recommended ways would be to tackle this. I noticed that sometimes the HomeKit framework does not deliver updates unless the Home app is opened on my Mac or iPhone. But not sure if this is expected or related to that problem and what I can do about it. Any feedback & help is appreciated 🙏 Reference:

Hello good morning lovely ShazamKit team! I was wondering if there's a way to evaluate the result (SHMatch) to be able to estimate if this is a very good match (the catalog is very certain that this is correct), or if this is at the lower end of the spectrum of certainty. Thanks a lot and have a nice day! – Frederik

Hello! I am looking to access data on how many times (on a specific day, week, or month) an alphanumeric subscription offer code has been redeemed (to track affiliate marketing). Right now, I am using the Reporter.jar tool like this: java -jar Reporter.jar p=Reporter.properties a=1234567 m=Robot.XML Sales.getReport 123456789, Subscription, Summary, Daily, 20230120, 1_3 As a result, a long list of subscription events is downloaded, however it is not clear which date a particular event did occur on. It seems like actually they pile up with every additional day. These are the columns that I can see: App Name, App Apple ID, Subscription Name, Subscription Apple ID, Subscription Group ID, Standard Subscription Duration, Subscription Offer Name, Promotional Offer ID, Customer Price, Customer Currency, Developer Proceeds, Proceeds Currency, Preserved Pricing, Proceeds Reason, Client, Device, State, Country, Active Standard Price Subscriptions, Active Free Trial Introductory Offer Subscriptions, Active Pay Up Front Introductory Offer Subscriptions, Active Pay As You Go Introductory Offer Subscriptions, Free Trial Promotional Offer Subscriptions, Pay Up Front Promotional Offer Subscriptions, Pay As You Go Promotional Offer Subscriptions, Free Trial Offer Code Subscriptions, Pay Up Front Offer Code Subscriptions, Pay As You Go Offer Code Subscriptions, Marketing Opt-Ins, Billing Retry, Grace Period, Subscribers As you can see, a date is not among them. Would be great if anyone has feedback on how to make this happen!

Hello! I am using the eventDidReachThreshold callback in the DeviceActivityMonitor in order to shield a target app after the user has spend x amount of time on it (e.g. x = 5 minutes). Many times this works fine, and I can trigger my shield after the specified threshold has been met. However sometimes, when they leave the target app before the threshold has been reached, the eventDidReachThreshold callback gets called randomly while they are doing something else on their phone (e.g. using a different app, on the Home Screen, phone locked…). From my perspective this does not make sense, since they are not actively spending time on the target app, and that time should not be counted towards the target app’s threshold. And it is also very confusing for the users because they will then find a blocked target app even though they haven’t used their time budget completely. This is not related to the intervalDidStart / intervalDidEnd callbacks, because they are not correlating with the timing of when the eventDidReachThreshold callback is called unexpectedly. Any ideas what this could be related to?

Hello, I am using a DeviceActivityEvent to limit access to an app after the user has spent x minutes on it. Sometimes it can happen that a DeviceActivitySchedule spans from 11:55pm - 12:25am (just an example). In these cases, I have noticed, the DeviceActivityMonitorExtension’s eventDidReachThreshold is not called after the user has reached the threshold time interval in the observed app. I assume this is because we have transitioned over midnight and something weird happens to the DeviceActivitySchedule. I’ve tried adding the day components to the DeviceActivitySchedule as well, but then it fails completely. Any advice how to handle this? I could, of course, create two separate DeviceActivitySchedules: one for before midnight, and one for after. But depending on the user’s real app usage that could lead to slightly different (and unexpected) behavior.

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:

My app Homie allows users to pin certain values, accessories or scenes to their menu bar for quick access, such as HMAccessory. To remember which devices and accessories a user has pinned to the Menu Bar, I store their uniqueIdentifier. However, I noticed that from time to time this uniqueIdentifier changes (this often happens after restarting the computer or installing a macOS software update). In this case, the device is not re-identified and the pinned-status is lost. The user is confused, because they think my app didn't store their information probably. And I am confused because the identifier is not consistent across app-starts. For reference: I am not asking to have consistent identifiers between different devices, I am asking to have consistent identifiers on the very same device. Reference: FB9052957

I am using the DeviceActivityMonitor eventDidReachThreshold functionality, but it became very unreliable on the iOS 17.5 beta. Anyone experiencing similar problems? Any known workarounds?

Hello fellow Screen Time Fans! I am encountering a strange problem since I started working with the Screen Time framework, and I don’t know what I’m doing wrong: Imagine the app has two ManagedSettingsStores: one to block apps during work hours (let’s say from 9am to 5pm) and one to block apps in the evening (let’s say from 5:30pm till midnight). Imagine, the user has blocked Instagram in both. When the user has Instagram open at 4:59pm it shows the Block during Work Hours Shield (so far, so good). At 5pm, the shield is removed, and the user can use Instagram. Then, at 5:30 the a shield is activated again: this time, the Instagram token is added to the evening store. However, there is no new ShieldConfiguration requested from the ShieldConfigurationDataSource. Instead, the previous shield from the work hour block is re-used and shown. To me, it appears that the Framework does not request new shields, when the token is moved from one store to another while the app remains in foreground. The Shield is only re-rendered when the user closes the shielded app and re-opens it. This is really confusing behavior and I would like to fix it. Did anyone here encounter something similar, and has a suggestion or workaround? My feedback is also documented in FB14237883.