Ashley Belanger (via Slashdot):
Amazon rigged its platform to “routinely” push an overwhelming majority of customers to pay more for items that could’ve been purchased at lower costs with equal or faster delivery times, a class-action lawsuit has alleged.
The lawsuit claims that a biased algorithm drives Amazon’s “Buy Box,” which appears on an item’s page and prompts shoppers to “Buy Now” or “Add to Cart.” According to customers suing, nearly 98 percent of Amazon sales are of items featured in the Buy Box, because customers allegedly “reasonably” believe that featured items offer the best deal on the platform.
[…]
Authorities in the US and the European Union have investigated Amazon’s allegedly anticompetitive Buy Box algorithm, confirming that it’s “favored FBA sellers since at least 2016,” the complaint said. In 2021, Amazon was fined more than $1 billion by the Italian Competition Authority over these unfair practices, and in 2022, the European Commission ordered Amazon to “apply equal treatment to all sellers when deciding what to feature in the Buy Box.”
These investigations served as the first public notice that Amazon’s Buy Box couldn’t be trusted, customers suing said. Amazon claimed that the algorithm was fixed in 2020, but so far, Amazon does not appear to have addressed all concerns over its Buy Box algorithm. As of 2023, European regulators have continued pushing Amazon “to take further action to remedy its Buy Box bias in their respective jurisdictions,” the customers’ complaint said.
See also: Nick Heer.
Previously:
Amazon Dark Patterns Italy Lawsuit Legal Shopping Web
Christian Tietze (Mastodon):
On Mastodon, we had a discussion about whether you are more or less productive with SwiftUI or UIKit/AppKit. Der Teilweise (@teilweise@layer8.space) chimed in with an actual, measurable benchmark: a flexible-width window, with reflowing text, and equal-size buttons. Doable in 10 minutes. Can SwiftUI beat this?
[…]
Here’s the reference implementation on GitHub.
[…]
- Richard Kolasa got pretty far in 6mins, but the default SwiftUI window has too much free movement :)
- Mike Apurin points out that window resizing is hell (Code).
- Ryan Lintott shared a solution that reflows the text and increases window height properly (Code). Uses his FrameUp library to help with the layout.
Mike Apurin:
Debating whether SwiftUI is “production-ready” in 2024 is an eye-roll argument, though. It has, limitations, sure, but what doesn’t?
“Production-ready” is probably not the right question. It is clearly being used in production. But you could look at how easy it is to make standard Mac layouts that were straightforward with the old system. In this particular example, it seems like sort of the anti-Perl: easy things made hard but possible. If you look at the SwiftUI layouts in Apple’s apps, they generally don’t sweat these details. SwiftUI started on watchOS, which doesn’t really have resizable windows and where buttons are usually full width and stacked vertically. On the other hand, there are certain types of layouts and data flow that are easier in SwiftUI.
Mike Apurin:
Sadly, the way windowResizability works makes it impossible to implement this without a GeometryReader or a Layout, and even then it’s a bit janky. SwiftUI needs something like the compression resistance priority here.
Der Teilweise:
Today I’d say SwiftUI has its pros and cons. I still doubt that it is better than UIKit/AppKit. It’s (just) different.
I like the good things about Autolayout more than I like the good things in SwiftUI. And I hate the bad things in SwiftUI passionately while I have made peace with the bad things in UIKit.
(We all thought Autolayout errors were the worst possible …)
Isaiah Carew:
there is, of course, no way to build a UI that changes with content using springs and struts. it’s all top-down constraints.
that said, here’s my quick UI:
- keeps the buttons the same size.
- maintains correct spacing.
- margins don’t scale, just buttons.
there’s not much to it, so it went pretty fast.
Steve Troughton-Smith:
I added an AppKit target to the @broadcastsapp codebase just to experiment, and of 245 source files only 11 are portable All the pre-existing SwiftUI code is uncompilable, because even basic things like size classes don’t have a macOS equivalent or translation. I continue to believe that the AppKit SwiftUI target is simply a dead end and needs to be rolled into the Universal app platform instead. I don’t want to continue with this bringup experiment at all.
Jaanus Kase:
Another thing that “should be easy in macOS SwiftUI but isn’t”:
Reopening a window after closing it, with the correct position, size and split view pane sizes.
It works correctly if I quit the app and restart. Window is restored with previous metrics (automatically stored in UserDefaults).
It does not work correctly if I close the window and click on the Dock icon which opens a new window. I expect the new window to have same metrics as the one I just closed, but nope.
Khoa:
This same code runs fine on Mac but causes severe hangs on iOS
Marcin Krzyzanowski:
Not me implemented 90% of functionality with the new SwiftUI API, only to learn the missing 10% is impossible because it’s missing configuration, and now rewriting it to something else.
it’s just annoying that SwiftUI API is so very closed. one can rarely add missing piece without reimplementing a thing from the ground. That aspect is very much the opposite of UIKit etc.
I would say it’s “make easy things easy, and hard things impossible” philosophy
John Siracusa:
My SwiftUI view and its containing NSHostingView/NSWindow are not getting along, and I think it’s an Apple bug.
Marco Arment:
Seems like everyone here is stumped, just like I was.
Does SwiftUI REALLY not support basic table-cell animation after four years? I assume it’s me, not the framework…
Tanmay:
SwiftUI is terrible when it comes to reliability for building any custom interactive component. Random things just break in the next release. If you want to build fluid, interactive designs for iOS that are rock stable, stick with UIKit.
Mario Guzmán:
Still experimenting with SwiftUI for Macintosh layouts because some of the toolbar item placement options and controls just don’t have the flexibility they do in AppKit.
Luc Vandal:
Keyboard shortcuts for toolbar items not showing when holding the ⌘ key on iPad: am I doing something wrong or is it just another “not yet supported in SwiftUI” thing?
So of course the solution was obvious (sarcasm)! Adding .labelStyle(.titleAndIcon) to the Label is the way to go. So many SwiftUI dark patterns…
Jordan Morgan:
In my previous snip, I used a cheeky Threads knockoff interface to demonstrate the subject matter. It occurred to me how crazy it is that I can even do this. SwiftUI has done away with so much work that used to be pervasive in interface programming, interface builder or not.
Christian Beer:
SwiftUI is awesome for starters… just until you get some strange error on a ForEach: “Cannot convert value of type ‚[XYZ]‘ to expected argument type ‘Range<Int>’” that worked perfectly until you wrote the wrong action code in a Button somewhere.
Krzysztof Zabłocki:
So many weird bugs in SwitUI, e.g. adding contextMenu steals all touches from the underlying view instead of just around that view, thus making overlay components break underlying UI interactions…
Oskar Groth:
No macOS SwiftUI component has let me down as much as List. Just when you think you’ve got it working well, there is always some tiny issue relating to reorder, DisclosureGroup expansion, highlight or layout.
Matt Massicotte:
I’ve been doing some experimentation with SwiftUI on macOS 14. Things are working amazingly well. I have yet to find anything weird, broken, or nonfunctional. Interop with AppKit world is excellent.
Craig Hockenberry:
Here’s a surprisingly hard thing to implement in SwiftUI: a panel that contains a resizable image that looks right on both iOS and tvOS..
Collin Donnell:
Things are easier in SwiftUI, except debugging, debugging sucks.
John C. Welch:
I’ll be adding to this post as I go along as a way of documenting some of the “fun” bits of SwiftUI[…]
Clarko:
Really frustrating to spend the day reworking on macOS UI, getting it really responsive and snappy, and then the exact same SwiftUI code on iOS and iPadOS runs like sludge.
Steffan Andrews (Reddit):
Apple completely removed the ability to open the SwiftUI Settings scene using legacy NSApp.sendAction() method using the showSettingsWindow: (macOS 13) or showPreferencesWindow: (macOS 12 and earlier) selectors. The only available method of opening the Settings scene (apart from the App menu → Settings menu item) is to use the new SettingsLink view.
This presents two major restrictions:
- There is no way to detect when the user has clicked this button if additional code is desired to run before or after the opening of the
Settings scene. - There is no way to programmatically open the
Settings scene.
BenedictC:
I blame the annual cycle in part for the fundamental problems in Swift and SwiftUI. There’s a proposal to add a feature for property specific inits (a bonkers idea). It exists to patch a problem with macros, which fixed a problem with property wrappers, which were added to allow SwiftUI to subvert value type semantics. I believe if Apple had spent more time dog fooding SwiftUI it would be very different. No amount of pausing to fix bugs will allow Apple to fix the fundamentals.
Christian Beer:
I still can’t get over the fact that in SwiftUI you can’t create a Table with a dynamic set of columns. And I don’t mean reordering or resizing. I mean: you can‘t use if or ForEach when creating table columns. ☹️
Christian Beer:
We’re in year 4 of SwiftUI and building a good multiplatform document based app is still hard to impossible.
Building a VERY simple document based app, with DocumentGroup and TextEditor, like the sample is easy. But doing more than that is hard: DocumentGroup with NavigationSplitView? Forget it. Customizing document creation? Forget it…
Christian Tietze:
Today is the day on which I realize:
I like working in SwiftUI more than I like building programmatic interfaces in AppKit.
It’s not even close. I’m really annoyed by all the wiring[…]
Dandy Griffin:
This chain speaks to me so much! I’m in the process of reducing SwiftUI usage in my only macOS app because it just seems to fall apart. I find AppKit tedious, but reliable, and there’s ~always~ a solution. Even hacky solutions in AppKit/UIKit never feel as fragile or hacky as SwiftUI hacks.
Sam Rowlands (tweet):
SwiftUI has really helped make Mac development more exciting (for me), and further cements how far outa the race Xojo is. At this point, I don’t think there is anything Xojo can do to catch up, but I believe they know that already.
Sure it’s not without it’s downfalls, adapting some of the work flows to the SwiftUI way, can be a massive paradigm shift, and sometimes feels like hacky spaghetti code. Alerts for instance feel unnatural, but I can see why they’ve done them this way.
Marco Arment:
Sometimes, I wonder if I’ve made a huge mistake by tackling a giant rewrite of my 10-year-old ObjC/UIKit app in Swift/SwiftUI that’ll probably end up costing me ~1.5 years of development time.
Then I try to do ANYTHING with ANY new API in the old codebase from Objective-C and UIKit.
It quickly becomes apparent that this rewrite was not much of a choice — it’s a necessity.
Sam Rowlands:
SwiftUI Mac, changing focus from one TextField to another marks the document as “Edited”, even when the text wasn’t changed in either TextField.
Christian Beer:
We achieved a lot more stable code with Swift (in comparison to Objective-C; I know it’s discussable)… but we lost so much with SwiftUI!
SwiftUI/EnvironmentObject.swift:90: Fatal error: No ObservableObject of type BottomBarViewModel found. A View.environmentObject(_:) for BottomBarViewModel may be missing as an ancestor of this view.
Christian Beer:
Theoretically SwiftUI previews in Xcode are a good idea. But if it takes A LOT longer to just view this preview than to start the app and navigate to that view, or even “Failed to launch app “XCPreviewAgent.app” in reasonable time“… it’s just not helpful.
Der Teilweise:
One of the things I hate about SwiftUI is the crappy visual editor. It’s light years behind what we had for Storyboards. It’s not even as good as the original Interface Builder was.
Even in Visual Studio (201x!) editing of Windows Forms is way better. And that, too, parses code to build the UI! Change a line of code in the *.Designer.cs, switch the view: Boom, there’s you UI.
Marcin Krzyzanowski:
I didn’t expect that, but SwiftUI.TextEditor lagging on edit for relatively short text. I can feel it lag while I’m typing letters.
Sam Rowlands:
I came to the conclusion that SwiftUI.textEditor refreshes the entire content each time, I think the same happens for TextField also. Wrapped NSControls don’t suffer from the same problems.
Marcel Weiher:
Well, refreshing everything each time is kind of the underlying model.
See also: Accidental Tech Podcast.
Previously:
Update (2024-03-14): See also: If Not Nil.
Update (2024-04-08): Howard Oakley:
Another fundamental problem I’ve run into is the app life cycle. Many Mac apps start with a brief initialisation phase, during which they might check required resources, look online for app updates, and load app-wide preferences and menus. Once those are complete or under way, the app turns to the task of opening documents and their windows, perhaps. Then, when the user quits the app, there’s a completion phase in which any last changes to settings are made, and the app gracefully exits. When using AppKit, these are normally accomplished in an AppDelegate, but Apple cautions against that for SwiftUI. In a box marked Important, it states: “Manage an app’s life cycle events without using an app delegate whenever possible.”
For someone porting an app from AppKit to SwiftUI, that comes as a bit of a bombshell, and implies that Apple hasn’t worked out exactly how to convert common AppDelegate functions into SwiftUI’s App protocol. After five years, that’s more than a little unhelpful.
Auto Layout Cocoa Mac macOS 14 Sonoma Open Source Programming Swift Programming Language SwiftUI
