We are seeing a strange lifecycle issue on multiple MDM-managed iPads where
application(_:didFinishLaunchingWithOptions:) is not called after the device is idle overnight.
Even if we terminate the app manually via the app switcher, the next morning the system does not perform a cold launch. Instead, the app resumes directly in:
applicationDidBecomeActive(_:)
This causes all initialization logic that depends on didFinishLaunching to be completely skipped.
This behavior is consistent across four different supervised MDM devices.
Environment
Devices: iPads enrolled in MDM (supervised)
iOS version: 18.3
Xcode: 16.4
macOS: Sequoia 15.7.2
App type: Standard UIKit iOS app
App: Salux Audiometer (App Store app)
Expected Behavior
If the app was terminated manually using the app switcher, the next launch should:
Start a new process
Trigger application(_:didFinishLaunchingWithOptions:)
Follow the normal cold-start lifecycle
Actual Behavior
After leaving the iPad idle overnight (8–12 hours):
The next launch skips didFinishLaunching
The app resumes directly in applicationDidBecomeActive
No new process is started
App behaves as if it had been suspended, even though it was manually terminated
Logs (Relevant Extracts)
Day 1 — Normal cold launch
[12:06:44.152 PM] PROCESS_STARTED
[12:06:44.214 PM] DID_FINISH_LAUNCHING_START launchOptions=[]
[12:06:44.448 PM] DID_FINISH_LAUNCHING_END
We then used the app and terminated it via app switcher.
Day 2 — Unexpected resume without cold start
[12:57:49.328 PM] APP_DID_BECOME_ACTIVE
No PROCESS_STARTED
No didFinishLaunching
No cold-start logs
This means the OS resumed the app from a previous state that should not exist.
Reproducible Steps
Use an MDM-enrolled iPad.
Launch the app normally.
Terminate it manually via the multitasking app switcher.
Leave the device idle overnight (8–12 hours).
Launch the app the next morning.
Observe that:
didFinishLaunching does not fire
applicationDidBecomeActive fires directly
Questions for Apple Engineers / Community
Is this expected behavior on MDM-supervised devices in iOS 18?
Are there any known OS-level changes where terminated apps may be revived from disk/memory?
Could MDM restrictions or background restoration policies override app termination?
How can we ensure that our app always performs a clean initialization when launched after a long idle period?
Additional Information
We have full logs from four separate MDM iPads showing identical behavior.
Happy to share a minimal reproducible sample if required.
Delve into the world of built-in app and system services available to developers. Discuss leveraging these services to enhance your app's functionality and user experience.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
For other permission prompts in the iOS ecosystem, we have the option to configure the text shown in the prompt via keys in the Info.plist. This does not appear to be the case with regards to the age range permission prompt. The text of the prompt implies the app includes a differentiated experience for child or teen content and that confirming age unlocks more features (making it seem optional for using the app).
Is there a plan for app developers to be able to update that permission prompt similarly to how we can configure others?
If so, is there any timeline we can expect that on?
We are using AgeRangeService.requestAgeRange(ageGates:in:) with an age gate of 18 to verify adult users.
The system prompt always displays the lower-bound wording (“17 or Younger”), even when the app’s requirement is to verify users who are 18 or older. We understand the UI is system-controlled; however, this wording causes confusion for users, QA, and product teams, as it appears to indicate a child-only flow even when requesting adult verification.
Based on the demonstration video, it appears that they have another more coherent message.
In Apple's example, it is different, and it is correct that we need to specify 18 years or older in the implementation.
A little more context might be helpful, but we are creating a kind of wrapper with React Native that receives that value as a parameter, which is 18.
CloudKit CKRecordZone Deletion Issue
Problem: CloudKit record zones deleted via CKDatabase.modifyRecordZones(deleting:) or CKModifyRecordZonesOperation are successfully
removed but then reappear. I suspect they are automatically reinstated by CloudKit sync, despite successful deletion confirmation.
Environment:
SwiftData with CloudKit integration
Custom CloudKit zones created for legacy zone-based sharing
Observed Behavior:
Create custom zone (e.g., "TestZone1") via CKDatabase.modifyRecordZones(saving:)
Copy records to zone for sharing purposes
Delete zone using any CloudKit deletion API - returns success, no errors
Immediate verification: Zone is gone from database.allRecordZones()
After SwiftData/CloudKit sync or app restart: Zone reappears
Reproduction:
Tested with three different deletion methods - all exhibit same behaviour:
modifyRecordZones(deleting:) async API
CKModifyRecordZonesOperation (fire-and-forget)
CKModifyRecordZonesOperation with result callbacks
Zone deletion succeeds, change tokens (used to track updates to shared records) cleaned up
But zones are restored presumably by CloudKit background sync
Expected: Deleted zones should remain deleted
Actual: Zones are reinstated, creating orphaned zones
Trying to support undo & redo in an app that utilizes Swift Data and as with anything other than provided simplistic Apple demo examples the experience is not great.
The problem:
Im trying to build functionality that allows users to add items to an item group, where item and item group have a many-to-many relationship e.g. item group can hold many items and items can appear in multiple groups.
When trying to do so with relatively simple setup of either adding or removing item group from items relationship array, I am pretty consistently met with a hard crash after performing undo & redo. Sometimes it works the first few undo & redos but 95% of the time would crash on the first one.
Could not cast value of type 'Swift.Optional<Any>' (0x20a676be0) to 'Swift.Array<App.CodableStructModel>' (0x207a2bc08).
Where CodableStructModel is a Codable Value type inside Item.
Adding and removing this relationship should be undoable & redoable as typical for Mac interaction and is "supported" by SwiftData by default, meaning that the developer has to actively either wholly opt out of undo support in their modelContainer setup or do it on a per action scale with the only thing I know of:
modelContext.processPendingChanges()
modelContext.undoManager?.disableUndoRegistration()
.....
modelContext.processPendingChanges()
modelContext.undoManager?.enableUndoRegistration()
General rant on SwiftData:
Random crashes, inconsistencies, random cryptic errors thrown by the debugger and general lack of production level stability.
Each update breaks something new and there is very little guidance and communication from the Swift Data team on how to adapt and more importantly consideration for developers that have adopted Swift Data.
If SwiftData is not ready for production, it would go a long way to clearly communicate that and mark it as Beta product.
This is just an FYI in case someone else runs into this problem.
This afternoon (12 Dec 2025), I updated to macOS 26.2 and lost my network.
The System Settings' Wi-Fi light was green and said it was connected, but traceroute showed "No route to host".
I turned Wi-Fi on & off.
I rebooted the Mac.
I rebooted the eero network.
I switched to tethering to my iPhone.
I switched to physical ethernet cable.
Nothing worked.
Then I remembered I had a beta of an app with a network system extension that was distributed through TestFlight.
I deleted the app, and networking came right back.
I had this same problem ~2 years ago. Same story:
app with network system extension + TestFlight + macOS update = lost network.
(My TestFlight build might have expired, but I'm not certain)
I don't know if anyone else has had this problem, but I thought I'd share this in case it helps.
I’m implementing StoreKit External Purchase Custom Links (EU) and so far it is really painful. I am running into a strange, device-specific issue. On 3/4 devices it works. On one device I never get a token at launch nor before a transaction. isEligible is true everywhere. All devices have versions 18.5 and are located in Germany.
Info.plist: SKExternalPurchaseCustomLinkRegions is set to EU storefront codes and I have followed every step in the documentation: https://developer.apple.com/documentation/storekit/externalpurchasecustomlink
Good device: At launch → ACQUISITION = nil, SERVICES = token present. Works consistently.
Faulty device: At launch → ACQUISITION = nil, SERVICES = nil. Same before transaction. No token ever reaches my server from this device.
isEligible is true on both devices.
Any experts or help on the matter?
Topic:
App & System Services
SubTopic:
StoreKit
I have an app that uses BLE to connect to access doors. Since iOS 26, when it hasn't connected to any doors for a while, it deactivates, whereas in older versions of iOS it continues to work all day without stopping. Has anyone else experienced this? I've found problems with people who have had the same issue since upgrading to the latest version of iOS 26. Is there a known issue with BLE in iOS 26? I haven't found any official information. thnks
Topic:
App & System Services
SubTopic:
Networking
Tags:
Design
Enterprise
Playground Bluetooth
Core Bluetooth
Hello,
Recently we got a question about the keyboard sensor data collection in our research project:
"For the typing statistics, was any typing included or only messaging and notes? E.g., typing in the browser, phone search, calendar, etc?"
While I believe it should be any typing included, I was not able to find a document explicitly stating that. Could you help to confirm it or guide me to any documentation explaining it?
Thanks!
Hello,
After being in the AppStore for more than a year with the app working perfectly, yesterday I started seeing that WeatherKit requests failed with
Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)"
Encountered an error when fetching weather data subset; location=<+41.40217108,+2.20023642> +/- 0.00m (speed -1.00 mps / course -1.00) @ 13/12/25, 12:20:35 Central European Standard Time, error=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors 2 Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)"
I checked on developer.apple.com and we still have everything turned on and
No changes were made from an already deployed app; and we pay 200$ a month for WeatherKit, this is unacceptable since it's not the first time WeatherKit randomly decides to stop working.
More fun facts: the widget works fine...
I want to use FileProvder to implement the function of recovering from the recycle bin (the cloud recycle bin does not move, and after the local recycle bin is restored, the upload event is triggered again), but testing shows that the current recovery from the recycle bin is through the modifyItem event, and the CreateItem event is not triggered again to upload locally restored files
Implement the deletion of undelivered files (dateless) without moving them to the recycle bin, which currently appears to be achieved by granting file. dash permission. But it is possible for the content of a file to be manually verified by the user. How can this be solved? How can we dynamically monitor whether a file is dataless
Thank you for your reply. Could you please help answer my question
Greetings my fellow engineers,
I use SwiftData in my iOS app. The schema is unversioned and consists of a single model. I've been modifying the model for almost two years now and relying on automatic database migrations. I had no problems for all that time, but now trying to add a property to the model or even remove a property from the model results in an error which seems like SwiftData is no longer capable of performing an automatic migration.
The log console has things like the following:
CoreData: error: NSUnderlyingError : Error Domain=NSCocoaErrorDomain Code=134190 "(null)" UserInfo={reason=Each property must have a unique renaming identifier}
CoreData: error: reason : Can't find or automatically infer mapping model for migration
CoreData: error: storeType: SQLite
CoreData: error: configuration: default
CoreData: annotation: options:
CoreData: annotation: NSMigratePersistentStoresAutomaticallyOption : 1
CoreData: annotation: NSInferMappingModelAutomaticallyOption : 1
CoreData: annotation: NSPersistentStoreRemoteChangeNotificationOptionKey : 1
CoreData: annotation: NSPersistentHistoryTrackingKey : 1
CoreData: error: <NSPersistentStoreCoordinator: 0x7547b5480>: Attempting recovery from error encountered during addPersistentStore: 0x753f8d800 Error Domain=NSCocoaErrorDomain Code=134140 "Persistent store migration failed, missing mapping model."
Have you ever encountered such an issue? What are my options?
Hello,
I’m reviewing the open-source mDNSResponder repository and have a question regarding licensing/provenance in mDNSCore/DNSDigest.c file.
That file contains an embedded notice stating that parts of the MD5/digest implementation were derived from older OpenSSL sources and therefore include the legacy OpenSSL/SSLeay license text, even though OpenSSL itself is now Apache-2.0 starting from version 3.0.
The legacy OpenSSL/SSLeay license is widely understood to impose additional attribution and notice requirements compared to Apache-2.0, and some downstream projects prefer to avoid it when a permissively licensed alternative is available.
Repository: https://github.com/apple-oss-distributions/mDNSResponder
File: https://github.com/apple-oss-distributions/mDNSResponder/blob/main/mDNSCore/DNSDigest.c#L66
I’d like to clarify a few points:
Is the MD5/digest code in DNSDigest.c still based on pre–OpenSSL-3.0 sources, such that retaining the legacy OpenSSL/SSLeay license block is intentional and required?
If the goal were to simplify licensing (Apache-2.0 only), would Apple consider replacing this MD5 implementation with an Apache-2.0–licensed alternative (for example, code derived from OpenSSL 3.x or another permissive implementation)?
Are there any technical or policy reasons (compatibility, crypto policy, platform APIs) that make such a replacement undesirable?
Since GitHub issues and PRs are restricted for this repository, I’m asking here for guidance. If maintainers agree that such an update would be useful, I’d be happy to help by preparing a PR for review.
I've also created a feedback report for this topic, the reference ID is FB21269078.
Thanks for any clarification.
Hello team,
Would this mean that content filters intended for all browsing can only be implemented for managed devices using MDM? My goal would be to create a content filtering app for all users, regardless of if their device is managed/supervised.
thanks.
Topic:
App & System Services
SubTopic:
Networking
During Apple Pay in-app provisioning (EV_ECC_v2), our iOS app successfully obtains the issuer provisioning certificates and generates cryptographic material. The flow fails when Apple posts the card blob to Apple’s broker (card creation step), returning HTTP 500 from .../broker/v4/devices/{SEID}/cards.
Steps:
Call issuerProvisioningCertificates?encryptionVersion=EV_ECC_v2
→ 200 OK; returns ECC leaf + Apple Root CA chain; nonce=2a831be4.
2. Build {encryptedCardData, activationData, ephemeralPublicKey}
3. POST /broker/v4/devices/{SEID}/cards
Expected: 200 OK on /broker/v4/devices/{SEID}/cards, or 5xx with a descriptive error if payload/cryptography is invalid.
Observed: 500 Internal Server Error from Apple broker on /cards (labeled “eligibility” in PassKit logs), causing a terminal failure in Wallet UI.
Hello,
I’m integrating promotional offers for auto-renewable subscriptions using StoreKit 2.
The offer is displayed correctly, the Apple purchase sheet appears, and I can start the payment flow. The sheet shows the correct discounted price and the end date of the offer. However, after confirming the purchase, an alert appears saying “Unable to Purchase - Contact the developer for more information”
When dismissing the alert, Xcode logs the following:
Purchase did not return a transaction:
Error Domain=ASDServerErrorDomain Code=3902
"No se ha podido realizar la compra"
UserInfo={
NSLocalizedFailureReason=No se ha podido realizar la compra,
client-environment-type=Sandbox,
AMSServerErrorCode=3902,
storefront-country-code=ESP
}
Test environment:
App installed from Xcode on a real iPhone
Logged in with a Sandbox Apple ID
Using StoreKit 2
Promotional offer applied using:
Product.PurchaseOption.promotionalOffer(_:compactJWS:)
On the server side, I generate the promotional offer signature exactly as described in Apple’s documentation:
https://developer.apple.com/documentation/storekit/generating-a-signature-for-promotional-offers
The signature is generated using a Subscription Key
Signed with ECDSA + SHA256
Uses the correct invisible separator (U+2063)
The signature is validated locally using the derived public key and verifies correctly
The sandbox user has had previous subscriptions, which is why this promotional offer is eligible and shown.
Given that:
The offer is displayed correctly
The purchase sheet shows the discounted price and duration
The signature validates locally
The error occurs only after confirming the purchase
My question is:
Is this a known limitation or issue with promotional offers in the Sandbox environment?
Should promotional offers be tested exclusively via TestFlight instead of Sandbox?
Any clarification would be greatly appreciated.
Thank you!
Hello,
I am working to integrate the new com.apple.developer.networking.carrier-constrained.app-optimized entitlement in my iOS 26 app so that my app can use a carrier-provided satellite network, and want to confirm my understanding of how to detect and optimize for satellite network conditions.
(Ref: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.networking.carrier-constrained.app-optimized )
My current approach:
I plan to set the entitlement to true once my app is optimized for satellite networks.
To detect if the device is connected to a satellite network, I intend to use the Network framework’s NWPath properties:
isUltraConstrained — I understand this should be set to true when the device is connected to a satellite network.
(Ref: https://developer.apple.com/documentation/network/nwpath/isultraconstrained )
linkQuality == .minimal — I believe this will also be set in satellite scenarios, though it may not be exclusive to satellite connections.
(Ref:
https://developer.apple.com/documentation/network/nwpath/linkquality-swift.enum/minimal )
Questions:
Is it correct that isUltraConstrained will reliably indicate a satellite connection?
Should I also check for linkQuality == .minimal, or is isUltraConstrained sufficient?
Are there any additional APIs or best practices for detecting and optimizing for satellite connectivity that I should be aware of?
Thank you for confirming whether my understanding and approach are correct, and for any additional guidance.
When setting new entitlements com.apple.developer.networking.carrier-constrained.appcategory and com.apple.developer.networking.carrier-constrained.app-optimized, I have a question about how URLSession should behave.
I notice we have a way to specify whether a Network connection should allow ultra-constrained paths via
NWParameters allowUltraConstrainedPaths: https://developer.apple.com/documentation/network/nwparameters/allowultraconstrainedpaths
There does not appear to be a similar property on URLSessionConfiguration.
In an ultra-constrained (eg. satellite) network, should we expect all requests made through an URLSession to fail?
Does all network activity when ultra-constrained need to go through a NWConnection or NetworkConnection specifically configured with allowUltraConstrainedPaths, or can URLSession ever be configured to allow ultra-constrained paths?
Hello,
We are encountering an issue where invoking our App Clip via a Safari Smart App Banner fails on certain devices, particularly those running iOS 26.
When a user taps "Open" on the Smart App Banner, the App Clip card attempts to load but ultimately fails with ASDErrorDomain Error 507.
The error occurs consistently on specific devices, while other devices function correctly. In some instances, the App Clip card metadata/UI appears momentarily (flashes on the screen) before the error message is displayed and the process terminates.
Has anyone else experienced this specific ASDErrorDomain error? We have already submitted a report via Feedback Assistant, but any insights or workarounds from the community would be appreciated.
Thanks!
Facing an issue with audio playback using AVPlayerViewController in iOS application. We are using the native player to play recorded audio files.
When the AVPlayerViewController appears, the native user interface is displayed correctly, including the playback controls and the volume slider.
However, when the user interacts with the volume slider
The slider UI moves and responds to touch events.
The actual audio output volume does not change. The audio continues playing at the initial volume level regardless of the slider position.
We initialize the player and present it modally using the following code:
AVPlayerViewController *avController = [[AVPlayerViewController alloc] init];
avController.player = [AVPlayer playerWithURL:videoURL];
// Setting initial volume
avController.player.volume = 1.0f;
avController.modalPresentationStyle = UIModalPresentationOverFullScreen;
avController.allowsPictureInPicturePlayback = NO;
// Present the controller
[self presentViewController:avController animated:YES completion:nil];