Its the same thing with Crashlytics too. What might be different about these two packages that is resulting in this behaviour?

@Engineer I've created a minimal XCode project that recreates this issue and attached to FB16148083 along with a new accompanying sysdiagnose. I'm very surprised nobody else has reported this issue as there's a lot of apps using message filtering in the app store. There's a very similar problem that manifested with XCode 15. If the app was built with XCode 15 then there would be no issues when run on iOS version < 18, but if run on iOS 18 the exact same issue as this would arise (this issue is when built with XCode 16, it runs on iOS 18+ but the issue manifests when run on iOS < 18)

@Apple Sysdiagnose uploaded

Thanks. It says only devices in developer mode can access the domain. To clarify that means any iPhone can be used, provided developer mode is enabled in Settings. The phone doesn't been to additionally be registered with the developer account?

That in turn comes back to the question how are the credentials applied when the system makes the connection to the server? It isn't the message filter extension which is making the connection to the server, and the MFE can't directly affect the http payload/header/signing etc. The MFE tells the OS that the server should be contacted, but it has no influence over how that is done, nor what the payload or signing applied is. So that is where my misunderstanding is coming from. As the MFE can't affect the HTTP payload, how are credentials getting applied to that payload?

Unfortunately I'm still confused. It seems to be being suggested that the app uses App Attest for validation between the app and the server. Then once that validation has been performed, the Message Filter Extension can see that the app/server has been validated and will start functioning. However what does that have to do with the server then subsequently validating https traffic coming from the System which is what the question is about? Once the MFE is functioning, when the handset receives an SMS, the System is going to invoke the MFE and the extension may instruct the system to contact the server. When the system contacts the server, then the server still has no way of knowing if the traffic is coming from a phone or an impersonator of a phone. The fact that the app has performed attestation seems irrelevant to me? The payload that the iPhone system sends to the server is going to be identical whether the app has performed attestation or not. Therefore, when the server receives some incomming https, it cannot distinguish if that has originated from an iphone, or some something impersonating an iphone. My apologies, I just seem to have a big disconnect in grasping the point that is being made in this thread.

@Kevin Elliott Returning to the original question here: In other words, how can the server verify that the request is valid and coming from the iPhone and not from some spoofer? The quoted part of the original question, in isolation from the sentence that preceeds it, doesn't accuratly represent the actual focus of the question. The first sentence of the question is: "If an app has a text filtering extension and associated server that the iPhone OS communicates with, then how can that communication be authenticated?" The word "that" in "how can that communication be authenticated" refers to the earlier part of the sentence "and associated server that the iPhone OS communicates with". i.e. it is referring to the communication between the OS and the server, not between the application and the server. The question is in reference specifically to a message filtering extension. When the associated server for a MFE is contacted, it is not contacted directly by the MFE nor by the app, instead it is contacted by the iPhone OS. The question therefore would be better off explicitly phrased as: "How can the server verify that the request which is being sent by the OS on behalf of the app/Message FIlter Extension is valid and coming from the iPhone and not from some spoofer? My apologies is this wasn't clear and the question has to be devided by careful study of the specific wording of the question. I get the impression this thead is answering a different question - question about how the server can authenticate https trafic coming from the app, rather than from the OS. If it hasn't then I'm still just not understanding at all how app attest fits into the picture in this specific case. With app attest the server is validating requests from the app. In the case of a Message Filter Extension there are no requests coming from either the extension nor from the app to the server.

The last part of the post got chopped off, I was quoting from the documentation "Associated domains establish a secure association between domains and your app.". How is that security established? If more than one app can contain the same domain within its entitlement (from what I have read it is possible for different apps, even from different developers, to contain the same domain) then how does the server know if a request came from an app listed in its app association file versus a request that came from an app which isn't in its app association file?

@Kevin Elliott So the app would run code referenced in the documentation for App Attest, rather than the Message Filter Extension, however when the OS contacts the server its pulling stuff from the keychain which was set in the app? There's a past question here about using (and failing) to use Web Credentials in the Message Filter Extension, should they have been calling that code from the app and not the extension? https://developer.apple.com/forums/thread/758611

AppAttest documentation says: "...Then you use the service to cryptographically sign server requests using the certified key." With text filtering extensions, as the server request is coming from the OS, not from the app/extension, then the app/extension presumably won't be able to sign the server request?

You just said Apple omit it from the payload for privacy reasons, then go on to propose explicity adding it, which would negate the very reason Apple omitted it. However, its not possible to modify the payload anyway, it is transmitted by the OS and the extension does not have the opportunity to change it.

Hello, is there any possibilities using shared web credentials for some form of authentication? P.S. The domain is in the info.plist, isn't that easily inspectable?

Feedback submitted FB15266709 BTW there's a copy/paste typo in the original posting, this will cause the issue: response.transactionalSubActions = [.transactionalCarrier, .transactionalHealth, .transactionalPublicServices, .transactionalFinance, .transactionalWeather, .transactionalRewards, .transactionalOrders, .transactionalOthers, .transactionalReminders] response.promotionalSubActions = [.promotionalOffers, .promotionalOthers, .promotionalCoupons] Or also this would too: response.transactionalSubActions = [ILMessageFilterSubAction.transactionalHealth] response.promotionalSubActions = [ILMessageFilterSubAction.promotionalCoupons]

Thank you that did the trick. However, do you happen to know the specifics of using ContactAccessButton via UIKit? If I display it, and click on its button, then I can see that its expecting a callback/delegate, however I don't see how to can add one programmatically using it in a UIViewController/UIView/Storyboard way.

AFAIK though its not possible to create a different account? When you create an account you have to supply info like your business sku, and legally registered business name and address and banking info etc. etc. The same company cannot create multiple developer accounts can they?