Kevin Perry:
It’s clear from community adoption and feedback that Codable has had a lot of success in the years since it was added to Swift 4, but that it doesn’t satisfy some important needs. One of the foremost of those needs is performance more in line with programming environments that compete with Swift. As such, the main goal for this effort is to unlock higher levels of performance during both serialization and deserialization without sacrificing the ease of use that Codable provides.
[…]
Even with all of its strengths, the existing API’s design has some unavoidable performance penalties. For instance, its use of existentials implies additional runtime and memory costs as existential values are boxed, unboxed, retained, released, and dynamic dispatch is performed.
Also, because a client can decode dictionary values in arbitrary orders, a KeyedDecodingContainer is effectively required to proactively parse the payload into some kind of intermediate representation, necessitating allocations for internal temporary dictionaries, and String values.
[…]
In Swift, when a client needs to do more than just alter the default CodingKey representations, developers are often faced with a large cliff where they’re forced to manually replicate the whole Codable implementation just to do so.
[…]
In this new design I aim to leverage Swift’s macro features to meet or exceed Serde’s level of support for customization of synthesized conformances. Moving code synthesis from the compiler to a macro will enable us to use attribute-like macros as targeted customization mechanisms, which was not something we could easily accomplish with the compiler-based Codable synthesis.
[…]
There is no encode(_: Date) function present in the Encoder interface, which means PropertyListEncoder has to attempt to dynamically cast every some Encodable type it receives to Date in order to handle these natively. This helps keep the Encodable type format-agnostic, but it has a negative impact on performance, even if you never actually encode any Dates.
I believe that fully and formally embracing format-specialization where appropriate is the best solution to this problem. Specifically, we should encourage each serialization format that has native support for data types that aren’t represented in the format-agnostic interface to produce its own protocol variant that includes explicit support for these types, e.g. JSONCodable or PropertyListCodable.
Dave DeLong (Mastodon):
One of the big flaws of Codable is that it was built on the wrong abstraction. 99.9% of the time, developers who are interested in serializing a struct to data and back are doing so to a single, well-known format. However, the Codable API was built so that the abstraction point is the encoder itself, under the assumption that you would want to serialize a type to multiple formats. This is not the case.
That design flaw has been the #1 source of Codable’s woes. It makes properly implementing custom coders almost impossible; no one implements superEncoder properly, since most people don’t deal with inheritance of reference types, and some formats are fundamentally incompatible with the Encoder/Decoder APIs. (XML and CSV are two that spring to mind off the top of my head)
[…]
IMO we should be encouraging packages that provide format-specific coders (JSONCodable, PlistCodable, CSVCodable, XMLCodable, etc) so that each encoder and decoder can provide format-specific functionality. Then we should provide a system level API to ask types to encode into an opaque format (ie “please turn yourself into a Data and back again”).
[…]
Foundation should provide an updated replacement for NSCoding and leave the type-specific encoders to type-specific packages to implement.
Kevin Perry:
JSONCodable, PlistCodable, etc. should have full freedom to craft their interface around each format’s individuals needs and specialities.
At one stage, the “format specialized” protocols was the entirety of the design. However, while looking at adoption scenarios, I realized that this design presented a problem with “currency” types that are owned by frameworks/libraries, but used by application-level serializable types.
[…]
Hence the introduction of the format-agnostic protocols in parallel with the format-specialized ones. Range and CGRect can, in similar fashion to Codable, describe their serializable members abstractly, allowing a specific encoder/decoder to interpret those instructions. The difference from Codable being that we avoid all the OTHER downsides of Codable the OP describes.
Dave DeLong:
That’s why I’m suggesting that we split the API to support the cases separately. We have one API that can be very general and support the whole “A type can be serialized to an opaque format” use-case, and then packages to support particular formats and all of their respective idiosyncrasies. I think we’d be repeating past mistakes to try and make those two use cases be the same API again.
Lincoln Wu:
I think there’s one common use case which is not covered by the current Codable design: heterogeneous/dynamic decoding/encoding.
Many times in my developing, I wanted to decode part of a json into an intermediate representation, and later further decode that thing into a specific type.
Matt Gallagher:
The problem with Codable – and what I think you’re getting at when you suggest we need JSONCodable/PlistCodable – is there’s no sane custom implementation of init(from:) and encode(to:) without being archive-specific. These functions are generally a mashup of two different ideas:
- migration and versioning
- archive-specific choices like which fields to include and what order
But moreover, while you might make archive-specific choices, you don’t always have archive-specific knowledge.
[…]
We have no lookahead. We can’t peek to see if the next char is a double-quote, a digit or a bracket. Without overloading the Decoder to emit lookahead metadata as decodable types, you simply need to try each possibility, in turn, incurring the overhead and disruption of thrown errors.
Kevin Perry:
This design does not include support for encoding and decoding cyclical objects graphs. Relatedly, there’s still no intention to include encoding of runtime type information in serialization formats for any purpose—all concrete types must be specified by the client doing the encoding or decoding.
Nick Lockwood:
I was really disappointed to see this, because these are probably my two major pain points with Codable.
If we are going to the trouble of making a brand new, backwards-incompatible replacement for Codable then it should try to correct all the major deficiencies of the existing design, not just performance.
NSCoding (for all its faults) supports both or heterogeneous data and cyclical references. If this new system doesn’t support those then we are saying from the outset that it is still isn’t going to be capable of dealing with a lot of real-world use-cases.
[…]
Also (related) some kind of built-in support for schema updates and migrations (similar to CoreData/SwiftData) would be a great feature, as this is another pain point in Codable.
Even just a way to specify a default value for new non-optional properties would reduce a lot of the need for adding manual decoder implementations to apps in post-1.0 releases.
Helge Heß:
NSCoder/NSArchiver was actually pretty good for what it was intended for, archiving object graphs. How can I do that today? SwiftData? 🙈
Nick Lockwood:
Another issue I’ve run into with Codable is that a given object may have more than one serialized representation in a given application.
Zev Eisenberg:
I’d like to put in a request to please consider error handling. A common source of grief for beginners is difficulty in reading the error messages thrown by Codable. Some information is missing, and it’s formatted such that you really have to do some digging to understand it.
Helge Heß:
It seems the new macro based approach will solve some major performance problems 👍 But it doesn’t seem to address what makes serialisation actually hard: different formats, mappings, versioning and preservation. It still seems to be bonusware, w/ “now it does the demos fast”, not something addressing actual serialisation issues.
Think Protobuf, that does.
Previously:
Cocoa JSON Language Design Macros Optimization Swift Codable Swift Programming Language
Ryan Christoffel:
Wayne Ma writes today at The Information about the state of Apple TV+ as a business, analyzing where the streamer stands in terms of revenue and subscribers after five years.
In the heavily-paywalled article, Ma reports that Apple’s losses on TV+ amount to over $1 billion per year. While it’s long been known that the streamer was not yet profitable, this is the first time I can recall that we’ve had a solid number to quantify the losses.
The report also claims Apple TV+ had 45 million subscribers last year.
Kontra:
Co-CEO of Netflix and Spotify board member Ted Sarandos on Apple TV+:
“I don’t understand it beyond a marketing play, but they’re really smart people. Maybe they see something we don’t.”
John Gruber (Mastodon):
But is it a loss when Apple expected the business to be unprofitable for a decade or more?
[…]
The insinuation here is that Apple’s pissing this money away and doesn’t know what they’re doing. Maybe they are! But if so it was exactly Eddy Cue and Tim Cook’s strategy to piss this money away. If Apple had expected TV+ to be profitable or break-even in 2024, then a $1 billion operating loss would be a story. But as it stands it’s just a cost.
John Gruber:
One interesting nugget is this chart, which suggests that subscriptions to TV+ have boomed since Apple and Amazon worked out a deal to sell TV+ subscriptions through Amazon Channels in Prime Video at the end of last year. That deal has, seemingly, moved the needle. Another interesting nugget is that TV+ seems to suffer from a higher churn rate than other streaming services. Said Belloni’s Puck colleague Julia Alexander, “Fewer than 35 percent of all subscribers keep the service for longer than six months.”
M.G. Siegler:
I mean, my god could you imagine if Apple had bought Netflix? Who knows if they even would have been allowed to from a regulatory perspective, or if Netflix would have sold, but if it’s true that Cue argued against it simply because he viewed their business as being bolstered by borrowing (financing content spend through debt) that’s a huge strategic blunder. Yes, this was the common criticism of Netflix at the time, though – with the benefit of hindsight – it clearly misunderstood what would happen if and when Netflix reached escape velocity with regard to scale.
[…]
Why would the availability of an Apple TV+ show on a Samsung TV prompt a person to buy Apple hardware? Just halo effect stuff? The argument for making these shows widely available is to sell Apple TV+ subscriptions and spread the cost (and content) far beyond the Apple ecosystem base, not the other way around.
[…]
Apple thought that creating great Apple TV+ shows would lead people to buy Apple TV set top boxes. That didn’t happen. Instead, they just kept their Rokus and stayed happy with Netflix and Prime Video and Disney+ and didn’t think much about Apple TV+.
[…]
Apple just needs to make the content side of the equation actually work, strategically. I don’t care how much it costs, necessarily. It’s more that those costs – in particular those losses not going down over time – actually indicated that they’re strategy was broken.
Previously:
Update (2025-04-01): Benjamin Mayo:
It may be starting from a small base, but TV+ does have upward trajectory. Frankly, on most metrics aside from the bottom line, the Apple TV+ plan is working. Apple is making a lot of good shows that people like, and is garnering millions of subscribers with ever-increasing viewership (given the increasing frequency of appearances of Apple shows on the Nielsen streaming charts). Over time, I see Apple TV+ as a big asset of the Apple One bundle.
[…]
Alongside reducing churn, the ongoing brand prestige and self-aggrandising awards recognition is also an added bonus for the company. If it really has accrued 45 million subscribers to date with a catalog of just ~280 originals, it doesn’t seem too far-fetched that they could eventually break even on the effort.
John Gruber:
The Studio is, thus far, engaging, surprising, funny, gorgeous, clever, and cinematically ambitious. It’s really quite a thing. I have no idea what’s coming in episodes 3–10, so maybe this piece will look a bit premature, if not foolish, in two months. But if the rest of season one is anything like the first two episodes, The Studio is a classic in the making.
The thought also occurs to me that this might be the don’t-over-think-it answer to just what the hell Apple is doing making original shows and movies in the first place. Perhaps Apple’s leadership simply believes, as I do, that cinema is the grandest and greatest form of art the world has ever seen — one that encompasses acting, writing, photography and/or illustration, and music — and but that great cinema is expensive and delicate and needs, from deep-pocketed studios and their deeper-pocketed corporate parents, more than patrons, but champions. And that in a media landscape where such champions of cinema-as-art and art-as-an-essential-public-good are fewer and fewer, it is Apple’s not just opportunity but obligation to step up to the plate.
It’s a pity that they don’t see it as their obligation to champion the art of software, e.g. by ensuring that individuals can build and distribute their creations without interference.
Apple Apple TV Apple TV+ Business Eddy Cue Netflix
Nathan Edwards (2023, via Nick Heer):
It was fine until my yellow ink cartridge (allegedly) ran out, and the printer stopped printing in color. I soldiered on with the black cartridge. Until one day I tried to print a return label (in black and white!) and the printer decided it wouldn’t. Not until I replaced the yellow ink cartridge. Fine. I paid 207 goddamn dollars for replacement cartridges, put them in, and discovered that HP region-locks its printers.
[…]
The genuine HP ink cartridges, for which I paid as much as I paid for the actual printer, would not work with the printer they were designed to work with because I bought it in a different part of the world. It wasn’t even a cheaper part of the world unless we’re talking healthcare or midcentury furniture.
[…]
Now, I realize this is an edge case. Most people don’t move across the world and bring a printer with them. But region-locking is only one of many ways printer companies use DRM to squeeze money out of their customers, and if you have an inkjet printer you might have already run into one of them.
Charlotte Gifford (2023, via Hacker News):
Hewlett-Packard, or HP, has sparked fury after issuing a recent “firmware” update which blocks customers from using cheaper, non-HP ink cartridges in its printers.
[…]
The printer company said it issued the update to reduce the risk of malware attacks, saying “third-party cartridges that use non-HP chips or circuitry can pose risks to the hardware performance, print quality, and security.”
Scharon Harding (Hacker News):
In a new form of frustration, HP is now being accused of issuing a firmware update that broke customers’ laser printers—even though the devices are loaded with HP-brand toner.
The firmware update in question is version 20250209, which HP issued on March 4 for its LaserJet MFP M232-M237 models. Per HP, the update includes “security updates,” a “regulatory requirement update,” “general improvements and bug fixes,” and fixes for IPP Everywhere. Looking back to older updates’ fixes and changes, which the new update includes, doesn’t reveal anything out of the ordinary. The older updates mention things like “fixed print quality to ensure borders are not cropped for certain document types,” and “improved firmware update and cartridge rejection experiences.” But there’s no mention of changes to how the printers use or read toner.
However, users have been reporting sudden problems using HP-brand toner in their M232–M237 series printers since their devices updated to 20250209. Users on HP’s support forum say they see Error Code 11 and the hardware’s toner light flashing when trying to print. Some said they’ve cleaned the contacts and reinstalled their toner but still can’t print.
Scharon Harding (Hacker News):
In December 2020, Mobile Emergency Housing Corp. and a company called Performance Automotive & Tire Center filed a class-action complaint against HP [PDF], alleging that the company “wrongfully compels users of its printers to buy and use only HP ink and toner supplies by transmitting firmware updates without authorization to HP printers over the Internet that lock out its competitors’ ink and toner supply cartridges.” The complaint centered on a firmware update issued in November 2020; it sought a court ruling that HP’s actions broke the law, an injunction against the firmware updates, and monetary and punitive damages.
[…]
After years of litigation, in August 2024, HP and the plaintiffs reached a settlement agreement that Judge Susan Van Keulen approved on Tuesday [PDF].
Under the settlement agreement, HP doesn’t admit to any wrongdoing. It also won’t pay any monetary relief to customers impacted by the November 2020 firmware update.
Previously:
DRM HP iOS Lawsuit Legal Mac Printing
Wikipedia:
Michael Sweet, who owned Easy Software Products, started developing CUPS in 1997 and the first public betas appeared in 1999. The original design of CUPS used the Line Printer Daemon protocol (LPD), but due to limitations in LPD and vendor incompatibilities, the Internet Printing Protocol (IPP) was chosen instead. CUPS was initially called “The Common UNIX Printing System”. This name was shortened to just “CUPS” beginning with CUPS 1.4 due to legal concerns with the UNIX trademark. CUPS was quickly adopted as the default printing system for most Linux distributions. In March 2002, Apple Inc. adopted CUPS as the printing system for Mac OS X 10.2. In February 2007, Apple Inc. hired chief developer Michael Sweet and purchased the CUPS source code.
Tim Anderson (2020):
The official public repository for CUPS, an Apple open-source project widely used for printing on Linux, is all-but dormant since the lead developer left Apple at the end of 2019.
[…]
Asked at the time about the future of CUPS, he said: “CUPS is still owned and maintained by Apple. There are two other engineers still in the printing team that are responsible for CUPS development, and it will continue to have new bug fix releases (at least) for the foreseeable future.”
[…]
Till Kamppeter, leader of the Linux Foundation’s OpenPrinting effort and organizer of the printing micro-conference at Linux Plumbers, commented on Larabel’s observations, pointing to this post where he says: “Due to dormant upstream development, we have discussed to creating a temporary fork on OpenPrinting [of CUPS] for bug fixes and distribution patches, and Michael Sweet has done it now.”
The “dormant” bit refers to Apple’s CUPS project; and OpenPrinting’s CUPS fork is here. Kamppeter added that “in case that Apple does finally cease CUPS development, I will continue the project together with Michael Sweet on OpenPrinting. CUPS will still be needed in Linux.”
LinuxReviews (Slashdot, Hacker News):
Apple’s CUPS git repository at Microsoft GitHub become a ghost-town after Mr Sweet’s departure. There is a single commit bumping the version and fixing minor issues in 2020 and that’s it, that’s all that happened in the CUPS git repository this year. That’s a stark contrast to the activity there previous years[…]
It looks like nothing has happened with Apple’s code since a security fix in 2022, and the repo comment makes it sound like Apple is intentionally leaving its support stuck at an old version:
Apple CUPS is the version of CUPS that is shipped with macOS and iOS. For the current version of CUPS that is used on other operating systems, see https://openprinting.github.io/cups for details.
Previously:
iOS iOS 18 Linux Mac macOS 10.15 Catalina macOS 15 Sequoia Open Source Printing Unix
