Hi Greg, yes! FB8110522, FB9076636, and related: FB9076641. My goal is to read digital elevation and other GIS data, which is often distributed as GeoTIFF files. GeoTIFF is a standard for a set of TIFF tags that provides information on how to interpret and georeference the data stored in the TIFF image data. As such, pixel value don't necessarily represent colors, but can represent any number of properties, chiefly altitude. I've needed to read files that were both 16-bit integer and 32-bit float values in meters. The GeoTIFF tags provide information on how the 2D extent maps to lat/lon, and how the altitude values are to be interpreted relative to the geoid model of the earth (or whatever planet the data may be for). These TIFF files are also sometimes BigTIFF (http://bigtiff.org/), for which I filed FB9076641, but I think macOS 14.5 supports BigTIFF. The GeoTIFF standard (https://www.ogc.org/standard/geotiff/) specifies a half-dozen TIFF tags that contain within them a second set of ”geokeys.” This was done so avoid polluting the limited TIFF tags namespace. The current version of the standard: https://docs.ogc.org/is/19-008r4/19-008r4.html I am unable to attach a file to this reply (both image and file attachment leave my files disabled in the open panel). Here is a link to a GeoTIFF file (although it is not BigTIFF): https://jetforme-org.sfo2.cdn.digitaloceanspaces.com/misc/posts/2024-07/test1.tiff tiffdump for the above image: % tiffdump Magic: 0x4949 <little-endian> Version: 0x2a <ClassicTIFF> Directory 0: offset 8 (0x8) next 0 (0) ImageWidth (256) SHORT (3) 1<10210> ImageLength (257) SHORT (3) 1<4720> BitsPerSample (258) SHORT (3) 1<32> Compression (259) SHORT (3) 1<8> Photometric (262) SHORT (3) 1<1> SamplesPerPixel (277) SHORT (3) 1<1> PlanarConfig (284) SHORT (3) 1<1> Predictor (317) SHORT (3) 1<1> TileWidth (322) SHORT (3) 1<512> TileLength (323) SHORT (3) 1<512> TileOffsets (324) LONG (4) 200<offsets> TileByteCounts (325) LONG (4) 200<offsets> SampleFormat (339) SHORT (3) 1<3> 33550 (0x830e) DOUBLE (12) 3<9.25926e-05 9.25926e-05 0> 33922 (0x8482) DOUBLE (12) 6<0 0 0 -119.106 34.1844 0> 34735 (0x87af) SHORT (3) 32<1 1 0 7 1024 0 1 2 1025 0 1 1 2048 0 1 4269 2049 34737 6 0 2054 0 1 9102 ...> 34736 (0x87b0) DOUBLE (12) 2<298.257 6.37814e+06>34737 (0x87b1) ASCII (2) 7<NAD83|\0> GDALNoDataValue (42113) ASCII (2) 8<-999999\0> Note the tags with IDs 33550, 33922, 34735, 34737, 34736, 34737. Those are the GeoTIFF tags. Also note that I am not asking Apple to parse these tags, although that would be very nice. What I would like is for all TIFF tags and other TIFF metadata to be accessible (and ideally, writeable) via some macOS/iOS/visionOS API, in a generic way. That way we can all leverage the extensible nature of TIFF. Just give me the data inside the TIFF tag; I'll parse the GeoKeys. (Note that this forum would not let me mark up links above. Wow, it also wouldn't let me include the integers for the tile offsets and byte counts in the dump above, saying there was inappropriate language in the post. I had to bisect it and update it multiple times to track down the specific language, as it would not say what it didn't like. Apparently it doesn't like strings of integers.)

Oh I see. I'm looking at test results, not the build. That's confusing, as they both show errors. Since the test didn't run, I would've preferred it just take me to the error in the build transcript.

I was able to do this by adding a module.modulemap file to the Headers. This is all within my library Package project: // swift-tools-version: 6.0 import PackageDescription /** This package wraps FTDI’s D2XX library for macOS. In order to simp xcodebuild -create-xcframework -library /Users/rmann/Downloads/lib3mf_sdk_v2.3.1/Bin/lib3mf.dylib -headers /Users/rmann/Downloads/lib3mf_sdk_v2.3.1/Bindings/C -output lib3mf.xcframework */ let package = Package( name: "SwiftD2XX", platforms: [.macOS(.v13)], products: [ .library( name: "SwiftD2XX", targets: ["SwiftD2XX"] ), ], dependencies: [ .package(url: "https://github.com/apple/swift-testing.git", branch: "main"), ], targets: [ .target( name: "SwiftD2XX", dependencies: [ "ftd2xx" ] ), .binaryTarget( name: "ftd2xx", path: "../ftd2xx.xcframework" ), .testTarget( name: "SwiftD2XXTests", dependencies: [ "SwiftD2XX", .product(name: "Testing", package: "swift-testing"), ] ), ] ) When I build my xcframework, I use this: xcodebuild -create-xcframework -library ftdi-d2xx/build/libftd2xx.a -headers ./headers -output ftd2xx.xcframework And the headers folder contains not only the headers for the xcframework, but a module.modulemap: module ftd2xx { header "ftd2xx.h" export * } This ends up getting copied into the xcframework’s Headers directory, and that allows other modules to import it (in this case, via import ftd2xx).

There’s another reason why I think it's wrong for tcsetattr to not accept arbitrary speeds: If you set the port speed with ioctl, then read the terminal settings, the struct will show the actual set speed, even if it's an "invalid" speed. If you then modify some aspect of the termios struct (say, the timeout), and try to tcsetattr, it will fail, because it doesn't accept the speed.

I tried to find the implementation of tcsetattr in the XNU sources, but it's not there (only the headers). FWIW, I filed FB13989879.

The macOS man page says The input and output baud rates are found in the termios structure. The unsigned integer speed_t is typedef'd in the include file ⟨termios.h⟩. The value of the integer corresponds directly to the baud rate being represented; however, the following symbolic values are defined and goes on to list the defined speeds. It notably does not say only those speeds are allowed. It seems to me there’s no good reason to restrict the setting to those values, only that it should accept at least those values. If ioctl can set the speed, meaning the underlying drivers and hardware can handle it, surely tcsetattr shouldn’t make a point of failing. Moreover, cfsetspeed does not return an error, only tcsetattr does.

This is disappointing. I had really hoped this WWDC would bring the announcement that SwiftData now supported collaboration. I had already filed FB requesting this (FB13801092, not that long ago, alas), but honestly I'm surprised Apple wasn't already working on this. When you introduce new technologies that are meant to replace older ones, you really need to follow up quickly with replacement for all the older functionality.

Two years and you still can't document your own stuff.

As I've thought about my app’s use case a bit more, I'm beginning to think I don't even need a passkey. I’m not 100% sure about this, though. All of this thinking is in the context of my app and server using Apple App Attestation to ensure it’s the only thing making requests. My app needs to interact with its server to provide some background processing for the user that I can't rely on iOS to provide: it needs to wake up at a specified time, do some small network calls to a third party that can take some time to complete (waiting for the other end), and then, depending on the result of those network calls, notify the user. (I had initially coded this using the the available iOS APIs, and found them unreliable. I then used OneSignal to schedule background push notifications that were more reliable, but iOS wouldn't let my app wake long enough to complete the network requests. This, coupled with OneSignal changes, led me to making my own server). By pushing the scheduling and network calls to my server, I didn't have to rely on iOS. But now the server has to differentiate users and store a per-user auth token for the third-party server. That made me think I needed passkeys to safely identify each user. But now I'm thinking perhaps not. During onboarding, my app can request an identifying token from the server (much like the auth token it gets after a successful passkey ceremony). It then sends that on all subsequent requests. Stored in iCloud Keychain, that should allow them to connect their other devices to the same account, right? I think this is secure, in that no unauthorized person should be able to access a given user’s account on my server. There may be a risk that the user loses access to their account state on the server, if they ever lose that auth token. But in this application, the server state is fairly easy to re-create from scratch, I think. Thoughts? • App Attestation ensures all requests come only from my app. • Server generates a user-identifying token, app stores it in iCloud Keychain. • App sends that token with all user-centric requests. At no point does the user have to concern themselves with creating or remembering a user account, or even using passkeys. (I do hate that I’ll be discarding all that lovely passkey work I did, but I’ll need it on another project soon enough).

I have the exact same issue. It seems the address information is stored in more than one place. If I look at my account membership details, it shows the new address. But the banner shown during the compliance flow shows my old addresses under two entities, my LLC and my Personal one. I went through ADP tech support (sent them an email) to see if they could update it. But then I went ahead and proceeded with the compliance steps, and it pre-populated the address form with the correct address, so maybe it will work for you too.

I should clarify: My app will use only passkeys for signin. No username/password. I kinda don’t want usernames to be visible to the user at all, but I suppose they're necessary to allow different users to use the same device. I'm watching the video now, looking for those options. I have some other feedback too: Avoiding Typing Wherever Possible In the example where you want to log into your account on your friend’s PC, the flow requires you to type in your username first. I don't know if that's a WebAuthn requirement, or something that site implemented, but I think a better experience would be for there to be a "Log in as Someone Else" button that presents the QR code without requiring me to type something (it can be very hard to type on some devices). The QR code can identify the relying party, device, and challenge to whatever other device is used for authentication. That latter device can then provide the username and signed challenge to the server (presenting the owner with options for different usernames), which can complete the loop with the PC. Before I learned about passkeys, I built a similar flow for CNC machines that have awful user interfaces. Streamlining Ah, it looks like .preferImmediatelyAvailableCredentials might help me! The only thing I think I might like to have is a "Create Account" button on the OS sign-in form that calls back my delegate so I can lead the user through creating an(other) account.

When I try to just sign in without any credentials, it presents a QR code. That is, when it doesn't report an error that the app site association is bad (seems to alternate with subsequent attempts).

No response at all. I shut this project down a few months ago, but I think the way I solved it was to remove the header from the Bridging header, and keep the code that depended on it as Obj-C.

It's an awful view, and both the FBs I filed have been ignored.

I found a solution. It turns out that SwiftUI is creating its standard suite of menus (which I argue is incorrect for an LSUIElement app). So to my app’s SwiftUI main Window, I add the following modifier: .commands { CommandGroup(replacing: .appTermination) { } } This removes the Quit menu item altogether. It might be better to call NSMenu.removeAllItems() in my app delegate, but from what I read online, SwiftUI will restore the menus, and so you have to observe NSApp.mainMenu for changes. Once again, Apple has offered very narrow use-case solutions in SwiftUI, without more generalized support.