Truecaller uses 4 call extension, Hiya has 3 and RoboKiller has 2. But why? There's no limitation or lack of functionality from just using one, why have multiple with the additional complexity of managing multiple ones within the app. I can't think of any possible reason for this, so I'm mystified why so many call blocking/identification apps have lots of them. Are they storing data in a database which doesn't support lazy loading / the ability to read a set of data in chunks, so instead they create multiple databases?

I added two actions extensions to my app, however if from the iPhone's call history, Share Contact is selected, then Edit Actions, then only one of the action extensions is visible (they both have the same NSExtensionActivationRule, but the intention being they'll have different action names and perform different actions). So presumably, having more than one action extension just isn't possible. Could somebody please confirm if that is the case or not.

After not happening to me for a few months, this issue has started hitting me again with currently %100 reproducability. If turn on VPN on my Mac then instantly the developer certificates within the keychain become untrusted. But that's not all, if VPN is then turned off the certificates do not revert to their trusted status but remain untrusted. The consequence of this is that if VPN is turned on and then a build is perform, it fails, and the only way to fix things is to delete the cert(s) from they keychain and re-install them. As a remote worker, having this happen several or even dozens of times a day is incredibly annoying and frustrating. This issue has been occurring for literally years, sometimes it occurs very often, others while its quiet for a while, and has spanned multiple versions of Xcode and Mac OS. So whatever the cause is its endemic. It doesn't just affect myself, but all the members in my development team. I'm currently using Xcode 14.1 RC 2 and Monterey but I've seen this issue occur with

If the user installs an application which uses push notifications onto iPhone A and then runs the app then the app will send the push token to the server (and from that point one the app should detect if the push token changes and send the new token to the server). However there's no way that the app can do this in the situation where the user backs up iPhone A to iCloud and then restores to iPhone B. If the user doesn't explicitly launch the application, then the application has no chance to detect that the push token will have changed, and so meanwhile the server is sending pushes using the token from phone A but the user now is using phone B. User's won't know they have to launch an app on phone B, and there's no way the app can launch itself, so the user's now have a non functioning app but they don't realise it. There must a lot of apps using push that face this situation, yet there's no solution? I was hoping iOS 16's background asset download might be a solution to this - if the extension gets called a

Is it possible to interact with a widget without the app launching, and also without long pressing followed by edit? I'm wondering if a scenario such as the user tapping the widget and that causing the pasteboard to be read, and then some content updated in the widget is possible without the app itself launching

I've added a background asset extension and am trying to invoke it using this: xcrun backgroundassets-debug --app-bundle-id com.myCompany.myApp --device-id 00008120-000225060C9B401E --simulate --app-update When I run that command I see this in the phone's log: Unable to observe extension for (com.cequint.myapp), the BAApplicationInfo is missing an extensionIdentity. So how should an extension identify be added? The extension's info.plist is as created by the Xcode template: <key>EXAppExtensionAttributes</key> <dict> <key>EXExtensionPointIdentifier</key> <string>com.apple.background-asset-downloader-extension</string> </dict> And I've added the following to the app's info.plist: > <dict> <key>BGTaskSchedulerPermittedIdentifiers</key> <array> <string>kBackgroundTaskIdIdentifier_RNScheduleAppRunEvent</string> </array> <key>BAMaxInstallSize</key> <integer>3221225472</integer> <key>BAInitialDo

This can easily be reproduced from scratch following these steps: Launch Xcode and choose to create a new iOS app. Organization name: com.company, ProductName:experiments. Therefore the bundle id is: com.company.experiments Create a background download target, productName:backgroundDownloadExtension. Therefore the bundle is is: com.company.experiments.backgroundDownloadExtension When Xcode creates the extension it automatically gives it a group capability with id: group.com.company.experiements. Within the signing & Capabilities section for the extension there is the following error: Within the developer portal, go to the Identifiers section, locate the main app bundle com.company.experiements. If not ticked, tick the App Groups capability. Click on edit, select group.com.company.experiments Within the developer portal Identifiers section, locate the extension bundle, com.company.experiments.backgroundDownloadExtension. Ensure the App Groups capability is ticked. Click on edit, select group.com.company.ex

Apple this is dead easy and quick to reproduce. Just create an app and then add a target of type background download. Xcode automatically assigns a group id to the target and generates a corresponding entitlements file like so: However the extension will not build, there is this error: You can bugger about in the developer portal as long as you want, ensuring the group identifier exists, ensuring provisioning profiles have this group capability, etc. etc. nothing will make this error go away. Now, what is unique about the download extension's entitlements file is the com.apple.developer.team-identifier key. This does not get generated for other extension - go ahead and see for yourself, create an action extension and give it a group, the result is its group appears in the entitlements file but not this com.apple.developer.team-identifier. If you try to print out $(TeamIdentifierPrefix) (via echoing it in a build script), you get this /Users/me/Library/Developer/Xcode/DerivedData/experiments-clpwbtcvdpqwuodxzw

I've found literally dozens and dozens of tutorials of how to deal with a voip push, but none of them, not one, make any mention at all of how to set things up prior to that, nor how to test the code they've just written. Sure, you can send a voip push easily enough using a push tool or push script, but that's only part of the picture, none of these tutorials mention anything about actually making a voip test call to accompany the test voip push. Are there any tools, or web portals etc. that can be used to generate a voip call to a handset to set the voip call side of things in addition to the voip push handling? Also, none of the tutorials mention what's needed to be done by the app in addition to implemented code to handle the voip push, specifically I mean how does the server sending the push know which user is associated with the push token. Surely there has to be a step where the app performs some sort of sip registration with a server before it deals with a voip push. None of these so called tutorials s

I'm confused by when CXProvider:reportNewIncommingVoIPPushPayload() is intended to be used versus CXProvider:reportNewIncommingCall(). All the iOS tutorials about VoIP push talk about sending a voip push to the app and the app calling CXProvider:reportNewIncommingCall() and then proceeding to deal with the VoIP call. However in this Apple documentation https://developer.apple.com/documentation/callkit/sending_end-to-end_encrypted_voip_calls It talks about sending a regular push, not a voip push, which is intercepted by a notification service extension, and the extension calling CXProvider:reportNewIncommingVoiPPushPayload(). I'm confused - when there's an incoming VoIP call should a voip push be sent to the app and reportNewIncommingCall() called or a regular push sent to the notification extension and reportNewIncommingVoiPPushPayload() called?

CallKit provides the ability to block regular calls via the call extension. And CallKit also provides the ability to integrate VoIP calls with the phone's call screen/user experience etc. However the blocking aspect of CallKit seems to have no bearing on the VoIP aspect. When the app receives a Voip Push it has to call CXProvider.reportNewIncomingCall() and that displays a call screen. If the parameters passed to reportNewIncommingCall() a handle of the .phone with a phone number registered for blocking with CallKit, the call screen still displays. Its not use to call CXProvider.invalidate() immediately because the call screen will still display, though its only displayed for a brief time its still very very obvious and noticeable. Therefore there appears to be no way of blocking the call, blocking is in quotes because from the user's perspective you would not expect to see the call screen, but is there is no way of stopping it from appearing, even if that appearance is only brief?

0 If a voip push (i.e. a push with a topic of com.company.app.voip as the push topic) is sent to a handset then it is delivered directly to the app via: pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler: If the app has a notification service extension, and the push payload contains mutable-content, and if the app is terminated, then the app gets launched in the background and the push still is delivered directly to the app, it does not get delivered to the extension. If the push topic is changed to be just com.company.app (and provided the payload contains the mutable-content flag) then in that case it gets delivered to the extension. However now it's no longer a voip push, it's just a regular push, because the topic no longer contains the .voip suffix. So how can things be configured whereby a voip push gets delivered to a notification service extension? Because that's what the Apple documentation says: Call this

This video is referenced in several places, for example here references it https://developer.apple.com/documentation/callkit/making_and_receiving_voip_calls_with_callkit and Eskimo has referenced it in his posts. But its gone, there are other WWDC16 session videos but not this one (https://developer.apple.com/videos/wwdc2016) Is it available anywhere else? Also how can this code be run/tested for an incoming call (without using the build in simulator i.e. using a real incoming Voip call)? What tool/app etc. could be used to generate a call to the handset to see the code in action when answering a VoIP call?

Whenever one googles for VoIP and iOS there's always a lot of results that appear that tell you about using CallKit. However CallKit on its own is useless, it just provides a GUI/OS integration of VoIP, but not the actual SIP nor VoIP things themselves. There's lots of 3rd party libraries out that, however they all include licensing, or paying a fee, and are tied to the 3rd party's servers. Approximately how much effort is it to develop from scratch in Swift code to enable an app to receive VoIP calls (it doesn't need to make outgoing VoIP calls, and and only audio, not video needs to be supported). Here's what I think would be involved: Send information from the app to a SIP registrar. How difficult is this? Enable VoIP push handling in the app, send the Voip Push token to a server. Handle incoming VoIP push. Implement the VoIP transport, audio handling etc., for incoming VoIP Integrate with the OS I know how to do 2, and for 4 there's loads of tutorials on CallKit. What I'd like to determine is what is invo

There's lots of material on the internet talking about how the VoIP background mode capability was deprecated in iOS 10. And yet its still presented as an option in the latest version of Xcode and it still appears in Apple's documentation https://developer.apple.com/documentation/xcode/configuring-background-execution-modes The documentation states: The app provides Voice over IP services and requires automatic launch after system restart. For more information, see the CallKit framework. It seems apps used to be able to be launched on restart prior to iOS 10, but since then they can't. So is the documentation for this area out of date and wrong? If its been deprecated for so long, why is it still documented and possible to add it to an application?