Charles Hu:
URL
is one of the most common types used by Foundation for File IO as well as network-related tasks. The goal of this proposal is to improve the ergonomics of URL
by introducing some convenience methods and renaming some verbose/confusing ones. Specifically, we proposed to:
- Introduce a new
StaticString
initializer - Refine the existing “file path” initializers
- Refine
appendingPathComponent
and friends - Introduce common directories as static
URL
properties
[…]
We propose to add all “get URL” style methods from FileManager
to URL
as static methods. This allows the call site to use Swift’s powerful static member lookup to get the URLs to predefined directories instead of always needing to spell out FileManager.default
. We also propose to add a few more static directory URLs that correspond to FileManager.SearchPathDirectory
.
Aside from being verbose, I’ve never liked the FileManager.urls(for:in:)
API because it returns an array that could potentially be empty. So I have to either risk a crash or check for that case and either report an error or substitute my own fallback. The proposed new API simply offers properties (which can’t throw) for the basic directories that I care about.
Karl:
Unfortunately, URL.appendingPathComponent
just forwards to NSURL.appendingPathComponent
, which makes blocking calls to the filesystem. So does URL(fileURLWithPath:)
(here).
But I do agree that a URL type should be a pure model type, and that the results of URL manipulation should never depend on the state of the filesystem.
Thomas Clement:
This has always bothered me as well, because what if the path doesn’t actually exist on disk at this point? Or what if the path isn’t readable from the current process permissions? Or what if the items on disk are later replaced by others (e.g. file could turn into a directory).
Karl:
It sounds weird - like, surely everybody would have noticed already if URLs didn’t conform to Comparable
- but it’s true! It doesn’t conform!
Alejandro Martinez:
It’s probably out of scope for this but my biggest issue with URL is its strict parsing. The amount of times a feature breaks because suddenly we get a url with spaces that URL refuses to parse it’s not small.
Everyone who deals with lots of URLs seems to have their own code to try to “fix up” invalid URLs that they get from user input or other external sources. It probably makes sense for URL
to be strict by default, but it would be nice to have an option for more leniency, e.g. along the lines of what Safari does if you type in something that doesn’t follow RFC 1738.
Previously:
Cocoa iOS Mac Swift Programming Language URL
Cabel Sasser:
Let’s compare the three — three!!! — totally separate ways to save PNG files in Photoshop.
① “Save for Web (Legacy)” is the classic interface we grew up on, and the only one that supports animated gif. (How legacy? They save as “Adobe ImageReady” files, discontinued in 2005 😅)
ImageReady was so good, much faster and easier to use than Photoshop for the types of operations it could handle.
② “Export As…” is the new, “modern” interface for saving files in Photoshop. “Modern” in this case means kind of a weird UI, and missing a lot of options and features. But it’s pretty zippy and doesn’t block your other windows like (Legacy) does.
③ “Save a Copy…” is the wildcard. I think it’s the only way to save a 16-bit PNG in Photoshop. And — oddly — this approach gives you three compression settings that “Export As…” does NOT have!?!?
I love “Save the smallest PNG from over a hundred possibilities!”.
These days when I want to save a PNG or JPEG I use Acorn.
See also: Adobe ImageReady 1.0.
Acorn Adobe ImageReady Adobe Photoshop Mac Mac App macOS 12 Monterey PNG
Josh Centers:
Have you ever looked down at your Apple Watch and thought, “I wish I could browse the Web from my wrist!” OK, probably not. But now you can anyway, thanks to the $0.99 µBrowser from developer Arno Appenzeller, who specializes in fun little utilities like PiPifier and TV Maps.
[…]
Other than the custom font quirk and the tiny screen, the main annoyance is that you must tap through a “Sign In” prompt every time you load a website, even though you’re not signing into anything. Arno explains during µBrowser setup that this is an Apple requirement, and you’re not actually handing over any personal information when you do this. Hopefully, Apple will eliminate this requirement soon.
Apple Watch watchOS watchOS App Web
Juli Clover:
Alongside iOS 15.2, iPadOS 15.2, macOS Monterey 12.1, and watchOS 8.3, Apple yesterday introduced an updated version of Xcode, Xcode 13.2. Developers who are updating should be aware that there’s a bug with the Mac App Store version of the software at this time, and it should be avoided.
[…]
Many developers are seeing the following message: “Internal error: missingPackageDescriptionModule,” and there appears to be no fix at this time.
Jesse Squires:
it is so funny to me that apple can’t even ship their own software to the mac app store without frequent issues
Previously:
Update (2021-12-16): Vatsal Manot:
“It’s making me furious” is my general mood with Xcode 13.x. Whatever the reasons may be, Xcode 13 has been one giant disaster of a release for most of the people I know.
I’m operating on a 20% productivity deficit everyday just because of the source editor regressions.
I’m still seeing the delay before unit tests are run.
Max Rovensky:
I still can’t attach to process in macOS projects unless I’m building for Rosetta
Vatsal Manot:
The Swift debugger in general is so broken for me, I’ve gone back to stone-age print statements everywhere. Every year feels like a step back in IDE usability.
Helge Heß:
Despite getting older, Swift has managed to maintain its original vibe.
Update (2021-12-20): Mr. Macintosh:
“Xcode contains a copy of the log4j library that has the CVE-2021-44228 security vulnerability. Xcode automatically downloads an updated version of this library and installs it into ~/Library/Caches/com.apple.amp.itmstransporter.”
Previously:
Mac Mac App Store macOS 12 Monterey Programming Xcode
Sami Fathi (Hacker News):
New detailed CT scan images of the first-generation AirPods, AirPods Pro, and third-generation AirPods have revealed in detail what internal design changes Apple had to accomplish to include new features in every generation while continuing to miniaturize internal components.
Great photos, but too bad about the scrolljacking and lack of permalink.
Previously:
AirPods History Web