When I try it, I get "'module' is inaccessible due to 'internal' protection level". I do see that it's being generated for one of my project's dependencies (in this case, it's a Vapor project, and the module that code completion jumps to is in in swift-crypto’s DerivedSources folder). UPDATE: Seems I had a malformed Package.swift (a missing comma), and instead of showing the error, Xcode just choked on compiling my test code. Running swift-test on the command line revealed this.

Where is Bundle.module defined?

After a lot of tinkering, I came upon a solution. Not sure if all of this is necessary: Only initialize the full stack if not in a SwiftUI preview. This was *****, relying on a runtime environment variable. Create a simple NSPersistentContainer when using in-memory store for previews and unit tests Only call setQueryGenerationFrom(.current) for the "real" stack, not the preview stack. This last one was key.

Thank you. It sounds like the best approach is to start with a standard/traditional Core Data stack and "migrate" to Swift Data from there.

Oh thank you, @DTS Engineer, that's helpful. Yes, I meant UICloudSharingController. I had completely failed to remember ShareLink, not realizing it works for this case. Ideally, I'd be able to use SwiftData for the bulk of my local objects, but afaik there’s no direct support for CKShare in SwiftData. Can you tell me if I have to create the Core Data stack from scratch, or can I insert the necessary bits (e.g. all the descriptions and options for shared zones, etc.) into the stack created by the Swift Data APIs?

Are you saying I have to create a file on disk in order to print?

I still get this in Xcode 16b5 on macOS in my SwiftData/SwiftUI app. I don't explicitly use NSKeyedArchiver anywhere, nor do I have any transformations on my model objects.

I did eventually get this to work. I needed to skip the two-byte header after all. Not sure why it didn't work the previous times I tried doing that.

I might not have been clear. As I understand it, the Share Extension is for making my app a recipient of shares from another app. In my case, I want to mimic what Ivory is doing, not be shared to from Ivory. I want to add a handful of "Copy…" commands that do slightly different things. In fact, what I should probably do is have one "Copy" command and an "Options" menu like Mobile Safari offers, where you can choose to "Send As" different formats. Is all that also provided by the Share Extension?

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.