Delete me

I'm currently finding it impossible to get a text filtering extension to be invoked when there's an incoming text message. There isn't a problem with the app/extension because this is the same app and code that is already developed, tested, and unchanged since I last observed it working. I know if there's any history of the incoming number being "known" then the extension won't get invoked, and I used to find this no hindrance to testing previously provided that: the incoming number isn't in contacts there's no outgoing messages to that number there's no outgoing phone calls to the number. This always used to work in the past, but not anymore. However, I've ensured the incoming text's number isn't in contacts, in fact I've deleted all the contacts. I've deleted the entire phone history, incoming and outgoing, and I've also searched in messages and made sure there's no interactions with that number. There's logging in the extension so I can see its being invoked when turned on from the settings app, but its not getting invoked when there's a message. The one difference between now and when I used to have no problem with this - the phone now has iOS 18.5 on it. Its as if in iOS 18.5 there ever was any past association with a text number, its not impossible to remove that association. Has there been some known change in 18.5 that would affect this call filtering behavior and not being able to rid of the incoming message caller as being "known" to the phone? Update I completely reset the phone and then I was able to see the the message filter extension being invoked. That's not an ideal situation though. What else needs to be done beyond what I mentioned above in order to get a phone to forget about a message's number and thus get an message filtering extension to be invoked when there's a message from that number?

Its possible to add the Declared Age Range entitlement to extensions, in particular I'm looking at a Notification Service Extension. However the DAR requestAgeRange() API takes a view controller as a parameter. Presumably therefore its not possible for a notification service extension to obtain the age range itself directly? Yes the extension can read it from shared groups if the app reads it and set it into the group. However the scenario I'm thinking of is this: App runs and gets the age range. Sets its functionality accordingly. The server sends pushes which are intercepted by the notification service extension, the extension adjusts its functionality based upon what the app wrote to shared groups The user changes the age range setting, but the app doesn't run. The extension keeps receiving pushes but its functionality is now out of sync with the age range as its not able to obtain it directly

From watching the video on App Attest the answer would appear to be no, but the video is a few years old so in hope, I thought I would post this question anyway. There's several scenarios where I would like a notification service extension to be able to use App Attest in communications with the back end(for example to send a receipt to the backend acknowledging receipt of the push, fetching an image from a url in the push payload, a few others). Any change App Attest can be used in by a notification service extension?

If there is this situation: A text message is sent from a sender and gets classified as junk (by a text filtering extension) with the result that it gets send to the spam folder as expected. A text message with different content is sent from the same sender and gets classified as allowed, however it also gets sent to the spam folder. If the above is repeated but after step 1 the message is deleted, then in step 2 the message doesn't get sent to the spam folder. So the presence of the message from step 1 being in the spam folder is having an effect on the behavior of step 2. Expected beahavour (if so, why?), or a defect?

When Live Caller ID first came out I experimented with it and got it working using the Example PIR database. All my links from that time are now out of date and no longer work, however I seem to have found where the PIR database example and documentation has moved to (https://swiftpackageindex.com/apple/pir-service-example/main/documentation/pirservice/testinginstructionslivecalleridlookup) But what I can't find is an exact definition of the the logo size/max size/dimensions/format should be. My memory from that time is that it was very pernickety, and if things weren't exactly right, the logo wasn't displayed. I can remember the format had to be HEIC to get it to work. Looking through the documentation however, I can't see exact requirements specified. My question is - for the Live Caller ID logo what are the exact image requirements, and where are they documented?