Is it possible to write an iOS app or app extension to block an incoming call based on the area code (or some other portion of the incoming call number)?

Hi. The WWDC video of the v2 weatherkit api showed some examples for the REST API. However, they were very limited. The documentation for the REST API is currently for the v1 weatherkit API. When will the documentation for the v2 API be released? There are some new features of the v2 that I would really like to use, but I can't without knowing the new v2 REST API specifications. Any guidance would be much appreciated. Thanks!

Observed few times that providerDidBegin(_:) delegate never called for the complete app session after app init(as part of this CXProvider registered) which was built with SDK 26 and running on iOS 26. This issue observed multiple times with our testing. Since there is no providerDidBegin:, client is marking CallKit as not ready and never report any calls for VoIP APNS and ended up in app crash due to "[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes]" Please refer for sysdiagnose logs : FB19778306

I'm trying to migrate from Complication with CLKComplication to WidgetKit. I have implemented the required methods in https://developer.apple.com/documentation/widgetkit/converting-a-clockkit-app, but the migration is not working. There is no evidence that the method for migration is also called. It was the same with Xcode 14.0.1 and Xcode 14.1RC. class ComplicationController: NSObject, CLKComplicationDataSource, CLKComplicationWidgetMigrator { ...     @available(watchOS 9.0, *)     var widgetMigrator: CLKComplicationWidgetMigrator {         return self     }     @available(watchOS 9.0, *)     func widgetConfiguration(from complicationDescriptor: CLKComplicationDescriptor) async -> CLKComplicationWidgetMigrationConfiguration? {         return CLKComplicationStaticWidgetMigrationConfiguration(kind: "MyWidget", extensionBundleIdentifier: "com.example.myapp.mywatchkitapp.mywidget")     } } What's wrong? Has anyone been able to migrate?

Hi, I'm currently working on an app made originally for iOS 15. On it, I add an observer on viewDidLoad function of my ViewController to listen for changes on the UserDefault values for connection settings. NotificationCenter.default.addObserver(self, selector: #selector(settingsChanged), name: UserDefaults.didChangeNotification, object: nil) Said values can only be modified on the app's section from System Settings. Thing is, up to iOS 17, the notification fired as expected, but starting from iOS 18, the notification doesn't seem to be sent by the OS. Is there anything I should change in my observer, or any other technique to listen for the describe event? Thanks in advance.

func handle(intent: INSendPaymentIntent, completion: @escaping (INSendPaymentIntentResponse) -> Void) { if let _ = intent.payee, let currencyAmount = intent.currencyAmount { let userActivity = NSUserActivity(activityType: "com.rapipay.nye.test.failure") userActivity.userInfo = ["amount": Int(truncating: currencyAmount.amount!)] completion(INSendPaymentIntentResponse(code: .failureRequiringAppLaunch, userActivity: userActivity )) return } } func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([any UIUserActivityRestoring]?) -> Void) -> Bool { print("ddddd") return true } this code is perfectly working on simulator and even i fi user userActivity as nil, continue userActivity is called, but on device it is not called Siri is working, asking for name and amount and handler is also called and opens app but does not pass intent or userActivity

We persist ApplicationTokens in a storage container that ShieldConfigurationExtension has access to. In rare, cases all the ApplicationTokens for a user seem to change. We know this because the Application parameter passed into configuration(shielding application: Application) -> ShieldConfiguration function has a Token that does not match (using == ) any of the ones we are persisting in storage. Interestingly, the persisted ones still work, so I don't believe storage has gotten corrupted or anything. We can use them to add or remove shields, we can use them to display labels of the apps they represent, etc. But they don’t match what’s passed into the ShieldConfiguration extension. If the user goes into the FamilyPicker at this point and selects an app of a token that we are already persisting, the FamilyPickerSelection will have a token matching the new one that is passed into ShieldConfigurationExtension, not the one we persisted when they last selected that app. This leads me to believe the tokens are updated/rotated in some cases. When and why does this happen, and how can we handle it gracefully?

I am seeing some unexpected behavior, in particular, is seems that iOS is periodically foregrounding my test app with no user intervention. I am curious why this is. I wrote a simple test app to see how long the app would run to collect location while in the background with only "While in Use" location permission. The app will start location updates when foregrounded and continue in the background. While backgrounded, I see the blue arrow in the dynamic island as expected. What is unexpected is that every few days, I see the UI of the app displayed in the foreground, without having foregrounded it myself (and no, I did not tap the blue arrow). This is using the legacy CoreLocation apis on iOS 17.5.1. My question is how/why does this happen?

Anyone who has successfully migrated to using WidgetKit for their Apple Watch complications, your help would be greatly appreciated! I've migrated to WidgetKit for my Watch app. On the Apple Watch Face Editor, the new Widget names and options appear correctly. However, on the iPhone Apple Watch app, it offers both WidgetKit and old ClockKit complications... this should not be. I also have found rendering issues where Watch Faces on the main My Watch tab have blank gaps for WidgetKit complications, when selecting the Watch Face they then render (see photos) I've put in a feedback FB12460375 Have tried a full clear and reinstall of my app on both devices, no change. This issue occurs on WatchOS 9.5.2 / iOS 16.5.1 and WatchOS 10 Beta 2 / iOS 17 Beta 2 Any other ideas?

Starting with iOS 18.3, we are getting infrequent crash reports somehow related to web sockets. Are there any new caveats we should be aware of or is it just a CFNetwork bug? Incident Identifier: 0D4343CE-3089-4514-841D-80CEC353B6B8 Distributor ID: com.apple.AppStore Hardware Model: iPhone16,2 AppStoreTools: 16C7015 AppVariant: 1:iPhone16,2:18 Code Type: ARM-64 (Native) Role: Non UI Parent Process: launchd [1] Date/Time: 2025-03-18 15:42:14.1732 -0400 Launch Time: 2025-03-15 20:38:20.7015 -0400 OS Version: iPhone OS 18.3.1 (22D72) Release Type: User Baseband Version: 2.40.05 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 VM Region Info: 0 is not in any region. Bytes before following region: 4373233664 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 104aa4000-104aa8000 [ 16K] r-x/r-x SM=COW /var/containers/Bundle/Application/EDB47FCF-9E2C-4BE3-A771-F6F84BFCAF31/<redacted> Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [4454] Thread 10 Crashed: 0 CFNetwork 0x0000000193c46aac -[__NSURLSessionWebSocketTask _onqueue_receiveMessageWithCompletionHandler:] + 256 (LocalWebSocketTask.mm:486) 1 CFNetwork 0x0000000193c438b0 -[__NSURLSessionWebSocketTask _onqueue_ioTick] + 636 (LocalWebSocketTask.mm:355) 2 CFNetwork 0x0000000193c46918 __67-[__NSURLSessionWebSocketTask receiveMessageWithCompletionHandler:]_block_invoke + 356 (LocalWebSocketTask.mm:97) 3 libdispatch.dylib 0x000000019a2e9248 _dispatch_call_block_and_release + 32 (init.c:1549) 4 libdispatch.dylib 0x000000019a2eafa8 _dispatch_client_callout + 20 (object.m:576) 5 libdispatch.dylib 0x000000019a2f25cc _dispatch_lane_serial_drain + 768 (queue.c:3934) 6 libdispatch.dylib 0x000000019a2f3158 _dispatch_lane_invoke + 432 (queue.c:4025) 7 libdispatch.dylib 0x000000019a2fe38c _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:7193) 8 libdispatch.dylib 0x000000019a2fdbd8 _dispatch_workloop_worker_thread + 540 (queue.c:6787) 9 libsystem_pthread.dylib 0x000000021d2e4680 _pthread_wqthread + 288 (pthread.c:2696) 10 libsystem_pthread.dylib 0x000000021d2e2474 start_wqthread + 8 (:-1) Thread 10 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x00000000000003f0 x3: 0x0000000000000001 x4: 0x0000000000000010 x5: 0x00000000b04d793d x6: 0x00000000000013c0 x7: 0x0000000000000000 x8: 0x0000000000000378 x9: 0x0000000000000001 x10: 0x00000001fabc6b40 x11: 0x000000000000000f x12: 0x0000000000ddf700 x13: 0x000000012a1bc1c0 x14: 0x00000001fabc9798 x15: 0x00000001fabc9798 x16: 0x000000018faa1c4c x17: 0x000000019a2ea664 x18: 0x0000000000000000 x19: 0x0000000303a83420 x20: 0x0000000000000000 x21: 0x000000012b42d900 x22: 0x00000001fc8000a8 x23: 0x00000001fc8000a8 x24: 0x00000003036913c0 x25: 0x00000003036913c0 x26: 0x0000000000000001 x27: 0x0000000303afc870 x28: 0x0000000000000001 fp: 0x000000016b95a1f0 lr: 0x0000000193c46a04 sp: 0x000000016b95a170 pc: 0x0000000193c46aac cpsr: 0x40001000 esr: 0x92000006 (Data Abort) byte read Translation fault

An issue with the CallKit UI, specifically regarding the functionality of the speaker button. When a user initiates a video call with CallKit and then, using the existing CallKit session, initiates an audio call, there are no issues with CallKit or the audio. However, if the user terminates the video call from the CallKit UI, the active CallKit session ends. To resume the ongoing audio call, we report a new CallKit call upon the end call trigger. While there are no issues with this reporting, the CallKit UI does not provide an audio route for the built-in receiver, and the speaker button remains unresponsive. IPA was build on SDK 18 and running on iOS beta 26. Issue is NOT seen with SDK18 and running iOS 18.x or lower devices. Feedback - FB18855566

I have a SwiftUI document-based app that for the sake of this discussion stores accounting information: chart of accounts, transactions, etc. Each document is backed by a SwiftData DB. I'd like to incorporate search into the app so that users can find transactions matching certain criteria, so I went to Core Spotlight. Indexing & search within the app seem to work well. The issue is that Spotlight APIs appear to be App based & not Document based. I can't find a way to separate Spotlight data by document. I've tried having each document maintain a UUID as a document-specific identifier and include the identifier in every CSSearchableItem. When performing a query I filter the results with CSUserQueryContext.filterQueries that filter by the document identifier. That works to limit results to the specific file for search operations. Index updates via CSSearchableIndexDelegate.reindex* methods seem to be App-centric. A user may have file #1 open, but the delegate is being asked to update CSSearchableItems for IDs in other files. Is there a proper way to use Spotlight for in-app search with a document-based app? Is there a way to keep Spotlight-indexed data local within the app & not make it available across the system? I.e. I'd like to search within the app only. System-level searches should not surface this data.

In mainland China, CallKit is not available. Recently, I discovered LiveCommunicationKit. Can it replace CallKit? There is no relevant introduction in the documentation. Can someone help me understand how to use it? https://developer.apple.com/documentation/livecommunicationkit

Hi, I'm trying to make use of the Device Activity Labels where you supply an ApplicationToken. I can successfully get it to show the icon + title of the Application (twitter in my case) but I cannot get the styling to work. // Works .labelStyle(.iconOnly) .labelStyle(.titleOnly) .border(...) ![]("https://developer.apple.com/forums/content/attachment/9660b578-a36f-4d5a-ae18-653a207aa5ab" "title=Screenshot 2023-03-12 at 12.57.34 PM.png;width=1218;height=844") // Does NOT work .font(.largeTitle) .foregroundColor(.blue) I have checked the same style (or just modifiers) against a standard Label and they actually do work in the code below. // This is an application token. Some style not applied. Label(targetApp) .labelStyle(MyStyle()) // Showing the same style using a simple label. All styles correctly applied. Label("Twitter", systemImage: "video.square.fill") .labelStyle(MyStyle()) Is changing the font + color of the title for this Label(_ applicationToken:) supported?

content = try String(contentsOfFile: filepath) is the following warning. 'init(contentsOfFile:)' was deprecated in iOS 18: Use init(contentsOfFile:encoding:) instead After internet searching I could find an answer. I would appreciate a rewrite of my code line to get rid of 31 warnings. Thanks a LOT Charlie

(Also have a case ID, 9879068) We have an app that user use to check in/out from work for example. We have a button in-app do do this. Now I'm trying to add buttons to our widgets and our new live activity so that users don't have to open the app. It's crucial that the live activity and widgets always show the exact same state. Otherwise it'll look pretty bad if a user has both a live activity and a widget showin at the same time. However, we have noticed that sometimes, pressing the button in the live activity, running the app intent, will not always make the widget update (we call reloadAllTimelines()). The other way around, i.e. press the button on widget to update live activity always works. (they both call the same app intent) When running it in debug mode on a phone from Xcode, it always works, but when running it just on the phone it's unreliable. My first thought was, of course, that's related to the widget "budget", but according to the docs HERE, it should not be applied when interacting with a widget, calling an app intent. My question: HOW can I make my widget reliably refresh using an app intent invoked from a live activity?? I have a ready small project with simple buttons and trace labels that display this issue that I'm happy to supply to someone.

Hello, The purpose of "Screen Time Passcode" under Settings/Screen Time is to protect Screen Time preferences and it is asked every time the user updates Downtime, App Limits, Content & Privacy Restrictions and so on. But the private passcode is not requested if the user disables Screen Time for a particular app (only Face ID or phone passcode is requested, but not the private Screen Time passcode). I think this is a mistake, I think the purpose of a private Screen Time passcode is to protect all settings, including apps that use this API, right? Is there any solution to this? Thank you.

Hi, I'm trying to implement WeatherKit for the first time and I am seeing this error when calling for the weather: Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" and Encountered an error when fetching weather data subset; location=<+51.57750785,-2.08241362> +/- 6.55m (speed -1.00 mps / course -1.00) @ 11/01/2025, 11:50:45 Greenwich Mean Time, error=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors 2 Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" I have: Enabled the WeatherKit capability in my iOS app in XCode Added Weatherkit to the AppID in the developer portal Any suggestions what else I can check? I'm running iOS 18.2.1 on 15 ProMax with XCode 16.2

Hi everyone, Is there any way to detect an app is being mirrored from an iPhone to macOS via iPhone Mirroring (new feature from iOS18 and macOS 15 Sequoia)? My app has a business requirement to disable screen mirroring and recording (or just display a black screen when it's active). However, the current implementation doesn't seem to work with iPhone Mirroring to macOS. Is there any solution for this? Because as far as I know, seems like there is no API to detect it What I've tried so far 1. Count the UIScreen var totalScreens = UIScreen.screens.count Screen counts: iPhone only (without mirroring or airplay): 1 iPhone Airplay (screen mirroring): 2 iPhone Mirroring (iOS18) to MacOS15: 1 conclusion: both iPhone only and iPhone mirroring to macOS returns the same screen count (no difference) 2. Mask the entire screen with passwordTextField.isSecureTextEntry= true Result iPhone screen recording: Black screen iPhone screen mirroring (AirPlay): Black screen iPhone Mirroring (with macOS): No blackscreen, it works as usual The implementation is similar to https://stackoverflow.com/a/67054892 and https://forums.developer.apple.com/forums/thread/736112?answerId=765331022#765331022 What I want to achieve is something like the FairPlay Streaming API (https://developer.apple.com/streaming/fps/), where it turns the screen black when a screenshot, screen recording, screen mirroring, or iPhone mirroring is active. Thank you

Hello, I have an app on the App Store built around WeatherKit and it was working fine, up until this morning when I started seeing errors when using the app. When debugging using Xcode I see the familiar error Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" which, according to what I've read on the forums looks like an authentication error. Attaching a network debugger to the Simulator, I saw this error: This I have tried: Verify that WeatherKit is enabled on both Capabilities and App Services tabs on the Dev Portal. Toggle on/off this value and regenerate Provisioning Profiles Uninstall/reinstall Checking that I have API available calls. Nothing. If I create a new Bundle ID and sign with that, it works correctly. But this is not an option since that will force all my customers to download everything from scratch. I am getting emails from customers demanding money back and I can't figure out what has happened. The only thing I can think of, is that I started developing an Apple Watch app to complement the iOS app, but that was last week and everything was working fine.