\n<\/p>\n
There has been plenty of criticism of Liquid Glass, both during the beta and since its official release. One article I read this week was Raluca Budiu<\/a>\u2019s critique of both Liquid Glass as a design language and the general lack of attention to detail in the macOS 26 UI. The biggest legibility issue, in my opinion, especially on iOS, is when text overlays on top of other text:<\/p>\n Apparently, designers decided users have eagle vision and infinite patience, because deciphering one line of text written across another is now fair game. Reading an email subject line now requires Dan Brown-level cryptographic decoder skills.<\/p>\n<\/blockquote>\n It\u2019s usually easy enough to make text or controls on top of content legible if you scroll by a few pixels, but that\u2019s not really the point. There\u2019s no question<\/em> that Liquid Glass is a step back for legibility.<\/p>\n It\u2019s also not just about legibility and Liquid Glass. There\u2019s a significant amount of criticism of other aspects of the operating systems, from John Ozbay<\/a> wondering what happened to Apple\u2019s legendary attention to detail?<\/a> to Adam Engst<\/a> questioning whether prioritising content over tools is the correct decision<\/a>.<\/p>\n Michael Tsai<\/a>, as always, has put together a great round-up of Liquid Glass comments from social media<\/a>. It\u2019s not entirely negative, but it\u2019s certainly leaning in that direction.<\/p>\n The last time we talked this much about an operating system design was iOS 7, which Louie Mantia<\/a> refers back to in his commentary on Liquid Glass from the early betas<\/a>, and that turned out fine in the end, even if it did take a few years of iteration to properly settle down.<\/p>\n There are ways to turn at least the Liquid Glass portion of the design system off<\/a>, although Adam, who wrote that article, doesn\u2019t recommend it:<\/p>\n I can\u2019t recommend turning off Liquid Glass entirely in this way. Although it does make macOS 26 look more like macOS 15, it suffers from several glaring mistakes that Apple has no incentive to fix. Stick to Reduce Transparency and add Increase Contrast if your eyes would appreciate it.<\/p>\n<\/blockquote>\n Maybe the most interesting thing about Liquid Glass is the conversations and critique that it has sparked. No matter how you feel about it personally, we\u2019re once again debating what \u201cgood design\u201d on Apple platforms means, and that\u2019s always a worthwhile subject for discussion. I\u2019m quite sure the design and human interface teams in Cupertino are watching closely, too.<\/p>\n \u2013 Dave Verwer<\/p>\n Add Barcode and Document Scanning with One Line of Code<\/a><\/p>\n Let users scan barcodes and documents effortlessly, and generate crisp PDFs with the Genius Scan SDK. Enjoy local processing for performance and privacy: real-time detection, perspective correction, image enhancement, OCR, and data extraction\u2014no more blurry documents! Try it today<\/a>.<\/p>\n Build, run, debug, and test your Swift apps in Zed<\/a><\/p>\n Adrian Ross<\/a>:<\/p>\n This isn\u2019t just an article about what you could do in theory<\/em> \u2013 I built my new app, DelayDrop, mainly in Zed. It\u2019s a pleasure to work in a genuinely good code editor, and switching into Xcode for things like previews really isn\u2019t an imposition.<\/p>\n<\/blockquote>\n I really like Zed<\/a>, and it\u2019s replaced VS Code for any front-end CSS or JavaScript work I do, as well as for editing things like JSON, YAML, and XML. If you\u2019re interested in using it for Swift work, Adrian has written up two articles: Build, run, and debug iOS and Mac apps in Zed instead of Xcode<\/a> and Now you can test Xcode apps and Swift packages in Zed<\/a>.<\/p>\n Advanced Codable<\/a><\/p>\n There\u2019s a nice set of A Who\u2019d have thought so many words could be written about encoding and decoding data? Not just in Alan\u2019s post, but in general. \ud83d\ude2c<\/p>\n Foundation Models profiling with Xcode Instruments<\/a><\/p>\n Artem Novichkov<\/a> runs through how Instruments can help you profile the speed of the requests you\u2019re passing through to Apple\u2019s foundation model. It can be slow, and it\u2019s worth finding out if it\u2019s purely<\/em> the request, or if it\u2019s the code you wrap around it.<\/p>\n When does SwiftUI automatically apply the glass look?<\/a><\/p>\n Talking of glass, Natascha Fadeeva<\/a> explains when SwiftUI\u2019s new glass button style (introduced in iOS 18) is automatically applied to toolbar items in system placements versus when manual styling is required to get the glass effect.<\/p>\n Caveat Emptor<\/a><\/p>\n Sam Deane<\/a>:<\/p>\n I\u2019ve encountered a few people who subscribe to a fundamentalist view of open source code: that it\u2019s useless unless it is fully polished, fully tested, 100% supported.<\/p>\n I understand this point of view; we\u2019ve all encountered code that makes great claims and turns out to be broken or mostly unfinished.<\/p>\n Respectfully though, those people are wrong.<\/p>\n<\/blockquote>\n I couldn\u2019t agree more! Don\u2019t be embarrassed to release anything, and you don\u2019t need to support it any more than you want to. You owe people nothing when you select \u201cPublic\u201d for your repository permissions.<\/p>\n\n
\n
\n
Code<\/h2>\n
Codable<\/code> tips and tricks in Alan Kantz-Durand<\/a>\u2019s latest post. I especially liked the idea of a Maybe<\/code>:<\/p>\n\n
Maybe<\/code> type is an enum that can represent either a value or an error. You can think of it as an Optional with context, or as a more-restrictive Result.<\/p>\n<\/blockquote>\n\n
Jobs<\/h2>\n