file uri scheme

[quote='865567022, siracusa, /thread/804395?answerId=865567022#865567022, /profile/siracusa'] My app also has a default Main Menu in its Main.storyboard file because it has a setting to decide if the app should show a Dock icon and menu bar or not (honored by callingNSApp.setActivationPolicy(…) at runtime). I get these warnings about the default menus in the main menu bar when my app launches. [/quote] It seems I get these too! I wasn’t looking at what my app was logging right after launch. The app I forked had a feature like this one in SwitchGlass. I had stripped out that feature, among so many others, but was considering add it back and so left the .nib in the app. So a good guess might be that any LSUIElement app nevertheless with a main menu logs these warnings. The similar warnings about my NSStatusItem menu, it seems they however are no longer being emitted under 26.2 beta (sadly I didn't check 26.1). So if one datapoint can be extrapolated into a trend, perhaps the main menu logs will eventua

Hi Kevin, TL;DR (Core Issues) 100% Reproducible: We used two completely independent test methods (cp + sync and fio buffered mode), and both consistently reproduced the data corruption issue under Buffered I/O. Clear Failure Threshold: Both tests point to the exact same failure boundary: file sizes 128MB (inclusive) and below pass, but 256MB (inclusive) and above consistently fail. Key Clue Confirmed: The fio test again reported the exact same error as our initial finding: data corruption starts at a very precise offset 1048576 (1MB) location. You mentioned last time that this offset was odd; now we can confirm this is not a coincidence, but a core characteristic of the problem. Test 1: System-Level File Copy Integrity Test (cp + sync) This test aims to simulate standard user operations to rule out tool-specific issues. Methodology: We used a shell script to automate cp for file copying, used sync to force the system to flush I/O caches, and finally compared the SHA256 hashes of the

Please file your concerns using Feedback Assistant.

So using the class constructor is pretty much the only reasonable way around this. I'm marking this reply as the correct answer. You can also avoid the crash by setting UIDesignRequiresCompatibility to YES in your Info.plist and use the pre Liquid Glass UI. maybe I'd file a bug but I don't think Apple responded to like 95% of my Catalyst bugs I reported in the past. I must have reported more than a dozen so I'm not going to be filing this one. FYI if you migrate to the group class constructor... if you have to do any per item tweaks you can apparently just dig in the subitems array right after you create the GroupItem (to set different actions on particular subitems etc.) HOPEFULLY they don't release an update that breaks that.

We've observed that the I/O behavior differs drastically depending on whether it goes through the system file cache: Quick question— how are you validating what the actual issue is? More specifically, are you pulling, unmounting the device, and testing with a known good driver? Or are you testing with your development DEXT? That's crucial because testing through your DEXT means you don't know whether this is a write or a read issue. That leads to here: At the end of the operation, to ensure data is flushed to disk, the macOS file system issues an fsync, which is ultimately translated into a SYNCHRONIZE CACHE SCSI command (Opcode 0x35 or 0x91) and sent to our UserProcessParallelTask_Impl. Are you sure about that? How have you validated that? I haven't tried to validate the entire I/O path, but I’m fairly sure that copyfile() (what cp calls) does not call fsync(). FYI, the history here is somewhat complicated and “ugly, but in general, if the system were going specifically trying to flush data

Is the AASA file only consulted on a fresh install or would an upgrade potentially trigger a similar scenario? We've had some users with an existing passkey upgrade our app, immediately launch it and then not have their passkeys found. A subsequent start of the app seems to remedy the situation however.

Hi @durul The ability to access your enterprise license files directly within your Apple Developer account isn't available just yet. I'll follow up on this thread as soon as it is.

I think the tricky part here is what support here actually means. Yeah, I was actually having a bit of trouble trying to think of a title for this post (and for the aforementioned FB21068845). If either of those behave differently, then that's a HUGE bug that we'd need to fix ASAP. I didn't actually check those two (write isn't implemented at all in my filesystem). While it would take a little longer to check actual writes I just checked and FSBlockDeviceResource.isWritable is returning the correct value (false) when mounted as read-only, so I think that part is okay, at least! I think the best approach here is to support permissions (FSItemAttributeMode), and then ALWAYS return a configuration for all objects that prevents writing and fail any attempt to modify mode I actually have tried this. There's this code in my real project: if request.isAttributeWanted(.mode) { // FIXME: not correct way to enforce read-only file system but does FSKit currently have a better way? let useMode = readOnlySystem ?

Hi @sashamoroz, this is a known issue that the engineering team is currently investigating. You can also file a bug report through the Feedback Assistant to be notified when the original bug is closed. After filing the bug report, please post the bug number.

Are read-only filesystems currently supported by FSKit? I think the tricky part here is what support here actually means. Let me start by what this actually does: pass the -r or -o rdonly options to the mount(8) command. Passing that to mount should mean that the VFS layer itself is prevented from writing to the device. In FSKit terms, that means FSBlockDeviceResource.writable should be false and that all write methods should fail. If either of those behave differently, then that's a HUGE bug that we'd need to fix ASAP. However, the confusing point here is that mounting a volume readonly doesn't necessarily define/change how the file system presents itself to the higher level system. That is, strictly speaking, nothing prevents a volume being mounted readonly... but that file system itself allowing itself to be fully modifiable. That might sound a bit strange, but as a concrete example, you could implement a resettable file system by using the on-disk file system as the sta

This sounds like a possible regression. Can you file a feedback using Feedback Assistant and attach a sample project that reproduces the issue? Once you do, reply with the Feedback ID

Thank you for your post. So many questions that I’ll try to answer. iOS carefully manages link-handling preferences to strike a balance between user convenience and security. Here is an overview that may be helpful in addressing your questions. iOS stores link-handling preferences globally, associating domains with either applications or Safari through Universal Links. When Universal Links are utilized, iOS verifies permission by checking a specially configured file (apple-app-site-association) hosted on the associated domain. Uninstalling an application does not reset link-handling preferences, as iOS retains the domain association in its system-level storage. The association persists until manually overridden by the user or cleared through advanced methods (e.g., resetting all settings). In some instances, long-pressing a link in Safari allows the user to select “Open in App” temporarily, overriding the previous setting. Once a user selects “Open in App” or “Open in Browser,” iOS retains this choic

This sounds like a possible framework issue. Can you file a feedback through Feedback Assistant and attach a sample project that reproduces the issue? Once you do, reply with the Feedback ID.

If you want to provide more information and a way to extend the AlarmKit framework I would recommend to file an enhancement request. If you'd like us to consider adding the necessary functionality, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number here. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.