I agree with Epic. It should be like on windows or macOS where you can register, get notarized, and then distribute without scare screens. I don’t see why phones are inherently different than computers.

I don’t want to be too flippant, but I think there is a real trade off across many aspects of life between “freedom” and “safety”.

There is a point at which people have to think critically about what they are doing. We, as a society, should do our best to protect the vulnerable (elderly, mentally disabled, etc) but we must draw the line somewhere.

It’s the same thing in the outside world too - otherwise we could make compelling arguments about removing the right to drive cars, for example, due to all the traffic accidents (instead we add measures like seatbelts as a compromise, knowing it will never totally solve the issue).

“Acquihire” means there was an acquisition. This is just a hire.

Didn’t we all learn this with the Snowden files? Nothing new unfortunately

Yeah they are both acting as a RAT essentially. Just one is in your control and one isn’t.

Why? I'm an iOS developer and, while I don't love everything about liquid glass, that is the current design language of iOS.

I certainly don't think having my app sticking out like a sore thumb, using a design language from old outdated iOS versions is "a good thing"

The new direction isn’t Liquid Glass, but a more unified branding across Android and iOS. WhatsApp, Google Maps, Instagram, Netflix, Prime Video, and many others don’t look dated, because they don’t make heavy use of the older iOS design language at all.

The parent comment is seemingly blaming React for the decisions of Shadcn for some reason.

There’s nothing about React that requires you to overcomplicate your DOM (unlike many other UI frameworks).

The point I wanted to emphasize is that even if you do overcomplicate your DOM, the component abstraction is what allows you to fix it in one place. Don't like what's in your component — add `return <input />`, bam! It's fixed across the entire app now.

And how is the surrounding JS code, like the event handlers, and the CSS of the component supposed to still work now? A radio input will need at the very least additional CSS to remove the native appearance. Unlikely that was set already --> it's not that easy.

The idea is that the component's API is not the DOM. Usually this means your data should flow in a certain way: top-down.

Application code is not supposed to use the DOM as the source of truth for some boolean state that the checkbox is an input for.

You don't usually read a component's state from outside (here: the "checked" property).

Instead you define an API where data only flows top-down.

When your checkbox component follows this paradigm, it is "controlled", and if it contains a standard HTML input, that input's "checked" DOM object property is bound to the data passed into the component ("props"). Clicking it won't check it anymore until you add an "onClick" callback and pass a function into this callback that will make the "checked" prop change.

The checkbox is now "controlled" and it's state was "lifted up" (meaning that it is determined not by the checkbox component itself).

"controlled" means you tell React to always force the "checked" DOM property to be the same as the "checked" prop you pass into the component. You do this by assigning to the reflected "checked" HTML attribute in JSX.

When your components only use this "top-down" data flow, they're "pure" in React lingo. Because they look like pure functions: props => DOM fragment. The machinery behind the scenes means they're not actually that (something has to coordinate the rendering).

But if you don't use internal state (e.g. useState hook) or global stores, these "impure" parts are React internals only, and you can have a mental model that views the component like a pure function.

This makes it easier to connect it with other components in a tree.

For example:

HTMLInputElement.checked can be true without a "checked" attribute being in the markup.

If you want to have some text next to it that says "checked / not checked" you have to wire stuff, and this stuff depends on your markup.

If you have a "controlled" checkbox, you have a tree, not only for the markup, but also for the data: the boolean "checked" state can now be declared one level above both the info text and the checkbox. Then the info text doesn't care at all about events anymore.

And the checkbox component only uses a callback that is also independent from the exact markup structure (e.g. a selector for the HTML input element).

You don't need to read from the checkbox to update the text. You feed both with a boolean and both can be "pure" components. The checkbox gets a "onClick" callback and it's checked state is no longer internal, it's "controlled".

The wiring you have to do instead of the regular DOM events (which would read the input's state) is now to use your "onClick" callback to toggle your boolean.

Internally, in the component, you do whatever you need to read and write to the DOM. But usually that just means "what markup do I return".

Input elements and reflected attributes such as "checked" are already a relatively complex case.

And, you can escape the recommended top-down data flow by many means (refs, context, accessing centralized "stores" from within the component...), but that's often where it gets ugly. But you need to do it often when your app gets bigger (centralized data stores), or when you implement things like UI libraries (refs).

If you already have a Swift app it could be worth considering. Or if you are targeting like 90% iOS users and just need Android support to check a box.

Yeah unless you legitimately enjoy it, want the experience, or want to save up some money for a while - I don’t think it’s worth it (coming from someone that spent 10+ yrs at FAANG).

It’s certainly not apples to apples with any other random tech job to where you can just compare TC while ignoring level of stress. And the money is good but not life changing good.

I’ve been using Alfred for forever, but with the new Spotlight on Tahoe I’ve decided to just try using Spotlight alone.

So far I’ve been pretty happy with it. But I was never a heavy user of the Alfred power features (despite owning a lifetime license for Powerpack).

Same here. Despite Legendary status, I’ve used Alfred as a souped-up launcher and implemented my workflows app-agnostic either as a shell script, a Shortcut, or an AppleScript. I haven’t launched Alfred since upgrading to Tahoe.

Especially since you can now create Shortcuts that get input directly from Spotlight or the active window.