For devices running iOS 18 and iPadOS 18 or later, you can add input-push-token: 1 to your payload to start a Live Activity and receive a new push token. After you receive a new push token, you can use it to send updates to a Live Activity. I read from https://developer.apple.com/documentation/ActivityKit/starting-and-updating-live-activities-with-activitykit-push-notifications#Start-new-Live-Activities-with-ActivityKit-push-notifications that I can start a live activity from CUSTOM SERVER by the start token I get from MyApp.Does that paragraph means my CUSTOM SERVER can receive a new token from aps? If not, how can update the live activity started by Push-Notification when MyApp doesn't alive? And what "input-push-token: 1 " can do, when I put it in the payloads?

I received this erroe:”400 / Missing or incorrectly formatted device token payload”, when wanted sign up chat gpt

Hi, for iOS in-app push provisioning flow, and for a card that is in already in requiresActivation state, is it possible from our app UI to launch to the card's verification screen either as a in-app flow (like how in-app push provisioning flow is doing) or Apple Wallet? So far the current process is that it will prompt user to provision the card again (only to show This Card is Already in Wallet error), or to open the card in tap-to-pay mode, or adding a new card flow in Apple Wallet. Am I missing any PassKit SDK on this?

Payment completed with error: Error Domain=ASDErrorDomain Code=500 "(null)" UserInfo={client-environment-type=Sandbox, storefront-country-code=USA, NSUnderlyingError=0x2828a5950 {Error Domain=AMSErrorDomain Code=305 "Purchase Failed" UserInfo={NSLocalizedDescription=Purchase Failed, AMSURL=https://sandbox.itunes.apple.com/WebObjects/MZBuy.woa/wa/inAppBuy?guid=00008030-000164513691402E, AMSStatusCode=200, AMSServerPayload={ "cancel-purchase-batch" = 1; customerMessage = "Bad Gateway_message"; failureType = ""; "m-allowed" = 0; pings = ( ); }, NSLocalizedFailureReason=Server canceled the purchase}}}

I'm working with the Screen Time API in iOS and have successfully implemented the following: Granted Screen Time Permission: The app asks for and obtains Screen Time permissions without any issues. Blocked Specific Apps: Using FamilyActivitySelection, I can block access to certain apps. Monitoring Device Activity: With DeviceActivityCenter().startMonitoring(), I’m able to successfully start monitoring. DeviceActivityCenter().startMonitoring(.myActivity, during: schedule) Now, I’m wondering if there’s a way to detect exactly which app the user opens, so I can fire an API from my own app based on that event. Is this kind of real-time app usage detection possible with the Screen Time API? If so, how might it be implemented?

I am working on a SwiftUI app using the Screen Time API and the DeviceActivityReport view to display app usage data. My current implementation successfully shows daily app usage using a DeviceActivityFilter with the .daily(during:) segment. However, I need to filter this data to show app usage only for a specific time period during the day, e.g., 4:00 PM to 5:00 PM. I created a DeviceActivityFilter with a .daily(during:) segment and passed a DateInterval for the desired time range: let now = Date() let startTime = calendar.date(bySettingHour: 16, minute: 0, second: 0, of: now)! let endTime = calendar.date(bySettingHour: 17, minute: 0, second: 0, of: now)! let timeInterval = DateInterval(start: startTime, end: endTime) let filter = DeviceActivityFilter( segment: .daily(during: timeInterval), users: .all, devices: .init([.iPhone]) ) I applied this filter to the DeviceActivityReport view: DeviceActivityReport(context, filter: filter) Even with the DateInterval set for the specific time range, the report still shows the total daily usage for each app, instead of restricting the results to the specified 1:00 PM to 5:00 PM range.

A user made an in-app purchase on December 15th at around 4:00 PM Japan Standard Time (JST). However, the confirmation email sent after the purchase shows the receipt date as December 14th. What could be causing this discrepancy in the date? The app store's primary language is set to English. The server region is singapore.

Hi everyone, is there any ways we can remove the weak ciphers as part of TLS handshake (TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) I checked here but still do not see anyways to print out and change the ciphers suite we want to use https://forums.developer.apple.com/forums/thread/43230 https://forums.developer.apple.com/forums/thread/700406?answerId=706382022#706382022

So, we've implemented IAP with StoreKit2 e2e for both the client and backend and it's working mostly perfectly, however we have an issue which we can't seem to understand Apple's behavior. So, imagine a purchase that occurred on the 10th of December in the sandbox environment through an install from TestFlight, and this same purchase keeps getting queued in the Transaction.unfinished list for some reason (today, the 17th of December, a whole week after the initial purchase!). Here's the flow: We iterate the list on app launch Send the unfinishedTransaction's transactionId to our servers The server says "hey, we could verify it with Apple but it's not longer active (expired). We can't really work with it so just finish it on your side and don't send it to me again" The client finishes!! the transaction On the very next app launch it keeps reappearing in the Transaction.unfinished queue Are we doing something wrong, why doesn't it get cleaned? Is this an expected behavior? Note, this is generally the server's logic for new purchases: If we weren't able to contact Apple - we tell the client to not finish the transaction so that we'll be able to re-iterate it on the next app launch or retry If the transaction is not expired and valid - we update our records and tell the client to finish the transaction If we couldn't update our records - we tell the client to not finish the transaction so that we'll be able to re-iterate it on the next app launch or retry If the transaction is not valid for some reason - we tell the user to finish the transaction The server might see it as a valid transaction if we'll send the originalTransactionId instead of the 'transactionId(using it to callgetTransactionInfoinAppStoreServerLibrary`), but is this something we want to do? This will obviously not fix the problem because the server tells the client to finish the transaction anyways, but it simply doesn't work. Please, any advice or changes to make to either Client/Server would be greatly appreciated Best Regards, Ofek

I have several ObjC based apps in the App Store and used to validate the receipt file inside the app in my code, and then reject it with exit(173) if it's invalid, which did trigger macOS to update the receipt if possible. This isn't working any more in recent macOS versions, where the user is instead just told that the app is damaged, and they need to re-install it manually. Which sucks. So I wanted to update my code. I read about SKReceiptRefreshRequest, which is supposed to re-download and install the receipt file, if I understand it correctly. I implemented the code but now have trouble verifying that it works as intended, and does this in a user friendly way. I found in my tests that macOS now caches the receipt in ~/Library/Caches/com.apple.appstoreagent/fsCachedData and then hardlinks the file into the app. BTW: Sadly, this also requires that the app is located on the startup volume or the system will refuse to install the receipt, which wasn't a requirement in past times. Now, if the receipt is already present in the cache folder, then my code works - the receipt gets re-linked. But what if the cached receipt isn't there, yet? Such as that the user had copied the app from another Mac over to a freshly installed Mac? In the past, when the user then launched the app on the new Mac, he'd be prompted to login to the MAS and if that worked, the receipt would get installed and the app launched. Basically, the question is: What if the receipt validation fails in my app and I request a new receipt, but the user has not yet logged into MAS (e.g. new computer)? To simulate this, I logging out of the MAS and TestFlight, deleting all copies of the app and then run the app that I had copied from another Mac where it was authorized with a valid receipt for that device. If I do this with the old version that uses exit(173), I get these two messages in macOS 15.2: The second one is especially terrible because it shows the translocated path, which the average user surely get quite confused, and then maybe even search in vain for the app in there and get frustrated. But that's out of my hands. Sigh. Now, that was proving that the old method with exit(173) isn't working any more and needs to be changed in my apps. Since I'm still developing (testing) this new behavior, the app is therefore not in the MAS yet - the only way for me to test this is to use TestFlight. However, running a Testflight app copied from another Mac leads to this error: That is not helpful in simulating what would happen if this app was released in the MAS. This won't let me find out what happens if my app is run on a Mac where the receipt fails and I ask it to load it via SKReceiptRefreshRequest and if the user is NOT yet logged into the MAS account for this purchased app of his/hers. That leaves only one option: Release the app with untested code and hope for the best. Contrary to this new behavior, the old method did let me test this easily because I would just use the special App Store tester account with the MAS app, i.e. the built MAS app would, when I launched it locally, request for a login and I'd provide my tester's account. But this isn't available any more, apparently. What a mess.

I'm trying to add Siri support to my app for sending voice messages. I've implemented INSendMessageIntentHandling in my main app target. It looks like it's getting as far as recording the voice message and passing my intent handler an INSendMessageIntent with an audio attachment, but I'm not able to read the attachment file. func handle( intent: INSendMessageIntent, completion: @escaping (INSendMessageIntentResponse) -> Void ) { if let attachment = intent.attachments?.first, let audioFile = attachment.audioMessageFile, let fileURL = audioFile.fileURL { // This branch runs // fileURL is "file:///var/mobile/tmp/SiriMessages/89F738F7-6092-439A-B4FA-2DD9A99F0EED.caf" let result = processMessageAudio(url: fileURL) completion(result) return } // This line isn't reached completion(.init(code: .failure, userActivity: nil)) } private func processMessageAudio(url: URL) -> INSendMessageIntentResponse { var fileRef: ExtAudioFileRef? if url.startAccessingSecurityScopedResource() { logDebug("File access allowed") } else { // This branch runs logDebug("File access not allowed") } defer { url.stopAccessingSecurityScopedResource() } let openStatus = ExtAudioFileOpenURL(url as CFURL, &fileRef) // openStatus is -54 (kAudio_FilePermissionError) return INSendMessageIntentResponse(code: .failure, userActivity: nil) } I'm not sure what I'm missing. It looks like there should be an audio file, and Siri shows a preview of the audio for confirmation.

I'm working on adding Apple Pay to my web site and I'm getting this error when the element loads. InvalidAccessError: Trying to start an Apple Pay session from an insecure document. Do I need HTTPS on my development site? I have it on my production site, but I've never enabled it for dev. If so, will it work with a self-signed certificate? If not, what does this error mean? How can I resolve it?

Hi All, Had a question. Is there a point to submit anything through the feedback assistant (https://feedbackassistant.apple.com)? I mean it doesn't seem like any engagement occurs through the platform on any issues submitted.

Issue: Using Messages in macOS Sequoia, I stop receiving any messages after 7+ hrs of the system being on. Troubleshooting: any messages sent to the target account doesn't show up when this issue occurs. I'm able to send messages from the target account which is received. only way to get it working is to reboot the computer but those messages sent never arrive to the target account even after reboot. upon reboot the behavior functions as expected. however the issue returns after 7hrs+ after reboot. logout and log back in when the system is in this state doesn't resolve the issue. only a reboot but the issues eventually returns. note the 7hrs+ is tested and is more accurately 7-10 hrs.

when app enter background,sometimes crash at BSXPCCnx:com.apple.backboard.hid-services.xpc (BSCnx:client:BKHIDEventDeliveryManager) this is crash stack: 0 libsystem_pthread.dylib 0x3b30 pthread_mutex_lock + 12 1 ilink_live 0xbd884 (缺少 UUID 973fe6c5058c35bda98679b0c8aa0129) 2 ilink_live 0xb75fc (缺少 UUID 973fe6c5058c35bda98679b0c8aa0129) 3 libsystem_c.dylib 0x23d68 __cxa_finalize_ranges + 492 4 libsystem_c.dylib 0x23b64 exit + 32 5 BackBoardServices 0x579ec -[BKSHIDEventDeliveryManager _initForTestingWithService:] + 98 6 BoardServices 0xbae8 __31-[BSServiceConnection activate]_block_invoke.182 + 128 7 BoardServices 0x17620 __61-[BSXPCServiceConnectionEventHandler _connectionInvalidated:]_block_invoke + 196 8 BoardServices 0x8f64 BSXPCServiceConnectionExecuteCallOut + 240 9 BoardServices 0x18e5c -[BSXPCServiceConnectionEventHandler _connectionInvalidated:] + 180 10 libdispatch.dylib 0x2370 _dispatch_call_block_and_release + 32 11 libdispatch.dylib 0x40d0 _dispatch_client_callout + 20 12 libdispatch.dylib 0xb6d8 _dispatch_lane_serial_drain + 744 13 libdispatch.dylib 0xc214 _dispatch_lane_invoke + 432 14 libdispatch.dylib 0x17258 _dispatch_root_queue_drain_deferred_wlh + 288 15 libdispatch.dylib 0x16aa4 _dispatch_workloop_worker_thread + 540 16 libsystem_pthread.dylib 0x4c7c _pthread_wqthread + 288 17 libsystem_pthread.dylib 0x1488 start_wqthread + 8 when crash happened ,most of time app recieved CBManagerStateResetting and CBManagerStateUnsupported event

I am working on a Bluetooth Low Energy (BLE) project using the nRF52840 Development Kit (DK), which has been reconfigured to simulate an nRF52805 chip. The firmware is based on Nordic Semiconductor's ble_app_hids_keyboard example, with modifications to implement a BLE HID Gamepad. I am using the S113 SoftDevice and have successfully tested the functionality with Android devices. The gamepad is recognized as a HID device, and it works as expected on Android, verified using the hardwareTester website. However, when I connect the gamepad to an iPhone via BLE, the same hardwareTester website does not respond as it does on Android, indicating that the iPhone does not recognize the device as a gamepad. The BLE connection is established successfully, but it seems iOS does not interpret the HID report descriptor or the BLE HID service correctly. I suspect there might be compatibility issues with the HID descriptor or the GATT attributes for iOS-specific BLE HID requirements. I would like to have some help.

Hi, I have develop the application in the react native. Now this application is related to truck drivers. So we have added load and when they accept the load then we fetch the location to firebase. Now issue is its not working when app close (background) on physical device. We tried on simulator and its working perfectly in the background. But when i make the build and test on physical device its not working for background task.

I previously had an application running at the login window prior to macOS Sequoia. It's a simple program specific to the needs of my company that did it's job. As you've probably guessed, with the move to Sequoia, it no longer works. Having developed this application, I'm fairly familiar with how all this works, so...is there something that changed with the loginwindow context in macOS Sequoia that affected this (and I obviously missed)? I've gone through DTS tickets previously and will again if necessary, but I'm hoping someone can just point out a linker option or build setting that is new with Sequoia. Thanks!

Hello everyone, I hope you’ll all bear with me as I get up to speed. My background is in Unix, procedural languages, mission critical databases and enterprise applications. I’ve just started heading a team with an iOS app used in healthcare that contains confidential patient information (PHI) that's governed by HIPAA and FDA cybersecurity, etc. It seems there’s some contention in the team over whether the app, SQLite db, and medical images belong in the Documents or an Application Support directory in the Library. From everything I’ve read, it seems that Apple’s intent is Library/Application Support. Two questions: Which is the correct location? And hopefully, a few compelling justifications. On one of our iPads, the app stopped displaying what was two years of data in SQLite. I haven’t yet tested for index corruption, however one of the programmers believes this resulted from an iOS update that needed space and cleared data in the cache (but that makes no sense to myself). Feedback highly appreciated. Many thanks, David Why, because somebody has to

I would like to share my specific use case and seek your guidance on implementing it effectively within iOS: We are developing an iOS application that may run simultaneously on multiple devices near each other. The core functionality involves continuous Bluetooth Low Energy (BLE) scanning to detect peripherals (beacons) in the range of a central device. The scanning needs to function seamlessly across the following states: • Foreground • Background • Locked mode (when the device is locked) Here are the detailed requirements: 1. Scanning Behavior: • The central device should continuously scan for nearby BLE peripherals (beacons). • If a new peripheral comes into range, the application should capture its data, including: • Device Name • MAC Address • Payload Data • RSSI (Signal Strength) 2. Peripheral Out-of-Range Handling: • If a detected peripheral (beacon) moves out of range, it should automatically be removed from the populated list displayed on the app. 3. Peripheral Reappearance: • If a peripheral (beacon) that moved out of range comes back into range, the application should detect it again and repopulate the list with updated data seamlessly. 4. Application State: • This behavior (scanning, detection, and updating) should work regardless of the app’s state: • Foreground • Background • Device Locked FYI, we are using Custom Ruuvi beacons Given the above requirements, I would greatly appreciate any guidance, suggestions, or best practices to implement this use case efficiently while adhering to iOS background execution and Bluetooth limitations.