Alexander Grebenyuk:
I wrote a post yesterday about triple-column navigation in SwiftUI. It felt a bit awkward posting it because this really shouldn’t be some obscure knowledge. This is hardly a challenging problem. But to me and to many other people, this was challenging.
Why was it challenging? The NavigationView documentation page doesn’t mention a triple-column layout or macOS at all. But the lack of content is not the only problem with Apple Documentation.
The intention of the article isn’t to complain, but rather to review the documentation system and point out some of its issues.
Alexander Grebenyuk:
This is a native macOS app written entirely in SwiftUI, from @main to bottom. Not a prototype, not a toy. A full-featured app. The intention is to deliver the best macOS experience possible.
[…]
The relationship between SwiftUI and AppKit are not documented and not guaranteed to be supported. This workaround is useful for now, but might stop working in the future.
[…]
I had to compromise in a few places. But I don’t have a lot of bugs to report. Maybe I’m just getting better at avoiding things that don’t quite work as expected. There are some limitations, but the AppKit integration is always there for me.
Wil Shipley:
SwiftUI is an amazing way to prototype interfaces quickly but when you hit a wall you hit it hard and there’s almost nothing you can do.
It’s also telling to me that, for instance, nobody seems to have figured out how to make two Buttons in SwiftUI be the same width.
(Yes, I’ve seen various posts about it, but so far haven’t found a solution that works in all cases.)
Previously:
Update (2021-03-14): Alexander Grebenyuk:
I solved all these performance issues with one simple trick – rewriting the list using NSTableView.
[…]
Unlike iOS, macOS needs to know the size of every cell. It allows precise control using a scroll indicator. It appears that List attempts to implement self-sizing on top of NSTableView, but it’s destined to fail on macOS.
[…]
There is always a risk with SwiftUI. It is an exceptional tool, but you never know when you are going to hit a wall. My pure SwiftUI app uses NSTextView, NSSearchField, and now NSTableView and NSMenu.
Update (2021-03-19): Steve Streza:
SwiftUI is two things. It is 1) a declarative, reactive UI paradigm similar to React or Jetpack Compose, and 2) a new set of controls and views that mimic AppKit/UIKit.
1 is brilliant. 2 is absurdly frustrating at every turn, and feels like hacking non-native UI.
Update (2021-04-07): Alexander Grebenyuk:
Some basic things that are unproblematically done with Auto Layout are hard in SwiftUI, for example, matching views size or aligning views. SwiftUI layout system is simply less expressive. The good things about it (stacks, grids, spacers) are easy to add to Auto Layout. And I still can’t build a complete mental model around the SwiftUI layout system. Auto Layout, on the other hand, makes total sense – it’s just math.
Dave Wood:
#SwiftUI is a disaster. I know of a team about to ship a production app built 100% with SwiftUI and it’s a UI shit show. Basic things that have worked fine since iPhone 2.0 just don’t work correctly with SwiftUI.
Update (2021-04-14): Ken Case:
Some things we wanted to do were easier than ever. Some things were much harder than one would hope. (E.g., SwiftUI will happily reclaim views which are scrolled offscreen, which can play havoc when one of those views is the first responder.) Creative experimentation required.
Update (2021-04-15): Marcin Krzyzanowski:
For the past 2 days, I’ve been dealing with a SwiftUI issue where NSViewRepresentable does something different than SwiftUI views and the hierarchy does not update properly. The same hierarchy and if I just replace component with SwiftUI.Button - everything starts working.
Now I need to reimplement native NSSegmentedControl purely in SwiftUI views to make it work, and still, it won’t look as good as the native component (SegmentedPickerStyle is not enough for my needs)
SwiftUI is faster until it’s not.
Update (2021-06-07): Peter Steinberger:
Sometimes SwiftUI is just so random. Compare the two images. The context menu does work in one and doesn’t work on the other. Can you tell which one is the right one?
Documentation Mac macOS 11.0 Big Sur Programming Swift Programming Language SwiftUI
Jimmy Jenkins (via Hacker News):
According to Arizona Department of Corrections whistleblowers, hundreds of incarcerated people who should be eligible for release are being held in prison because the inmate management software cannot interpret current sentencing laws.
[…]
According to the sources, the entire inmate management software program, known as ACIS, has experienced more than 14,000 bugs since it was implemented in November of 2019.
The article calls this one of the bugs, but it sounds like the state changed the requirements without appropriating any funds to update the software. The estimated “2,000 additional programming hours” seems rather small given the scope of the program:
The ACIS software system replaced an older program called AIMS that had been in operation for more than three decades. According to a 2019 presentation to the Joint Legislative Budget Committee, the Department of Corrections has spent more than $24 million replacing the inmate management system. A department spokesperson testified that requirements for the project were poorly scoped from the beginning, resulting in a contract that went millions of dollars over budget.
frompdx:
Software is simultaneously infallible and the perfect scapegoat. The inmate who lost their phone privileges for 30 days is an example. They did nothing wrong but the computer says so and nothing can be done. The computer is right in the sense that its decision cannot be undone, and solely to blame since no human can undo its edict or be held accountable, apparently.
Previously:
Will Oremus:
When you join the fast-growing, invite-only social media app Clubhouse — lucky you! — one of the first things the app will ask you to do is grant it access to your iPhone’s contacts. A finger icon points to the “OK” button, which is also in a bolder font and more enticing than the adjacent “Don’t Allow” option. You don’t have to do it, but if you don’t, you lose the ability to invite anyone else to Clubhouse.
Via Nick Heer:
The permission dialog iOS presents users before an app is able to access their contacts is, in a sense, being presented to the wrong person: can you really consent on behalf of hundreds of friends, family members, and acquaintances? From a purely ethical perspective, the request ought to be pushed to every contact in the directory for approval, but that would obviously be a nightmare for everyone.
There are clearly legitimate uses for doing this. Allowing people to find contacts already using a service, as Clubhouse is doing, is a reasonable feature. It does not seem like something that can be done on-device, so the best solution that we have is, apparently, to grant apps permission to collect every contact on our phones. But that is a ludicrous tradeoff.
Guilherme Rambo:
Just had a poke at the Clubhouse app with a proxy, given the recent concerns about contacts usage. The bad part is that it uploads all of your contact’s phone numbers (surprise!). The good part is that that’s the ‘only’ thing it uploads about them.
[…]
Another problem is that the API used to upload the phone numbers doesn’t seem to be using SSL pinning.
Dave Verwer:
I saw some suggestions that Apple should solve this with a Photos.app style “select which contacts can be accessed” permission, but is anyone going to go through their contacts manually, picking and choosing? I have just under a thousand records in mine from many years of personal+work life, and I bet that’s nothing compared to some people. It’s not practical. Maybe a solution would be to let the permission be on groups rather than individual contacts, but who’s contact database is that well organised? Mine isn’t.
The other popular theory on how to solve this is that Apple should provide an API to hash contact information, allowing apps to match people without getting access to personal information. That’s one of those ideas that feels better and solves one aspect of the problem, but bad situations are inevitable when you match a full contacts database.
Previously:
Update (2021-03-15): Jane Manchun Wong:
Clubhouse no longer requires contacts access for sending invites in the latest update!
You can now directly enter the number, or use the iOS contact picker (which doesn’t require contacts access) to send invite
Clubhouse Contacts iOS iOS 14 iOS App Privacy
Hartley Charlton (Hacker News):
Across Twitter and the MacRumors forums, users are reporting that M1 Macs are experiencing extremely high drive writes over a short space of time. In what appear to be the most severe cases, M1 Macs are said to be consuming as much as 10 to 13 percent of the maximum warrantable total bytes written (TBW) value of its SSD.
[…]
It is not known how widespread the TBW issue is, but reports of strange SSD behavior are also now emerging from users with Intel-based Macs, suggesting that the TBW issue may not be exclusive to M1 Macs.
Dan Moren:
I ran the command-line tests on my own M1 MacBook Air versus my 2017 iMac, and it certainly did seem as though some of the numbers on the Air were higher than they should be, given the amount of relative use.
The numbers for older Macs reported on Accidental Tech Podcast also seem higher than I would have expected.
Update (2021-03-11): Ben Lovejoy (tweet):
Second, he says than SSD vendors have to be very conservative in their wear ratings, as it leaves them on the hook for warranty claims if a drive fails before reaching its rated wear limit. In practice, SSDs can commonly cope with four times as much wear.
Regardless, I think we need to figure out why macOS is writing (or reporting that it’s writing) so much more data than intuitively seems reasonable. And this is not an issue limited to M1 Macs.
Update (2021-05-25): Hector Martin:
Update on the macOS SSD thrashing issue: It seems the issue is fixed in 11.4. Feel free to try the betas if you’re adventurous, or wait for the final release.
It’s going to be interesting diffing the XNU kernel source once it drops and seeing what the bug was…
Previously:
Apple M1 Mac macOS 11.0 Big Sur Solid-State Drive (SSD) Storage
