file uri scheme

On another thread davpea wrote: [quote='866396022, davpea, /thread/807383?answerId=866396022#866396022, /profile/davpea'] Is there a bug report for this / do you know if its being addressed soon (MacOS 26.2) ?? [/quote] I’ve seen a bunch of forums threads about this but no one on those threads has posted a bug number. Without that, it’s hard to say anything about this issue. I recommend that you file your own bug about it. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There seems to be multiple parts to your question: Downloading content Managing files in the Documents directory Displaying that content Which one are you having problems with? This is important because it informs how to route your question. For example, if you’re having problems with URLSession then that’s something I can help you with, but I’m not the best person to talk to about UI frameworks. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi, While I have tried to highlight all the necessary configurations and details related to my project in the above message, I have also attached a drive link with the project zip file. Please check the same for any issues with my project. [https://drive.google.com/file/d/12POHIXTmhVNg9H5VsP53P7gq--U1aXdA/view?usp=sharing]

Thank you for your response. Here is the AASA file URL as requested: https://pre-api.tcc-ltd.sa/.well-known/apple-app-site-association To clarify, I fully understand that using Developer Mode allows us to bypass the Apple CDN and test Universal Links internally, and in that scenario everything works correctly within our target country environment. However, the issue arises when the app is distributed via the App Store. In production, Apple CDN servers located outside our target country attempt to fetch the AASA file, and since our firewall is configured to allow access only from within the target country, those external requests are blocked. This results in Universal Links not functioning for end users, even though they are located inside the allowed region. Our goal is to ensure that Universal Links work for real users in our target country without relaxing our geographic firewall policy for external IPs. Could you please advise if there are any recommended approaches or best practices for

Yes. Currently, one of our corporate clients has reported an issue with my application. Upon analyzing the application log file from when the incident occurred, we identified ENOTCONN as the cause. We have not received similar reports from other clients. The total number of logs received is limited, and at this time we have only been able to identify the cause from the app logs in one case.

Just to be clear, do you mean to change the icon of the file provider name in the sidebar, the Adobe Drive here, as shown in your screenshot? Best, —— Ziqiao Chen  Worldwide Developer Relations.

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

Hello. I talked to engineering about your question and LUT based display profiles have never been supported on Apple Platforms. You may wish to file an enhancement request asking for support for these types of profiles. You can file an enhancement request as a feedback report.

Xcode doesn't pass these environment variables to lldb when it runs it, nor does it preprocess the .lldbinit files to insert these variables. We don't pass them to lldb as there's too much chance one of them really wouldn't be appropriate for lldb and cause hard to diagnose problems. And since .lldbinit files can contain arbitrary user expressions, preprocessing can also cause problems. Instead, the suggested way to do this is to make a target specific lldbinit file - as you have done - and in that file bring in all the .py files you need using command script import --relative-to-command-file ./my_python_files/my_python_file.py That allows you to give the paths to all your python files relative to the target-specific .lldbinit file without having to know where any of them actually are. Note, the same option exists for sourcing other files of lldb commands using command source.

Everyone except one user (so far) who has reached out to report nothing happens when they tap the Start Processing button. First off, how do you know that? And what other devices have you tested on? That particular device does NOT have a dynamic island, so starting a task doesn't necessarily have any visible impact. The task DOES start, but you won't see any system UI unless the app is backgrounded or there are other tasks active. Next, moving to the bug here: I submitted a bug report FB21052216 If your user is willing to help, what we really need is a sysdiagnose. The basic process is: Reproduce the issue a few times. Capture and collect the sysdiagnose. Upload that file to the bug. The only warning here is to not reboot the device until the sysdiagnose is captured, since the reboot will lose log data. Jumping back to your earlier post: Or have I done something wrong in the implementation? I don't see any obvious mistake in your implementation, but there were two things I would double-check: Remembe

Thanks for filing a bug report. I checked on its status and it has yet to be assigned to an engineering team for investigation. Of course, I should have mentioned earlier, since this is fixed in 18.6 the workaround in this case is to upgrade to 18.6. Have you tested in iOS 26 or later? Does this problem occur there?

Thanks for filing some bugs. I checked and they're still being routed to engineering teams. I'll check back later with a status update.

Apologies for the extended delay. I comprehend the geographic restrictions, but your server should permit requests for the AASA file from any IP address and user agent. Without this capability, the AASA file cannot be downloaded and utilized. Could you please provide a link to the file in question? Without access to that file from your server, I am unable to identify any alternative methods to obtain access to the Universal Links. Albert Pascual
  Worldwide Developer Relations.