Creating my first IOS appIntents. I created two simple appIntents. One to create a random number and the other to store it (actually it just prints it). Yet, when I run a shortcut that connects the two, the one that stores it is not receiving the entity. It receives nil instead of the entity created in the first step.

Any idea to achieve reliable periodic Bluetooth data retrieval on iOS, even when the app is closed or killed.

You are probably aware of the upcoming root certificate change for any servers you might have that you use to send push notifications by connection to APNs. If you are not, here is the announcement. We have been getting some questions about this, and understand not everyone is familiar with their server setup. First, we would like to clarify that this is only a change to your server's certificate trust store. You do not need to update anything else, like your APNs push certificates, the build certificates and provisioning profiles for your team/app, and so on. All you need to do is to install the mentioned new root certificate to your push server's trust store. If you are using a 3rd party push provider, it is them who will need to handle their servers. But you may want to double check with them nevertheless. If you are managing your own push servers that connect to APNs directly, then it is your responsibility to download and install the root certificate mentioned in the above link on your server(s). Unfortunately we cannot provide specific instructions on how to install this root certificate on every kind of server out there. Each server operating system/push server software will have different ways these root certificates are installed, which is out of scope of our support abilities. If you are not sure how to do this, I would recommend you seek help for this from your server-side developers or server admins. Or, if you don't have access to such resources, you can ask the support channels for your system the question: How do I install a root certificate? We have setup a test server at 17.188.143.34:443 that you can use to try and send pushes to test whether your new root certificate is correctly installed. An alternative way to test this would be, from a terminal prompt: openssl s_client -connect 17.188.143.34:443 -servername api.sandbox.push.apple.com -verifyCAfile USERTrustRSACertificationAuthority.crt -showcerts Change the parameter to the -verifyCAfile argument to point to your trust store, and it should allow you to validate Sample return results would be: Connecting to 17.188.143.34 CONNECTED(00000003) depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority verify return:1 depth=1 CN=Apple Public Server RSA CA 11 - G1, O=Apple Inc., ST=California, C=US verify return:1 depth=0 C=US, ST=California, O=Apple Inc., CN=api.sandbox.push.apple.com verify return:1 Argun Tekant /  DTS Engineer / Core Technologies

SIGPIPE is an ongoing source of grief on Apple systems [1]. I’ve talked about it numerous times here on the forums. It cropped up again today, so I decided to collect my experiences into one post. If you have questions or comments, please put them in a new thread. Put it in the App & System Services > Core OS topic area so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Well, on Unix-y systems in general, but my focus is Apple systems (-: Debugging Broken Pipes On Unix-y systems, writing to a pipe whose read side is closed will raise a SIGPIPE signal. The default disposition of that signal is to terminate your process [1]. Broken pipe terminations are tricky to debug on Apple systems because the termination doesn’t generate a crash report. For example, consider this code: let (read, write) = try FileDescriptor.pipe() // This write works. try write.writeAll("Hello Cruel World!".utf8) let msg = try read.read(maxCount: 256) … do something with `msg` … // But if you close the read side… try read.close() // … the write call raises a `SIGPIPE`. try write.writeAll("Goodbye Cruel World!".utf8) Note This code relies on some extensions to FileDescriptor type that make it easier to call the pipe and write system calls. For more information about how I set that up, see Calling BSD Sockets from Swift. If you put this in an iOS app and run it outside of Xcode, the app will terminate without generating a crash report. This logic also applies to BSD Sockets. Writing to a disconnected socket may also trigger a SIGPIPE. This applies to the write system call and all the send variants: send, sendto, and sendmsg). IMPORTANT Broken pipe terminations are even more troubling with sockets because sockets are commonly used for networking, where you have no control over the remote peer. It’s easy to reproduce this signal with Unix domain sockets: let (read, write) = try FileDescriptor.socketPair(AF_UNIX, SOCK_STREAM, 0) // This write works. try write.writeAll("Hello Cruel World!".utf8) let msg = try read.read(maxCount: 256) … do something with `msg` … // But if you close the read side… try read.close() // … the write call raises a `SIGPIPE`. try write.writeAll("Goodbye Cruel World!".utf8) However, this isn’t limited to just Unix domain sockets; TCP sockets are a common source of broken pipe terminations. [1] At first blush this API design might seem bananas, but it kinda makes sense in the context of traditional Unix command-line tools. Confirm the Problem The primary symptom of a broken pipe problem is that your app terminates without generating a crash report. Unfortunately, that’s not definitive. There are other circumstances where your app can terminate without generating a crash report. For example, another common cause of such terminations is the app calling exit. There all two ways you can confirm this problem. The first relies on Xcode. Run your app in the Xcode debugger and, if it suddenly stops with the message Terminated due to signal 13, you know you’ve been terminated because of a broken pipe. IMPORTANT Double check that the signal number is 13, the value of SIGPIPE. If you can’t reproduce the problem in Xcode, look in the system log. When an app terminates the system records information about the reason. The exact log message varies from platform to platform, and from OS version to OS version. However, in the case of a SIGPIPE termination there’s usually a log entry containing PIPE or SIGPIPE, or that references signal 13. For example, on iOS 18.2.1, I see this log entry: type: default time: 11:59:00.321882+0000 process: SpringBoard subsystem: com.apple.runningboard category: process message: Firing exit handlers for 16876 with context <RBSProcessExitContext| specific, status:<RBSProcessExitStatus| domain:signal(2) code:SIGPIPE(13)>> The log message contains both SIGPIPE and the SIGPIPE signal number, 13. For more information about accessing the system log, see Your Friend the System Log. Locate the Problem Once you’ve confirmed that you have a broken pipe problem, you need to locate the source of it. That is, what code within your process is writing to a broken pipe? If you can reproduce the problem in Xcode, configure LLDB to stop on SIGPIPE signals: (lldb) process handle -s true SIGPIPE NAME PASS STOP NOTIFY =========== ===== ===== ====== SIGPIPE true true false When the process writes to a broken pipe, Xcode stops in the debugger. Look at the backtrace in the Debug navigator to find the offending write. If you can’t reproduce the problem in Xcode, one option is to add a signal handler that catches the SIGPIPE and triggers a crash. For example: #include <signal.h> static void sigpipeHandler(int sigNum) { __builtin_trap(); } extern void installSIGPIPEHandler(void) { signal(SIGPIPE, sigpipeHandler); } Here the signal handler, sigpipeHandler, forces a crash by calling the __builtin_trap function. IMPORTANT This code is in C, and uses __builtin_trap rather than abort, because of the very restricted environment in which the signal handler runs [1]. With this signal handler in place, writing to a broken pipe generates a crash report. Within that crash report, the crashing thread backtrace gives you a hint as to the location of the offending write. For example: 0 SIG-PIPETest … sigpipeHandler + 8 1 libsystem_platform.dylib … _sigtramp + 56 2 libswiftSystem.dylib … closure #1 in FileDescriptor._writeAll<A>(_:) + 100 3 libswiftSystem.dylib … partial apply for closure #1 in FileDescriptor._writeAll<A>(_:) + 20 4 libswiftSystem.dylib … partial apply for closure #1 in Sequence._withRawBufferPointer<A>(_:) + 108 5 libswiftCore.dylib … String.UTF8View.withContiguousStorageIfAvailable<A>(_:) + 108 6 libswiftCore.dylib … protocol witness for Sequence.withContiguousStorageIfAvailable<A>(_:) in conform… 7 libswiftCore.dylib … dispatch thunk of Sequence.withContiguousStorageIfAvailable<A>(_:) + 32 8 libswiftSystem.dylib … Sequence._withRawBufferPointer<A>(_:) + 472 9 libswiftSystem.dylib … FileDescriptor._writeAll<A>(_:) + 104 10 SIG-PIPETest … FileDescriptor.writeAll<A>(_:) + 28 … Note The write system call is not shown in the backtrace. That’s because the crash reporter is not backtracing correctly across the signal handler stack frame that was inserted by the kernel between frames 1 and 2 [1]. Fortunately that doesn’t matter here, because we primarily care about our code, which is visible in frame 10. I can’t see any problem with putting this code in your development build, or even deploying it to your beta testers. Think carefully before putting it in a production build that you deploy to all your users. Signal handlers are tricky [1]. [1] For all the gory details on that topic, see Implementing Your Own Crash Reporter for more information about that issue. [2] This is one of the gory details covered by Implementing Your Own Crash Reporter. Resolve the Problem The best way to resolve this problem depends on whether it’s being caused by a pipe or a socket. The socket case is easy: Use the SO_NOSIGPIPE socket option to disable SIGPIPE on the socket. Once you do that, writing to the socket when it’s disconnected will return an EPIPE error rather than raising the SIGPIPE signal. For example, you might tweak the code above like so: let (read, write) = try FileDescriptor.socketPair(AF_UNIX, SOCK_STREAM, 0) try read.setSocketOption(SOL_SOCKET, SO_NOSIGPIPE, 1 as CInt) try write.setSocketOption(SOL_SOCKET, SO_NOSIGPIPE, 1 as CInt) Note Again, this is using helpers from Calling BSD Sockets from Swift. The situation with pipes is tricky. Apple systems have no way to disable SIGPIPE on a pipe, leaving you with two less-than-ideal options: Disable SIGPIPE globally. To do this, call signal with SIG_IGN: signal(SIGPIPE, SIG_IGN) The downside to this approach is that affects the entire process. You can’t, for example, use this technique in library code. Switch to Unix domain sockets. Rather than use a pipe for your IPC, use Unix domain sockets instead. As they’re both file descriptors, it’s usually quite straightforward to make this change. The downside here is obvious: You need to modify your IPC code. That might be problematic, for example, if this IPC code is embedded in a framework that you don’t build from source.

We updated the apple-app-site-association file two weeks ago and we are only seeing the new content from Apple's CDN serving certain regions such as Texas and Canada. Regions such as Colorado intermittently sees the old content and California has been receiving the old content all the time. Is this a known issue? If yes, when can we expect this to be fixed and where to check the status? If not, can someone in charge of CDN please look into this? Let me know if there is a better place to report this issue and get the support ASAP though. Thank you in advance and happy new year!

My question Is there a way to perform an iCloud keychain reset in order to be able to test CKErrorUserDidResetEncryptedDataKey ? I found this section in the CloudKit documentation https://developer.apple.com/documentation/cloudkit/encrypting-user-data#Handle-a-User-Keychain-Reset I want to be prepared for the zoneNotFound / CKErrorUserDidResetEncryptedDataKey case. However, I can't find a way to actually reproduce this error with an iCloud (test-) user and can't find any Apple documentation on how to perform sucha "User Keychain Reset". The only thing that almost looked like it I came across was in the Keychain.app's Settings "Reset Default Keychains…". However, performing this didn't seem to affect the CloudKit data used in our App at all. I've been trying to do this with an Apple account that has 2FA active and a recovery account assigned. We're only targetting >= iOS 18, macOS >= 15.

My iOS application can execute a timer in the background on some devices, but it doesn't work on others. I attached my raw data to this post. The raw data includes the device ID, the iPhone model, and the iOS version. raw data: Can someone help me, please!

I have been using the hourly weather forecast API, for some reason sometimes the API fails with 400 Bad Request, but on retrying just a minute later the call successfully returns data. The start and end time are 2 days apart so I don't think it's an issue with the time frame. The failed calls also don't return any reason so not sure what is the exact failure. Has anyone encountered this issue or knows why this might be happening?? Thanks!!

Hey, I'm trying to update my old app that used DarkSky to WeatherKit, and struggling. I always get: ailed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" This is regardless if I do it on my iPad, or in the simulator. I have done the following: Selected WeatherKit on the Capabilities and App Services tabs of the Identifier section on developer. Put it under signing and capabilities in XCode I've tried making a new provisioning profile, cleaning build folder, etc. Not sure what to do here. I suspect part of this problem is that I developed this app in 2018 and now I'm trying to update it. I am able to run the app on TestFlight, but not as an internal tester. Apple won't let me, so I have to add myself as an external tester. Thanks for any help you can provide!

Hi All, I am trying to write an NWProtocolFramerImplementation that will run after Websockets. I would like to achieve two goals with this Handle the application-layer authentication handshake in-protocol so my external application code can ignore it Automatically send pings periodically so my application can ignore keepalive I am running into trouble because the NWProtocolWebsocket protocol parses websocket metadata into NWMessage's and I don't see how to handle this at the NWProtocolFramerImplementation level Here's what I have (see comments for questions) class CoolProtocol: NWProtocolFramerImplementation { static let label = "Cool" private var tempStatusCode: Int? required init(framer: NWProtocolFramer.Instance) {} static let definition = NWProtocolFramer.Definition(implementation: CoolProtocol.self) func start(framer: NWProtocolFramer.Instance) -> NWProtocolFramer.StartResult { return .willMarkReady } func wakeup(framer: NWProtocolFramer.Instance) { } func stop(framer: NWProtocolFramer.Instance) -> Bool { return true } func cleanup(framer: NWProtocolFramer.Instance) { } func handleOutput(framer: NWProtocolFramer.Instance, message: NWProtocolFramer.Message, messageLength: Int, isComplete: Bool) { // How to write a "Message" onto the next protocol handler. I don't want to just write plain data. // How to tell the websocket protocol framer that it's a ping/pong/text/binary... } func handleInput(framer: NWProtocolFramer.Instance) -> Int { // How to handle getting the input from websockets in a message format? I don't want to just get "Data" I would like to know if that data is // a ping, pong, text, binary, ... } } If I implementing this protocol at the application layer, here's how I would send websocket messages class Client { ... func send(string: String) async throws { guard let data = string.data(using: .utf8) else { return } let metadata = NWProtocolWebSocket.Metadata(opcode: .text) let context = NWConnection.ContentContext( identifier: "textContext", metadata: [metadata] ) self.connection.send( content: data, contentContext: context, isComplete: true, completion: .contentProcessed({ [weak self] error in ... }) ) } } You see at the application layer I have access to this context object and can access NWProtocolMetadata on the input and output side, but in NWProtocolFramer.Instance I only see final func writeOutput(data: Data) which doesn't seem to include context anywhere. Is this possible? If not how would you recommend I handle this? I know I could re-write the entire Websocket protocol framer, but it feels like I shouldn't have to if framers are supposed to be able to stack.

why is it that this code doesn't show the bluetooth device name but in the iOS settings it is displayed correctly. Thank you. import UIKit import CoreBluetooth import CoreLocation class BluetoothViewController: UIViewController, CBCentralManagerDelegate, CLLocationManagerDelegate { var centralManager: CBCentralManager! var locationManager: CLLocationManager! override func viewDidLoad() { super.viewDidLoad() // Initialize central manager centralManager = CBCentralManager(delegate: self, queue: nil) // Initialize location manager to request location access locationManager = CLLocationManager() locationManager.delegate = self } // CBCentralManagerDelegate Methods func centralManagerDidUpdateState(_ central: CBCentralManager) { switch central.state { case .poweredOn: // Bluetooth is powered on, request location permission if needed if CLLocationManager.locationServicesEnabled() { locationManager.requestWhenInUseAuthorization() } startScanning() case .poweredOff: print("Bluetooth is powered off.") case .resetting: print("Bluetooth is resetting.") case .unauthorized: print("Bluetooth is unauthorized.") case .unknown: print("Bluetooth state is unknown.") case .unsupported: print("Bluetooth is unsupported on this device.") @unknown default: fatalError("Unknown Bluetooth state.") } } func startScanning() { // Start scanning for devices (you can add service UUIDs to filter specific devices) centralManager.scanForPeripherals(withServices: nil, options: [CBScanOptionAllowDuplicatesKey: true]) print("Scanning for Bluetooth devices...") } func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi: NSNumber) { // This method is called when a peripheral is discovered let deviceName = peripheral.name ?? "Unknown" let deviceAddress = peripheral.identifier.uuidString print("Found device: \(deviceName), \(deviceAddress)") // Optionally, you can stop scanning after discovering a device // centralManager.stopScan() } func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) { print("Connected to peripheral: \(peripheral.name ?? "Unknown")") } // CLLocationManagerDelegate Methods (for location services) func locationManager(_ manager: CLLocationManager, didChangeAuthorization status: CLAuthorizationStatus) { if status == .authorizedWhenInUse { // Permission granted, now start scanning startScanning() } else { print("Location permission is required for Bluetooth scanning.") } } // Optionally handle when scanning stops or any errors occur func centralManager(_ central: CBCentralManager, didFailToConnect peripheral: CBPeripheral, error: Error?) { print("Failed to connect to peripheral: \(error?.localizedDescription ?? "Unknown error")") } func centralManager(_ central: CBCentralManager, didDisconnectPeripheral peripheral: CBPeripheral, error: Error?) { print("Disconnected from peripheral: \(peripheral.name ?? "Unknown")") } }

I am developing an app where the primary feature is to notify users. To deliver notifications more effectively, I am considering using PushKit and CallKit. Would it be acceptable under the guidelines to use PushKit and CallKit as an optional feature for an AI agent to notify users via a phone call?

No matter what I do whether I delete the app or reset my phone it still prompts me to log in to the previous sandbox test account. I'm not even signed into that account on my phone or in the App Store.

I am having issues loading in a mapkit snapshot. I get an error saying that https://domain.com and they're expecting domain.com. I have no idea what could be going wrong here. I set the domains properly in the mapkit tokens. When I click on the link it opens a new tab and loads what the data properly, but somehow in the application on production this error comes up.

Hello, thank you for your time. I'm using several physical devices to test IAPs in builds from xCode. Some of my test devices are logged into child accounts from my family account. Child accounts "Ask Permission" from devices logged into adult accounts in the family. when you attempt to make a purchase. I'm hoping to be able to use these devices to test my IAPs but I get the following error after supplying the password for the sandbox account: Unable to Ask Permission You can't ask permission because you have signed in with iCloud and iTunes accounts that are not associated with each other. [Environment: Sandbox] Is there any way to make this work?

I'm writing an app that uses text to speech. On the physical Iphone 12 it works but on the simulator I don't get any speech from my app. I tried the following to enable. Settings -> Accessebility -> "Spoken Content" -> "Speak Selecton" to ON (green) in Voices I added the German Anna that I use on my Iphone with the downloaded enhancements. The speech test works in this menu but not in my app. What am I missing ? Cheers, Gerhard

When simulating a Storekit error like an invalid device verification or others of that type, should we finish a failed transaction? When I test with a Storekit configuration file, all failed transactions persist after every restart. The Apple-provided sample code for Storekit 2 has transactions finished only when they are successful.

Hello. I have a few questions about the implementation of Apple Pay payments on websites. Could you help me From the documentation: Apple Pay issues an Apple Pay Merchant Token if the user’s payment network supports merchant-specific payment tokens. Otherwise, Apple Pay issues a device token for the payment request. How can we determine whether a token is a merchant token or a device token? Is it possible to determine this by any of the token fields? https://developer.apple.com/documentation/passkit/payment-token-format-reference Is it possible to understand this in other ways? Can I make recurring payments with the device token if it was issued instead of the merchant token? Is it necessary to include the tokenNotificationURL when generating a merchant token, or can we generate one without specifying it? What does the applicationExpirationDate field in the merchant token represent? Is this the date when the device token or merchant token expires and payments cannot be made with it?

hi i'm testing the new certificate. I'm using the p12 certificate and without doing anything, the sandbox can still be functioned. I assume the new certificate has already been installed in the default path by linux. so I execute openssl s_client -connect 17.188.143.34:443 -servername api.sandbox.push.apple.com -verifyCAfile /etc/pki/tls/certs/ca-bundle.crt -showcerts and i received CONNECTED(00000003) depth=2 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services verify return:1 depth=1 CN = Apple Public Server RSA CA 12 - G1, O = Apple Inc., ST = California, C = US verify return:1 depth=0 C = US, ST = California, O = Apple Inc., CN = api.development.push.apple.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/O=Apple Inc./CN=api.development.push.apple.com i:/CN=Apple Public Server RSA CA 12 - G1/O=Apple Inc./ST=California/C=US -----BEGIN CERTIFICATE----- ... so the server indeed has the certificate, is this correct?

Hi, My env. is .. Xcode: Version 16.2 (16C5032a) macOS Sequoia: Version 15.1 And I have 2 problems. Please give me the advice.. Failed Message. When I run the automatically generated app as it is, the following error(warning?) message appears in the terminal. Can't find or decode reasons Failed to get or decode unavailable reasons NSBundle file:///System/Library/PrivateFrameworks/MetalTools.framework/ principal class is nil because all fallbacks have failed Not on the simulator And the result is not running in the simulator, but instead appears as a window. (The simulator works fine when launched separately, but the app from the current project doesn’t show up in it.)