Six months ago I wrote FB14122473, detailing how the built-in CDC (or FTDI) VCP serial port driver is limited to 3 Mbps or less. Thing is, there are some FTDI devices that can do 12 Mbps (maybe more), and I have devices I need to communicate with at 4 Mbps. I had to use the FTDI SDK to be able to communicate with these. I was hoping this post might help draw attention to that bug report.

Hello. In my app, I need to implement the following mechanism: I need to collect data from nearby Bluetooth devices, process them, and send this information to the server at short intervals, including when the app is minimized. Is this possible on iOS? BGProcessingTask has restrictions related to battery saving policies and does not guarantee task execution at specific intervals. Additionally, there is a limitation on background task execution, which can occur no more frequently than every 15 minutes. However, some apps, such as Google Maps, work in the background and update geolocation data. Could you suggest a solution for this task? Thanks for any help on this topic

Hello, I am currently developing a call service using CallKit and VoIP push. Recently, I have encountered a very challenging issue. During testing, when a VoIP push is received, the incomingCall gets triggered continuously, but then it automatically terminates after about 1-2 seconds. I am checking this issue under the debug scheme, and even when switching to different commits, the same problem persists. I suspect it might be an issue with the device, but I would like to confirm the cause and find a solution. Below are some characteristics I have noticed: On this device, when a VoIP push is received, CallKit automatically terminates, but this does not occur when debugging. The issue always occurs when not debugging. Looking at the device console logs related to callservicesd, there are many logs with 'invalidate' appended. For example: Invalidating process assertion for bundle ID from timeout All calls ended. Clearing system uplink muted cache Invalidate callDurationUpdateTimer InCallService has changed process state to 2 InCallService has been suspended; invalidating its XPC client connections. [0x565544180] invalidated because the current process cancelled the connection by calling xpc_connection_cancel() XPC connection invalidated from client These logs appear although our server did not receive any incoming call request, so we did not terminate it on our end. I also checked if there was a crash, but there were no reports left on the device. Could you please share any insights into the cause or solutions for this situation? Thank you.

I encountered a scenario involving a subscription and need to determine if it's a problem or an expected outcome. Here are the details: My service received a notification from Apple of type DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. The status field received on the payload was equal to 1 - Active. (2024-12-19T15:34:53.801) My service again received a DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. But the status field received was 2 - Expired. (2024-12-19T23:34:57.527) My service received an EXPIRED with subtype VOLUNTARY notification. (2024-12-19T23:35:01.669) Is the event 2 an inconsistent event? Since we are receiving a notification that means the auto renew was disabled when the subscription was already expired.

Hi Team, We are getting below error when we try to connect our REST APIs from our device. Our application is enterprise application and its connecting all backend calls via MobileIron Secure Tunnel(VPN). We are not encountering this error when we try to connect backend system from Simulator on VPN connected machine. We are calling 13 APIs but we are getting below error intermittently for different APIs i.e each time we are facing this issue for different APIs. We connected with our Helpdesk team to troubleshoot the error and they checked the MobileIron VPN firewall and there is no log We configured below things Allow Arbitrary Loads - True <key>NSExceptionMinimumTLSVersion</key> <string>TLSv1.2</string> We are using Alamofire library to connect backend. We disabled all site validation and we configured minTLSVersion 1.2. Please find below code snippet static let serverTrustPolicies:[String: ServerTrustEvaluating] = { var sites = [String]() sites.append("apis.xyz.com") return sites.reduce([String: ServerTrustEvaluating]()) { (dictionary, site) -> [String: Alamofire.ServerTrustEvaluating] in var dictionary = dictionary dictionary[site] = DisabledTrustEvaluator() return dictionary } }() static let manager: Session = { var serverTrustPolicies: [String: ServerTrustEvaluating] = NetworkClient.serverTrustPolicies let configuration = URLSessionConfiguration.default configuration.tlsMinimumSupportedProtocolVersion = .TLSv12 return Alamofire.Session(configuration: configuration, serverTrustManager: CustomTrustManager(evaluators: serverTrustPolicies)) }() error from Alamofire

So what's the point of being able to block unto 50 apps per ManagedSettingStore via store.application.blockedApplications (which works fine) until removing the blocked apps or clearing the store. Where the following occurs if you have a social networking group with more than 9 apps only 9 apps will go back into the group and all the others will go onto the springboard all jumbled if you end up with an empty group then tap into the group, it is removed then during the reset all apps are placed back on to the springboard

Recently, after updating the Developer app to the latest version, my iPad has been unable to open this app as it crashes immediately upon launch. Prior to the update, the app functioned normally. My device is an 11-inch iPad Pro from 2021, running iPadOS 17.3. I have tried troubleshooting steps such as reinstalling the app and restarting the device, but these actions have not resolved the issue. However, I need to use this specific version of the system, iPadOS 17.3, for software testing purposes and cannot upgrade the system. Other apps on my device work normally without any issues. Is there a solution to this problem? I have attempted to contact the developer support team in China, but they were also unable to provide a resolution. This issue is reproducible 100% of the time on my iPad.

I've noticed several crashes that look like they're caused by an index out of bound in internal methods of NSFetchedResultsController. This happens while changes are merged from the persistent store container into the view context. Here's an example of the last exception backtrace. Exactly which internal methods that are called in - [NSFetchedResultsController(PrivateMethods) _core_managedObjectContextDidChange:] vary between crash reports but they all end up crashing from _NSArrayRaiseBoundException. The Core Data stack consists of one persistent store, one persistent store coordinator that the view context is set up to automatically merge changes from, and data is saved to disk from background context. persistentContainer.loadPersistentStores(...) viewContext = persistentContainer.viewContext viewContext.automaticallyMergesChangesFromParent = true backgroundContext = persistentContainer.newBackgroundContext() backgroundContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy backgroundClientContext = persistentContainer.newBackgroundContext() backgroundClientContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy Does anyone have any ideas what could be causing this? Thankful for any ideas or advice on how to investigate further.

Several users have reported that my iOS Action and Share Extensions is not visible. Now one of the TestFlight users has reported the same. Notice this user has been using the app for one year, so they know how to use it. Doing FaceTime and them sharing the screen, we have tried: Deleting app and downloading from App Store Deleting app, turning device off (call was off) and turning it on, downloading from App Store Deleting app, turning device off (call was off) and turning it on, downloading from TestFlight They can open the app, they just do not see the extensions. I would have thought it was the activation rules inside of the InfoPlist, but they are the same for all users and my other testers are not facing the issue. Device is iPhone 16 Pro, iOS 18.1 What other steps could I follow? What other information could I gather to fix this?

在执行完 INIntent 或者AppIntent的Shortcuts后，刷新 WidgetKit桌面小组件

After transferring the App ownership to a different account, if you update the app on iOS, two identical apps will show up in Settings > Screen Time. Users can't control the blocking settings from before the update - the only fix is to restart the phone. After the next execution of manageStore.shield.applications, users still can't manually disable the restrictions - their only option is to uninstall and reinstall the app. I believe this is related to how Screen Time API's authentication works - it's not just tied to the app's bundle ID, but also linked to the developer account's organization ID. Any suggestions for a clean solution that would allow smooth app updates after the transfer without running into these issues?

I'm trying to create an Apple Pay session for my website. I'm starting with curl for now, just to get proof of concept. curl --cert cert.pem --pass {passphrase} --header "Content-Type: application/json" --request POST --data '{"merchantIdentifier":"{merchantIdentifier}","displayName":"testDisplayName", "initiative": "web", "initiativeContext": "{domain}"}' https://apple-pay-gateway.apple.com/paymentservices/paymentSession This is the response I get back { "statusMessage": "Payment Services Exception merchantId={VERY-LONG-ID} not registered for domain={domain}", "statusCode": "400" } I'm not sure why this is happening. {domain} is in the form of sub.site.tld with no protocol, such as https, which matches what I see in the list of the domains in the merchant identity dashboard. The {merchantIdentifier} also matches what I see in the top right, but the merchantId in the response is something I don't recognize. It's a long string of characters that appears to be hexadecimal. I added the apple-developer-merchantid-domain-association file to my .well-known directory and the dashboard does report that the domain is verified. I am making the request from the web server that the domain resolves to, if that matters. I can't think of any reason this would be happening. I'm not sure where the long merchantId in the response is coming from. Does it matter that it doesn't match what I supplied in the request? As far as I can tell, I am using the correct merchantIdentifier. It matches the dashboard and the CN field of the certificate. I found this other post that seems to have a similar error: https://forums.developer.apple.com/forums/thread/671227 The main difference is a 417 status code instead of the 400 I got. But the problem here was that there was no payment processing certificate and I do have one of those. I haven't checked with my processor to verify that the certificate is published, but I will do that soon. I wouldn't expect that to matter. Maybe it does? What other reason could I be getting this error? Could it be a problem with my merchant identity certificate? It took a lot of effort to make it work. But I suspect it's fine, otherwise I wouldn't be getting a response from Apple at all. I can't think of any other possible problems.

I'm working with the Apple Watch's acceleration data and have referred to the document Identify the coordinate axes of the device. According to this document, the X-axis points to the right side of the watch, the Y-axis points towards the top side, and the Z-axis points towards the user. However, when I place the watch on a flat surface and move it horizontally to the right, I observe that the X-axis acceleration is negative. Similarly, when I move the watch vertically upwards, the Y-axis acceleration also shows a negative value. Is this expected behavior, or am I misunderstanding something about the coordinate system or acceleration readings?

Hi, I've some issues on my application about purchases. My app is available for iOS and tvOS. Some part of my code is the same on both target (my purchase code is one of them). The issue is: Some users can't do a purchase on Apple TV (but not all and I can't reproduce) Some users purchased on a device and are not considered as pro on the other device (logged with same apple account). Again it's not all. Here is my store code

Dear Team, we are from Austria and want to test our apple pay on the web implementation via Apple Sandbox. As far as we can see Austria is not on the list that sandbox supports Apple Pay testing for. Can you please advise how can we move forward with testing? We have already created and also tried out our Sandbox account on iPhone 11 and successfully added test cards to the Wallet. Can we expect please in later stage some restrictions due to our region? Thank you in advance. Iveta

Greetings! I was reviewing the documentation for the Apple Store Server Notification v1 APIs and saw the deprecation notice. We are currently unable to migrate to v2 in the near future. With that in mind, I want to know if there were any plans to shut off v1, and if so, was there any timeline we could expect? Thank you in advance. Reference: https://developer.apple.com/documentation/appstoreservernotifications/app-store-server-notifications-version-1

Trial Rollout: 652eff3d1bce5442b8d753c9 (ramp:654d29cb7e430f0ea5135e4b namespaces:VISUAL_INTELLIGENCE_RICH_LABEL_I18N) Trial Rollout: 654439cdafbf5b61207873a9 (ramp:65443b27f764584e3e121677 namespaces:SIRI_DATA_SHARING_MTE_OPT_OUT) Trial Rollout: 6090733d1c1e594b6765e603 (ramp:61f1fd4757c72d21f3fd20dc namespaces:WIRELESS_DATA_ANALYTICS_SIS_FR2HARVESTING) Trial Rollout: 63f9578e238e7b23a1f3030a (ramp:64af3a8e3789f0013152c6ea namespaces:SMART_REPLY_ACTIONS_EN) Trial Rollout: 64c17a9925d75a7281053d4c (ramp:64d297de1008ca2fac17a1dc namespaces:SIRI_AUDIO_DISABLE_MEDIA_ENTITY_SYNC) Trial Rollout: 64628732bf2f5257dedc8988 (ramp:651ca4291993407e6d574317 namespaces:) Trial Rollout: 6434420a89ec2e0a7a38bf5a (ramp:64c96f230d0abc3f1813bdab namespaces:) Trial Rollout: 639124e81d92412bfb4880b3 (ramp:63ffdf0ac679dd6bc58280c1 namespaces:SIRI_UNDERSTANDING_TMDC) Trial Rollout: 6246d6a916a70b047e454124 (ramp:6449728db0bf6a06721af761 namespaces:WALLET_APP_ECOM_PAYMENT_SHEET) Trial Rollout: 6425c75e4327780c10cc4252 (ramp:642b12bf4327780c10cc42e5 namespaces:SIRI_HOME_AUTOMATION_INTENT_SELECTION_CACHE) Trial Rollout: 60f8ddccefea4203d95cbeef (ramp:640141a8c679dd6bc5828185 namespaces:) Trial Rollout: 5f72dc58705eff005a46b3a9 (ramp:63d9571c2cb48e1296b0749a namespaces:SIRI_VIDEO_APP_SELECTION) Trial Rollout: 5fb4245a1bbfe8005e33a1e1 (ramp:635c675bc8a2104545a56d45 namespaces:) Trial Rollout: 60356660bbe37970735c5624 (ramp:618b79164b3765609b8b8252 namespaces:) Trial Rollout: 60da5e84ab0ca017dace9abf (ramp:6137762b61217b31102314aa namespaces:) Trial Rollout: 6081ed9716bb6d61d81d5014 (ramp:67953013d0a7cc3ee9718297 namespaces:BIFROST_PROD_1) Trial Rollout: 601074e4af9bef000c169ea8 (ramp:67953105c871785bbdefd35c namespaces:BIFROST_DEV_1) Trial Rollout: 6761d0c9df60af01adb250fb (ramp:6788a4224ebe024683e5aa2e namespaces:)

Has anyone had any success enabling Apple Pay checkout for a Google Chrome or Firefox users (macOS or PC)? This was rolled out in iOS 18 but Shopify support hasn't been able to help: https://www.theverge.com/2024/6/13/24177851/apple-ios-18-pay-chrome-scanning-code-wwdc-2024 Thanks

I have a SwiftData model where I need to customize behavior based on the value of a property (connectorType). Here’s a simplified version of my model: @Model public final class ConnectorModel { public var connectorType: String ... func doSomethingDifferentForEveryConnectorType() { ... } } I’d like to implement doSomethingDifferentForEveryConnectorType in a way that allows the behavior to vary depending on connectorType, and I want to follow best practices for scalability and maintainability. I’ve come up with three potential solutions, each with pros and cons, and I’d love to hear your thoughts on which one makes the most sense or if there’s a better approach: **Option 1: Use switch Statements ** func doSomethingDifferentForEveryConnectorType() { switch connectorType { case "HTTP": // HTTP-specific logic case "WebSocket": // WebSocket-specific logic default: // Fallback logic } } Pros: Simple to implement and keeps the SwiftData model observable by SwiftUI without any additional wrapping. Cons: If more behaviors or methods are added, the code could become messy and harder to maintain. **Option 2: Use a Wrapper with Inheritance around swiftdata model ** @Observable class ParentConnector { var connectorModel: ConnectorModel init(connectorModel: ConnectorModel) { self.connectorModel = connectorModel } func doSomethingDifferentForEveryConnectorType() { fatalError("Not implemented") } } @Observable class HTTPConnector: ParentConnector { override func doSomethingDifferentForEveryConnectorType() { // HTTP-specific logic } } Pros: Logic for each connector type is cleanly organized in subclasses, making it easy to extend and maintain. Cons: Requires introducing additional observable classes, which could add unnecessary complexity. **Option 3: Use a @Transient class that customizes behavior ** protocol ConnectorProtocol { func doSomethingDifferentForEveryConnectorType(connectorModel: ConnectorModel) } class HTTPConnectorImplementation: ConnectorProtocol { func doSomethingDifferentForEveryConnectorType(connectorModel: ConnectorModel) { // HTTP-specific logic } } Then add this to the model: @Model public final class ConnectorModel { public var connectorType: String @Transient public var connectorImplementation: ConnectorProtocol? // Or alternatively from swiftui I could call myModel.connectorImplementation.doSomethingDifferentForEveryConnectorType() to avoid this wrapper func doSomethingDifferentForEveryConnectorType() { connectorImplementation?.doSomethingDifferentForEveryConnectorType(connectorModel: self) } } Pros: Decouples model logic from connector-specific behavior. Avoids creating additional observable classes and allows for easy extension. Cons: Requires explicitly passing the model to the protocol implementation, and setup for determining the correct implementation needs to be handled elsewhere. My Questions Which approach aligns best with SwiftData and SwiftUI best practices, especially for scalable and maintainable apps? Are there better alternatives that I haven’t considered? If Option 3 (protocol with dependency injection) is preferred, what’s the best way to a)manage the transient property 2) set the correct implementation and 3) pass reference to swiftdata model? Thanks in advance for your advice!

I've noticed that very consistently the Weatherkit API times out when I make a large(-ish) number of calls at 7am east coast time. If I make x calls between 7:00:00 and 7:01:00 about half of them time out (as do retries.) If I make 2x the calls between 7:15:00 and 7:16:00 there are close to zero time outs. I've looked at the logs, at the calls per second, etc., and there is no difference between 7 and 7:15. So, I'm not hitting a rate limit. It seems like Weatherkit itself just can't handle the traffic at peak times. Is there any other explanation? Does Apple intend to make sure the API can handle all the traffic they are getting paid to handle?