I just tried this myself with a phone that has 18.2 and wasn't able to observe it. I made an (unblocked call to the handset) in the call history it shows the number and the location of the caller. Then I blocked it (using Call Kit) and made another call, now it shows the number and below it it says "Name of app: blocked" I tried with another phone with iOS 18.3, this time blocking it before making the call, the result was the same i.e. it shows the call appears in the call log with the name of the app that blocked it. So therefore, how are you reproducing this? However one did I did notice was that if the number is blocked by the OS itself i.e. if you make a call then tap the (i) in the call history, and then tap Block Caller and then make a call, then in that case the call doesn't even appear in the call history. Something has also changed - when iOS 18 first was released, the OS posted a notification when a call was blocked by CallKit, this is no longer happening with iOS 18.2 or 18.3

Still present with 16.2

@JR42abc Did you ever solve this?

@Kevin Elliott A few of app extensions cannot make networks calls themselves, instead the OS makes the network call on behalf of the extension (such as the Message Filter Extension or Unwanted Communication extension). As its not the extension itself making the network call in these situations, then does that affect the situation?

Yes. Is there a way for the server to know the traffic has come from Apple and not a spoofer of Apple? I saw somebody post a question in the past about using Shared Web Credentials to perform basic auth, is that possible?

Search for iOS and app deep linking and url scheme.

Presumably the two apps/companies know something about each other - otherwise what could be the possible point in trying to share a piece of data. So could app A enable deep linking via a url and then app B invokes that url with the token appended.

You can't do this on iOS - you can't trigger your app to run at a specific time or periodically. Your alternatives are to write a server, and you server co-ordinate things and send a push to the app. Alternatively, live activities might be a good fit for what you want to do.

No it isn't

@Kevin Elliot "Why? All other issues aside, I'd expect this to be a fairly rare edge case. Is there a reason why this is particular issue for your users/use case?" As echu says "It's a problem because people add known spammers to their contacts" Exactly. I'm a developer, but also an iPhone user and as a user I do this myself.

I discovered that logging doesn't appear at the point when the extension is enabled and the extension is specifying a set of sub actions. If no sub actions are specified then logging reappears. Its exactly the same as reported in this ticket here, so probably connected to this ticket: https://developer.apple.com/forums/thread/764561

I updated from 16 beta to 16 proper as soon as it was available. (I've also been having my battery issues for a couple of weeks).

My app has an action extension. I have both Xcode 15 and Xcode 16 installed. If I build with Xcode 15 it works, however if I switch to Xcode 16 and build then it no longer works as expected if run on iOS 18 (if built with Xcode 15 and run on iOS 18 it works, if built with Xcode 16 and run on iOS 17 it works. So its the dual combination of Xcode 16/iOS 18 where it doesn't work). If I run the action extension in Xcode there's red output classified as a fault from the com.apple.extensionkit subSystem: -[_EXSinkLoadOperator loadItemForTypeIdentifier:completionHandler:expectedValueClass:options:] nil expectedValueClass allowing {( _EXItemProviderSandboxedResource, NSString, NSMutableData, NSURL, UIImage, NSUUID, NSMutableArray, NSMutableDictionary, NSMutableString, NSDate, NSError, NSArray, NSValue, NSData, NSNumber, NSDictionary, CKShare )} That doesn't get logged when running with Xcode 15

Firebase does some swizzling. Read their documentation and see if setting the FirebaseAppDelegateProxyEnabled flag to false solves your issue.

"Are these crashes being missed by Crashlytics" Crashlytics can only know about a crash if the app runs after a crash has occurred and in addition Crashlytics gets a chance to upload crash reports. If there's a crash that occurs upon app launch, then the app and hence Crashlytics might not get the chance to run long enough in order to upload crash reports before the app terminates due to the current crash. i.e. if its a crash that always or often occurs at app launch, then Crashlytics probably won't have the execution time it needs to upload reports.