Swift goes further down the stack than you might at first imagine -- there's a lot of Swift written at Apple even in places where you might expect C.
The container CLI tool wraps the underlying Containerization framework, which in turn vends packages for things like EXT4 file system support -- all written in Swift. Here's one example as a jumping off point.
https://github.com/apple/containerization/blob/main/Sources/...
In macOS 26, you can see every Rosetta app that has recently run on your machine by going to System Information and then Software / Rosetta Software. It includes the "Fallback Reason" (e.g. if you manually forced the app under Rosetta or if it was an Intel-only binary).
FWIW, I have zero Rosetta apps on my M1 laptop and I've been a Mac user since the earliest days.
I'm super aware of the issues involved--I oversaw the transition from PPC to Intel at a university back in the day, using OG Rosetta. Even then, we had users who would only stop using their PPC apps when you took them from their cold, dead hands.
Ha! But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null.
You use this construct for unwrapping nullable fields, for example something like this:
guard let httpResult else { return }
Note that you don't need to assign the value to itself in modern Swift. This line takes an optional (httpResult?) and returns early if null. If not, you can use it with strong guarantees that it's not nullable, so no need for ? or ! to unwrap it later in the scope.
> But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null.
It is, when `self` is captured weakly in a closure, and that closure is outliving the instance.
It's worth noting that this doesn't add any expectations for how your UI is built. The example shown in the screenshot continues to use Jetpack Compose (Android's native UI) with Kotlin invoking Swift business logic. You can also use other UI frameworks on Android, of course, including some that are written in Swift.
One nice thing about this implementation is that it shares many of the same characteristics as Swift on other platforms: unlike some common alternatives, it's not garbage collected but uses reference counting; it uses the same underlying libraries, concurrency primitives and memory model.
Excited to see how folk use it... it's technology that will hopefully springboard some other interesting innovations.
[Disclosure: I work on developer tools and frameworks at Apple.]
This seems great, we are looking for a code sharing language between platforms and the options so far are the Usual Suspects:
- TypeScript: we have a few million lines already, but it runs poorly on Android midrange devices.
- Rust: very efficient on Android / iOS but on web there’s very expensive memcopy between WASM memory and JS. Safe but hard to write and refactor casually. Would be great for server perf tho. Async has many footgun for our JS devs. Biggest long term downside: borrow checker speed limit on developer velocity for business logic.
- Kotlin: can target JS directly avoiding bridge cost. iOS devs are uneasy about it. Async story is extremely confusing. Biggest long term downside: how Byzantine the JVM ecosystem is on the server.
Until I saw this Swift wasn’t really in the running. I need to explore the web target situation. Swift is maturing but still weak in ecosystem on non-Apple platform compared to other options. Still swift is moving towards a great combo of speed + safety + usability.
Biggest long term downside: type inference pain. Swift is the only language I’ve used that will tell me “the types seem wrong / ambiguous, but the compiler has no idea what your specific mistake is” and there’s no way to fix it other than trying random code permutations. I hit that one with node-swift yesterday and gave up.
Is there anything in the works for taming the type inference or some way to force-select which overload I want?
This doesn't transpile. It cross-compiles to Android architectures using the NDK. You can see a very simple "hello world" example at the bottom of this article:
Oh thanks, I was reading about Skip and it seemed to be a transpilation tool. The new thing is Swift compiled to a native binary with the NDK and using a JNI bridge to interoperate with Kotlin APIs.
I didn't understand the introduction here, which says both:
> The well-maintained NTFS driver in the Linux kernel enhances interoperability with Windows devices
and
> Currently, ntfs support in Linux was the long-neglected NTFS Classic (read-only), which has been removed from the Linux kernel, leaving the poorly maintained ntfs3.
Is it well-maintained or long-neglected? Or am I misunderstanding this?
I think the author made a typo (or was trying to be sarcastic and missed the sarcasm quotes around "well maintained").
I've used all NTFS drivers extensively in Linux, and whilst ntfs3 is maintained with somewhat regular commits, they are often pretty sparse and haven't addressed some of the long-standing issues (eg Bonnie++ and some other disk benchmark tools fail) - the biggest issue being the lack of a decent fsck tool in the entire ecosystem (ntfsfix in the ntfsprogs pkg isn't a real fsck).
Personally I'd still be wary of doing any fsck from this new project for a good wee while and would recommend using the real CHKDSK from a Windows or a WinPE install instead. Of course, the best option is to avoid using NTFS altogether and use a well-maintained native Linux fs.
Post that stuff with a content warning, would you?
> The base EBCDIC characters and control characters in UTF-EBCDIC are the same single byte codepoint as EBCDIC CCSID 1047 while all other characters are represented by multiple bytes where each byte is not one of the invariant EBCDIC characters. Therefore, legacy applications could simply ignore codepoints that are not recognized.
That says roughly the following when applied to UTF-8:
"The base ASCII characters and control characters in UTF-8 are the same single byte codepoint as ISO-8859-1 while all other characters are represented by multiple bytes where each byte is not one of the invariant ASCII characters. Therefore, legacy applications could simply ignore codepoints that are not recognized."
(I know nothing of EBCDIC, but this seems to mirror UTF-8 design)
OPA solves the problem of defining and enforcing policies across a system. Some examples:
- How do I enforce that inbound API requests come only from trusted sources?
- How do I enforce fine-grained access to user records?
- How do I enforce a set of naming conventions for a data update?
Many such policies may come from regulatory requirements, may be regional in nature, and may change in otherwise stable codebases. And it's even harder when you're applying this to a highly-scalable production internet service. As a result, defining policy at an organizational level with auditing is a challenge for large enterprises. OPA helps enterprises administer and enforce policies.
That's still not saying what it is, though. Is it a thing you put in front of your backend to allow/deny requests? Is it an endpoint something like nginx calls with an auth token and the http verb and url that responds with 200/403 that nginx can react to? Is it a library you embed in your application? Is it an agentic AI?
It's as though you're describing a car to someone who's never seen a car before by listing all the places you can go in a car.
The container CLI tool wraps the underlying Containerization framework, which in turn vends packages for things like EXT4 file system support -- all written in Swift. Here's one example as a jumping off point. https://github.com/apple/containerization/blob/main/Sources/...
reply