Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for

Hi, thanks for posting this — I've been hitting the exact same wall. I'm building a screen time management app and spent considerable time trying to persist per-app usage data from the DeviceActivityReportExtension to the App Group container. I exhaustively tested every storage mechanism available: Core Data, JSON files, UserDefaults (App Group suite), Keychain, raw POSIX syscalls, SQLite, iCloud KV, and NSUbiquitousKeyValueStore. All fail with permission errors — the extension is completely write-locked at the kernel level (POSIX errno 1 / EPERM). I also confirmed the DeviceActivityMonitor extension has the same restriction. So I'm very interested in your finding that the host app can reconstruct raw activity data from the report. Could you share more about the technique you used? Specifically: How does your host app access the data from the report extension? Is it through the rendered view hierarchy, some callback mechanism, or something else entirely? Are you able to get per-app bundle identifiers

Thanks for this awesome post. Yes, low power will trigger the device to go night night if possible. This is a great post for other developers to provide tips and ticks how to keep the device awake on a recording session. https://developer.apple.com/documentation/uikit/uiapplication/isidletimerdisabled Your approach of setting is indeed the standard way to achieve this. However, certain power management features, like Adaptive Power Mode, can override these settings, as you've observed. Ensure that you have an active configured while recording. This typically helps in signaling to the system that media capture is in progress, which should naturally prevent the device from sleeping. Unfortunately, iOS doesn't provide public APIs to directly detect Adaptive Power Mode specifically. However, you can check for Low Power Mode . While this doesn't exactly map to Adaptive Power Mode, it can still be useful for alerting users. Since detecting Adaptive Power Mode isn't directly possible, consider displaying a

Thank you for your post. I must admit that I am not entirely clear on your question regarding creating a Live Activity for a remote hosting environment. I believe I may have misunderstood your inquiry. Could you please provide me with additional details to clarify your objectives? As currently, Live Activities are designed primarily for iOS devices, and they appear on the Lock Screen and Control Center. December 16, 2025 Updated guidance for all platforms, and added guidance for macOS and CarPlay. https://developer.apple.com/design/human-interface-guidelines/live-activities/ If you want to bring Live Activities to Apple Watch: https://developer.apple.com/videos/play/wwdc2024/10068/ Including the documentation for the live activities guide. The widget configuration api to position a widget: https://developer.apple.com/documentation/swiftui/widgetconfiguration/disfavoredlocations(_:for:) Thanks, Albert Pascual
  Worldwide Developer Relations.

I am testing my iOS app on iOS 18. I performed 50 tests, and in 43–44 of them, the app successfully detects beacons, relaunches in the background, and continues BLE communication. Testing how? What are the details of the process you're actually using to test this? That is, are you: Artificial Testing” -> Laying the phone on a desk next to the beacon and toggling the beacon (or shielding the phone) on/off to simulate entry and exit. VS. Real World Testing” -> Carrying the phone around in your pocket and seeing what happens. Beyond that, what are the broader parameters of the test itself? How far is the device from the beacon? How long is the device exposed to the beacon? What's the broader use case you're trying to implement? Most importantly, what, if anything, do you know about EXACTLY what was happening when the failure occurred? I want to understand why beacon triggers are inconsistent in iOS. What are the common reasons behind iOS not relaunching the app

First, please check the document NFC & SE Platform for secure contactless transactions for the requirements and regional availability of NFC support with Secure Element. NFCTagReaderSession cannot be used for payment cards. You will need to use alternate CoreNFC APIs, which are only available via special entitlements and agreements. The document above will also explain the requirements for getting access to those APIs. Eventually, you will need to enter into an agreement with Apple and request the NFC & SE Platform Entitlement, if you satisfy the requirements as listed in the document above. If you are not able to use those APIs, PassKit framework will be your only remaining option, if appropriate. If you have already requested the relevant entitlements, if approved, you will receive further guidance on how to proceed with your development.

@DTS Engineer Yes, this is still possible, even with this constraint. If you intend on creating your .swiftpm project via Xcode, you can add local Swift packages. See the below image where I successfully build an Xcode App Playground project with a local package: However, this will not work if you use the Swift Playgrounds app, so users should be aware of this limitation: Also keep in mind that the package must only contain Swift code. If there is any non-Swift code, the project will refuse to build.

There have been some behavioral changes on N1 chip devices; especially in areas where the BT spec has not had a single way of interpreting things. We have been observing these changes and changing them back if appropriate and are considered regressions. So, the first thing you should do is to test all this in the latest iOS 26.3 and see if anything has changed from your earlier observations. Also, there would have been some changes on patterns of use that were never meant to work, but just happened to work, and those would have been corrected. For example, scanning without services is not supposed to work, and was never expected to work in the background. If you are scanning in the background without services, and whatever the Flutter library may have been doing to work around that limitation (if anything), and that has stopped working, you can consider that a bug that has been fixed. Similarly, advertising packets in the background have always been on a best effort basis. Also, it has always been po

Thank you so much for your quick response and for looking into this! I have already addressed the technical issue regarding Guideline 5.1.2 by implementing the ATT prompt correctly on the Welcome Screen in the latest build (1.0.4+5), which is currently 'Waiting for Review'. I truly appreciate the guidance. Looking forward to a successful review! Kindest regards, Jose Rodriguez

Whether iOS provides any mechanism or API that allows iPhone apps to trigger or request parental re-approval after the application has already been installed PermissionKit has that for you: https://developer.apple.com/documentation/PermissionKit/SignificantAppUpdateTopic Also from which iOS version this capabilities will work & how to handle lower iOS version which is not supporting. The APIs seem to only be supported in iOS 26.2 and above. The laws say that A developer shall verify through the app store's data sharing methods.... Since Apple has not provided any data sharing method for users on iOS versions before 26.2, my interpretation is that we do not need to do any age verification for users on older versions of iOS, but I can not be sure at this time and this is not legal advice. I doubt Apple will provide any recommendation since doing that could be considered legal advice. The only way we will know for sure though is for the deadlines to pass,