Note: This document is specifically focused on what happens after a DEXT has passed its initial code-signing checks. Code-signing issues are dealt with in other posts.
Preliminary Guidance:
Using and understanding DriverKit basically requires understanding IOKit, something which isn't entirely clear in our documentation. The good news here is that IOKit actually does have fairly good "foundational" documentation in the documentation archive. Here are a few of the documents I'd take a look at:
IOKit Fundamentals
IOKit Device Driver Design Guidelines
Accessing Hardware From Applications
Special mention to QA1075: "Making sense of IOKit error codes",, which I happened to notice today and which documents the IOReturn error format (which is a bit weird on first review).
Those documents do not cover the full DEXT loading process, but they are the foundation of how all of this actually works.
Understanding the IOKitPersonalities Dictionary
The first thing to understand here is that the "IOKitPersonalities" is called that because it is in fact a fully valid "IOKitPersonalities" dictionary. That is, what the system actually uses that dictionary "for" is:
Perform a standard IOKit match and load cycle in the kernel.
The final driver in the kernel then uses the DEXT-specific data to launch and run your DEXT process outside the kernel.
So, working through the critical keys in that dictionary:
"IOProviderClass"-> This is the in-kernel class that your in-kernel driver loads "on top" of. The IOKit documentation and naming convention uses the term "Nub", but the naming convention is not consistent enough that it applies to all cases.
"IOClass"-> This is the in-kernel class that your driver loads on top of. This is where things can become a bit confused, as some families work by:
Routing all activity through the provider reference so that the DEXT-specific class does not matter (PCIDriverKit).
Having the DEXT subclass a specific subclass which corresponds to a specific kernel driver (SCSIPeripheralsDriverKit).
This distinction is described in the documentation, but it's easy to overlook if you don't understand what's going on. However, compare PCIDriverKit:
"When the system loads your custom PCI driver, it passes an IOPCIDevice object as the provider to your driver. Use that object to read and write the configuration and memory of your PCI hardware."
Versus SCSIPeripheralsDriverKit:
Develop your driver by subclassing IOUserSCSIPeripheralDeviceType00 or IOUserSCSIPeripheralDeviceType05, depending on whether your device works with SCSI Block Commands (SBC) or SCSI Multimedia Commands (SMC), respectively. In your subclass, override all methods the framework declares as pure virtual.
The reason these differences exist actually comes from the relationship and interactions between the DEXT families. Case in point, PCIDriverKit doesn't require a specific subclass because it wants SCSIControllerDriverKit DEXTs to be able to directly load "above" it.
Note that the common mistake many developers make is leaving "IOUserService" in place when they should have specified a family-specific subclass (case 2 above). This is an undocumented implementation detail, but if there is a mismatch between your DEXT driver ("IOUserSCSIPeripheralDeviceType00") and your kernel driver ("IOUserService"), you end up trying to call unimplemented kernel methods. When a method is "missing" like that, the codegen system ends up handling that by returning kIOReturnUnsupported.
One special case here is the "IOUserResources" provider. This class is the DEXT equivalent of "IOResources" in the kernel. In both cases, these classes exist as an attachment point for objects which don't otherwise have a provider. It's specifically used by the sample "Communicating between a DriverKit extension and a client app" to allow that sample to load on all hardware but is not something the vast majority of DEXT will use.
Following on from that point, most DEXT should NOT include "IOMatchCategory". Quoting IOKit fundamentals:
"Important: Any driver that declares IOResources as the value of its IOProviderClass key must also include in its personality the IOMatchCategory key and a private match category value. This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it. It also prevents the driver from having to compete with all other drivers that need to match on IOResources. The value of the IOMatchCategory property should be identical to the value of the driver's IOClass property, which is the driver’s class name in reverse-DNS notation with underbars instead of dots, such as com_MyCompany_driver_MyDriver."
The critical point here is that including IOMatchCategory does this:
"This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it."
The problem here is that this is actually the exceptional case. For a typical DEXT, including IOMatchCategory means that a system driver will load "beside" their DEXT, then open the provider blocking DEXT access and breaking the DEXT.
DEXT Launching
The key point here is that the entire process above is the standard IOKit loading process used by all KEXT. Once that process finishes, what actually happens next is the DEXT-specific part of this process:
IOUserServerName-> This key is the bundle ID of your DEXT, which the system uses to find your DEXT target.
IOUserClass-> This is the name of the class the system instantiates after launching your DEXT. Note that this directly mimics how IOKit loading works.
Keep in mind that the second, DEXT-specific, half of this process is the first point your actual code becomes relevant. Any issue before that point will ONLY be visible through kernel logging or possibly the IORegistry.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
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
I'm building out a live activity that has a button which is meant to update the content state of the Live Activity. It calls a LiveActivityIntent that runs in the app process.
The push server starts my live activity and the buttons work just fine. I pass the push token back to the server for further updates and when the next update is pushed by the server the buttons no longer work. With the debugger I'm able to verify the app intent code runs and passes the updated state to the activity. However the activity never updates or re-renders. There are no logs in Xcode or Console.app that indicates what the issue could be or that the update is ignored.
I have also tried adding the frequent updates key to my plist with no change.
I'm updating the live activity in the LiveActivityIntent like this:
public func perform() async throws -> some IntentResult {
let activities = Activity<WidgetExtensionAttributes>.activities
for activity in activities {
let currentState = activity.content.state
let currentIndex = currentState.pageIndex ?? 0
let maxIndex = max(0, currentState.items.count - 1)
let newIndex: Int
if forward {
newIndex = min(currentIndex + 1, maxIndex)
} else {
newIndex = max(currentIndex - 1, 0)
}
var newState = currentState
newState.pageIndex = newIndex
await activity.update(
ActivityContent(
state: newState,
staleDate: nil
),
alertConfiguration: nil,
timestamp: Date()
)
}
return .result()
}
To sum up:
Push to start -> tap button on activity -> All good!
Push to start -> push update -> tap button -> No good...
Topic:
App & System Services
SubTopic:
Widgets & Live Activities
Tags:
APNS
Intents
App Intents
ActivityKit
G'day.
At my office the doors are locked with an NFC reader. We carry around a little NFC tag on our key chains which will read out a number and this then will open the door if the number matches a number in the database.
I am tired of carrying around the tag, people keep loosing it, forgetting it and it would be nice to open the door using a Phone - which we tend to always have on us.
So I used a credit card which is NFC enabled to readout the NFC information, added this number to the database and can now open doors using my credit card. This is pretty cool. If I forget my keys (most likely they will be on the desk but silly me left the desk without them), I may have my wallet with me.
Then I tried Wallet.app on my iPhone and select the same credit card. However the door doesn't open. When looking in the door software I noticed that the tags will always transmit the same number. So does my credit card. However Wallet.app will read out 4 readings (or maybe just one very long one) and they are always different. So I can not make them match with the door database.
Any ideas how to make this work? Can I give somehow wallet.app an NFC number which I can then add to my door database? Or how come the credit card and the very same one in wallet.app don't match?
Thanks for your help! Would be neat if I could make this work out. This will make a lot of people happy at my office!
Cheers!
My app has in app purchase for subscriptions, available in many countries. When using Sandbox App Store accounts on TestFlight with a locale different from my own in the iOS 26 RC, I'm getting incorrect currency coming back from Product.products(for: identifiers), and so my app displays the wrong price for the locale. However, the actual Apple Pay buy sheet shows the proper currency symbol and currency amount. This did not happen on prior versions of iOS.
Is anyone else experiencing this?
Hi everyone,
I’m running into an App Store Connect issue that seems to be a misclassification, and I’m hoping someone (or Apple staff) can help clarify or advise.
App: Quick Quote Calculator
Platform: iOS (built with Expo)
App type: Business
No navigation, routing, maps, or turn-by-turn directions
When submitting a new build, App Store Connect returns:
ITMS-90118: Invalid routing app setting
To upload a routing app coverage file, you must define the app binary as a routing app.
However:
There is no “Routing & Navigation” section in App Information
There is no “Routing App Coverage File” section under App Store
No routing metadata or coverage file has ever been uploaded
The app does not provide routing or navigation functionality
It appears the binary itself is being classified as a routing app, but there is no UI in App Store Connect to view or remove this classification.
What I’ve tried
Verified app metadata and screenshots
Confirmed no routing/navigation APIs are used
Reviewed Info.plist permissions (no routing language)
Uploaded a new build with incremented build number
Has anyone run into a case where a routing flag is applied at the binary level and the Routing App options are not exposed in App Store Connect?
Is the only resolution to have Apple manually remove the routing classification via App Review / Developer Support?
Any insight from Apple staff or devs who’ve resolved this would be hugely appreciated.
Thanks in advance!
Yes — the app is strictly a business quote calculator for trades. It calculates distance (Miles via addresses) but does not display maps, routes, directions, or navigation of any kind.
Topic:
App & System Services
SubTopic:
Maps & Location
I've tried pass different value like 13,16,18, but I don't see any difference..? could anyone tell what could happen differently if I pass a different value here?
Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows.
Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate.
A few observations:
The issue is not limited to the latest app version, it also affects older versions.
It appears to occur only on iOS 17+.
The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days.
At the moment, there are no related incidents reported on Apple’s System Status page.
Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet.
Has anyone else observed similar StoreKit behavior recently on iOS 17+?
Any insights or known issues would be greatly appreciated.
I'm scanning for peripherals, and keep references to multiple CBUUIDs - one for each peripheral.
I then start a connection to the peripheral.
I never get a callback to say the connection succeeded, failed, or disconnected.
I have a Mini-Moreph Bluetooth sniffer. The sniffer shows that the iPhone never tried to connect to any of the peripherals.
The iPhone HCI logs show that a create connection request was sent, but a cancel connection request was sent 0.018 seconds later. No feedback was given to my application through CoreBluetooth.
I've filed this through Feedback Assistant, but expect nothing will come of the report.
We recently migrated our entire product to Apple Unified Logging due to the various benefits it provides. However we immediately started hitting the "log quarantine" problem ("QUARANTINED DUE TO HIGH LOGGING VOLUME"). This is partly because we are indeed over logging in a few cases (which we have to work on fixing), but also partly because it's a complicated product with potentially hundreds of libraries, and some of the code can legitimately be very busy. For example we have a system extension that's implemented both as a NetworkExtension client and an EndpointSecurity client, if we were to log decent information about each network or file system event so we can troubleshoot something, they are bound to be high volume logs.
Now when our app is running in a normal user environment, this is not a problem. We can disable certain heavy log levels, or at least disable persisting for certain logs (one of the benefits of Apple Unified Logging we really like is that it allows very flexible controls, log config command, OSLogPreferences, configuration profile, we can employ whatever that suits a specific case). But ultimately, the question is what if we end up with a troubleshooting case we don't know exactly where a problem is so we just need the full logs at debug level? And not only just enabled, but because we might not know when the issue can happen either we also need to persist the full set of logs for as long as possible? We will start hitting log quarantine again. Granted this is a very extreme case, but if worst comes to worst, how can we even do that with Apple Unified Logging? Is there an option that allows us to override the quarantine, if but temporarily?
I've searched a few relevant forum posts, some of which described log quarantine but no one had mentioned any solution for it (besides having to stop logging so much from the app but as I explained we do have legitimate cases where log volume can still be huge). I've also read The Eskimo's "Your Friend the System Log" and browsed some of the troubleshooting config profiles provided by Apple hoping to discover some hidden payloads but found none so far.
There is an OSLogRateLimit environment variable that I noticed if I run a launchctl print system/<a-launch-daemon-lable> and it's usually 64. Is this something relevant? And knowing Apple it's probably something that can't be tampered with?
I just spend the morning debugging LocationButton and the associated CLLocationManagerDelegate only to realise that it works perfectly in iOS 18.5 but no longer works for me in iOS 26.0, 26.2 or 26.2.1 (the latter on-device). It does work when I run my app on macOS 26.2 (Designed for iPad).
Is there a change in behaviour or requirements on iOS I am missing?
On iOS 18.5 I observe that the authorisation status changes from .notDetermined to .authorizedWhenInUse after the LocationButton has been tapped and my delegate is able to obtain the location through locationManager(_ , didUpdateLocations:).
On iOS 26.x the authorisation status remains .notDetermined and my delegate receives locationManager(_:didFailWithError:) with error code .denied.
Setting NSLocationWhenInUseUsageDescription in my Info.plistdid not help.
Just in case ;) FB21798098 (SwiftUI LocationButton fails to acquire authorization on iOS 26)
When I've tried to use UIDevice on my Mac running my Catalyst application, testing code
UIDevice *d=UIDevice.currentDevice;
for (NSString *k in @[@"name", @"systemName", @"systemVersion", @"model", @"localizedModel"])
NSLog(@"%@ -> %@", k, [d valueForKey:k]);
to my great surprise I am getting
name -> iPad
systemName -> iPadOS
systemVersion -> 26.3
model -> iPad
localizedModel -> iPad
What the. How do I determine the real values? Thanks!
Hello,
I have an app that is using iOS 26 Network Framework APIs.
It is using QUIC, TLS 1.3 and Bonjour. For TLS I am using a PKCS#12 identity.
All works well and as expected if the devices (iPhone with no cellular, iPhone with cellular, and iPad no cellular) are all on the same wifi network.
If I turn off my router (ie no more wifi network) and leave on the wifi toggle on the iOS devices - only the non cellular iPhone and iPad are able to discovery and connect to each other. My iPhone with cellular is not able to.
By sharing my logs with Cursor AI it was determined that the connection between the two problematic peers (iPad with no cellular and iPhone with cellular) never even makes it to the TLS step because I never see the logs where I print out the certs I compare.
I tried doing "builder.requiredInterfaceType(.wifi)" but doing that blocked the two non cellular devices from working. I also tried "builder.prohibitedInterfaceTypes([.cellular])" but that also did not work.
Is AWDL on it's way out? Should I focus my energy on Wi-Fi Aware?
Regards,
Captadoh
Subject: iOS Fails to Fetch AASA File for Internationalized Domain Names (IDN) in Unicode or Punycode Format
Dear Apple Developer Relations Team And Community Members,
We are reporting a critical bug in the iOS Associated Domains feature that prevents Universal Links from working for apps using Internationalized Domain Names (IDN).
Problem Description:
The iOS operating system does not attempt to download the apple-app-site-association (AASA) file for domains containing non-ASCII characters (e.g., diacritics, Cyrillic).
This failure occurs regardless of whether the domain is specified in the app's entitlements in its human-readable Unicode format (e.g., montréal.ca) or its encoded Punycode format (e.g., xn--montral-fya.ca, xn--e1afka0abm4b.xn--p1ai).
Without fetching and validating this file, Universal Links are not activated, and the system fails to establish a connection between the website and our app.
Steps to Reproduce:
Create an app with the Associated Domains entitlement enabled.
Add an IDN to the entitlement. We tested both formats:
Format A (Unicode): applinks://montréal.ca
Format B (Punycode): applinks://xn--montral-fya.ca
Host a valid AASA file on our server at the correct, accessible well-known URLs for both domain representations:
For montréal.ca: https://montréal.ca/.well-known/apple-app-site-association and https://xn--montral-fya.ca/.well-known/apple-app-site-association
Install the app on a device running the latest iOS version.
Monitor network traffic using a tool like Charles Proxy.
Observed Result:
No HTTP GET request is made to any of the AASA URLs for the domains montréal.ca (in either Unicode or Punycode format) upon app installation. The system does not initiate the domain validation process. In contrast, for a standard ASCII domain (e.g., applinks://example.com), the AASA fetch is triggered immediately and is observed in the network log.
Expected Result:
iOS should correctly resolve the Internationalized Domain Name (whether specified in Unicode or Punycode format in the entitlement) and perform an HTTP GET request to fetch the AASA file from the /.well-known path, identical to its behavior for ASCII domains.
Evidence & Configuration:
Our server is configured correctly: SSL certificates are valid, the AASA file is served with the correct application/json MIME type, and is directly accessible via a browser or curl.
The AASA file's syntax has been validated and is correct.
The issue is reproducible on the latest versions of iOS.
Impact:
This bug blocks a core platform feature for millions of users in regions that use non-Latin scripts (e.g., France, Russia, China, Arab states). It makes it impossible to use Universal Links with our primary domains, severely degrading the user experience and forcing us to seek suboptimal workarounds like registering separate ASCII domains.
Request:
We kindly request that you investigate and log this issue as a bug in iOS and forward it to the appropriate engineering team for a fix in an upcoming update. We are prepared to provide any additional information, demo projects, or server access to assist in diagnostics.
Thank you for your attention to this serious matter.
Hello Apple Developer Community,
I'm working on implementing App Clips for a restaurant platform and need guidance on configuring custom App Clip experiences using URL redirects.
Context:
We have multiple restaurant locations, each needing branded App Clip cards (custom image, title, subtitle). With hundreds of tables across many venues, creating individual App Clip experiences for each table in App Store Connect isn't scalable.
Currently:
Using a single, generic App Clip experience for all locations => https://example.com
Desired Flow:
Customer scans QR code at restaurant table
↓
https://example.com/123
↓
iOS fetches URL
↓
Server responds with 302 redirect
↓
https://example.com/brands/le-pain-quotidien?venue=abc123
↓
iOS displays App Clip card with "Le Pain Quotidien" branding
↓
User taps "Open" → App Clip launches with correct context
What I've Tried:
Configured multiple App Clip experiences in App Store Connect
Implemented 302 redirects from short URLs to branded URLs
Tested various redirect configurations without success
Questions:
Does iOS fetch and follow redirects before displaying the App Clip card, or does it only use the originally scanned URL?
What App Clip experience URLs should be configured in App Store Connect for this redirect scenario?
Are there specific HTTP headers or redirect requirements for iOS to properly recognize the final destination?
Should the App Clip experience be registered for example.com/123 or example.com/brands/le-pain-quotidien?
Reference:
Apple's documentation suggests this is possible:
https://developer.apple.com/documentation/AppClip/configuring-the-launch-experience-of-your-app-clip#Use-short-URLs-or-redirects
Has anyone successfully implemented custom App Clip cards using URL redirects? Any guidance on the correct configuration approach would be greatly appreciated.
Thank you!
I added a Content Filter to my app, and when running it in Xcode (Debug/Release), I get the expected permission prompt:
"Would like to filter network content (Allow / Don't Allow)".
However, when I install the app via TestFlight, this prompt doesn’t appear at all, and the feature doesn’t work.
Is there a special configuration required for TestFlight? Has anyone encountered this issue before?
Thanks!
Hi!
I was able to successfully persist my debug log entires using the OSLogPreferences key in my Info.plist and retrieve the logs from my iPhone using log collect.
This worked to get log messages created when my app executed a background task tonight (2026-01-20 00:20). But log Debug and Default log messages from a normal run yesterday (2026-01-19 15:34) disappeared.
I can query for the missing messages in the log archive I created yesterday but they are missing in the log archive I created today covering also yesterday. I had invoked:
% sudo log collect --device-name "<my device name>" --last 25h --output /tmp/system_logs.logarchive
...
%sudo log show /tmp/system_logs.logarchive --debug --info --predicate 'subsystem=="com.example.MyApp"'
Is this expected and/or is there anything I could do to persist the logs for a longer period?
For reference, that's what I have added to my Info.plist for the debug build configuration so far:
<key>OSLogPreferences</key>
<dict>
<key>com.example.MyApp</key>
<dict>
<key>DEFAULT-OPTIONS</key>
<dict>
<key>Level</key>
<dict>
<key>Enable</key>
<string>Debug</string>
<key>Persist</key>
<string>Debug</string>
</dict>
<key>Enable-Private-Data</key>
<true/>
</dict>
</dict>
</dict>
Environment:
Xcode 26
iOS 26
Also tested on iOS 18 (working correctly)
Description:
I'm experiencing a behavior change with URL(fileURLWithPath:) when the filename starts with a tilde (~) character.
On iOS 18, passing a filename like ~MyFile.txt to URL(fileURLWithPath:) treats the tilde as a literal character. However, on iOS 26, the same code resolves the tilde as the home directory, resulting in unexpected output.
Minimal Example:
let filename = "~MyFile.txt"
let url = URL(fileURLWithPath: filename)
print(url.lastPathComponent)
Expected Result (iOS 18):
~MyFile.txt
Actual Result (iOS 26):
924AF0C4-C3CD-417A-9D5F-733FBB8FCF29
The tilde is being resolved to the app's container directory, and lastPathComponent returns the container UUID instead of the filename.
Questions:
1. Is this an intentional behavior change in iOS 26? 2. Is there documentation about this change? 3. What is the recommended approach for extracting filename components when the filename may contain special characters like ~?
Workaround:
Using NSString.lastPathComponent works correctly on both iOS versions:
let filename = "~MyFile.txt"
let result = (filename as NSString).lastPathComponent
// Returns: "~MyFile.txt" ✅
Is this the recommended approach going forward?
Description
Our NETransparentProxyProvider system extension maintains a persistent TLS/DTLS control channel to a security gateway. To maintain this stateful connection the extension sends application-level "Keep Alive" packets every few seconds (example : 20 seconds).
The Issue: When the macOS device enters a sleep state, the Network Extension process is suspended, causing our application-level heartbeat to cease. Consequently, our backend gateway—detecting no activity—terminates the session via Dead Peer Detection (DPD).
The problem is exacerbated by macOS Dark Wake cycles. We observe the extension's wake() callback being triggered periodically (approx. every 15 minutes) while the device remains in a sleep state (lid closed). During these brief windows:
The extension attempts to use the existing socket, finds it terminated by the backend, and initiates a full re-handshake.
Shortly after the connection is re-established, the OS triggers the sleep() callback and suspends the process again.
This creates a "connection churn" cycle that generates excessive telemetry noise and misleading "Session Disconnected" alerts for our enterprise customers.
Steps to Reproduce
Activate Proxy:
Start the NETransparentProxyProvider and establish a TLS session to a gateway.
Apply Settings: Configure NETransparentProxyNetworkSettings to intercept outbound TCP/UDP traffic.
Initialize Heartbeat: Start a 20-second timer (DispatchSourceTimer) to log and send keep-alive packets.
Induce Sleep: Put the Mac to sleep (Apple Menu > Sleep).
Observe Logs: Monitor the system via sysdiagnose or the macOS Console.
Observation: Logs stop entirely during sleep, indicating process suspension.
Observation: wake() and sleep() callbacks are triggered repeatedly during Dark Wake intervals, causing a cycle of re-connections.
Expected Behavior
We seek to minimize connection turnover during maintenance wakes and maintain session stability while the device is technically in a sleep state.
Questions for Apple
Is it possible to suppress the sleep and wake callback methods of NETransparentProxyProvider when the device is performing a maintenance/Dark Wake, only triggering them for a full user-initiated wake?
Is it possible to prevent the NETransparentProxyProvider process from being suspended during sleep, or at least grant it a high-priority background execution slot to maintain the heartbeat?
If suspension is mandatory, is there a recommended way to utilize TCP_KEEPALIVE socket options that the kernel can handle on behalf of the suspended extension?
How can the extension programmatically identify if a wake() call is a "Dark Wake" versus a "Full User Wake" to avoid unnecessary re-connection logic?
As part of iOS 26, we get X25519MLKEM768 key exchange group support, but SecP256r1MLKEM768 and SecP384r1MLKEM1024 are not supported. Is there any way to enable these key exchange groups on iOS 26? We need them for WKWebView and NSURLSession.
STEPS TO REPRODUCE
On iOS 26, connect to the PQC server using Safari.
The key exchange group is limited to X25519MLKEM768.
I've implemented
func urlSession(_ session: URLSession, task: URLSessionTask, willPerformHTTPRedirection response: HTTPURLResponse, newRequest request: URLRequest, completionHandler: @escaping (URLRequest?) -> Void)
and
func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64)
I've put a breakpoint in each but the BP in willPerformHTTPRedirection never fires.
When the didWriteData fires and I inspect downloadTask.originalRequest I see my original request URL
When I inspect downloadTask.currentRequest the returned request contains a different URL.
I'm the farthest thing from an HTTP wizard, but I had thought when originalRequest differs from currentRequest there had been some sort of server-side 'redirection'.
Is there a way for my code to receive a callback when something like this happens?
NOTE: my download code works fine, I'm just hoping to detect the case when currentRequest changes.
any/all guidance greatly appreciated
on the off chance it helps, are are my original and current request values:
(lldb) po downloadTask.originalRequest
▿ Optional<URLRequest>
▿ some : https://audio.listennotes.com/e/p/c524803c1a90412f922948274ecc3625/
(lldb) po downloadTask.currentRequest
▿ Optional<URLRequest>
▿ some : https://26973.mc.tritondigital.com:443/OMNY_HAPPIERWITHGRETCHENRUBIN_PODCAST_P/media-session/76cfceb2-1801-4570-b830-ded57611a9cf/d/clips/796469f9-ea34-46a2-8776-ad0f015d6beb/e1b22d0b-6974-4bb8-81ba-b2480119983c/2f35a8ca-b982-44e9-8122-b3dc000ae0e1/audio/direct/t1769587393/Ep_571_Want_to_Join_Us_for_a_No-Spend_February_Plus_a_Better_Word_for_Squats.mp3?t=1769587393&in_playlist=751ada7f-ded3-44b9-bfb8-b2480119985b&utm_source=Podcast