RodoBobJon

hace 4 mesesdiscuss

Perfect example of what you’re talking about: today a coworker of mine showed off a vibecoded data viewer app that lets him view our analytics in a way that works well for his job, using our analytics platform’s API. A nice little personal productivity boost for him, but not something that will ever replace the analytics platform itself.

RodoBobJon

hace 2 añosdiscuss

It’s possible at least some of those people enquiring about the AI strategy are looking to find out if a company is about to ruin itself with bad decisions around AI. And some others are probably saying what they think people want to hear.

And yes, of course some are caught up in the hype; that’s the nature of these hype bubbles.

RodoBobJon

hace 6 añosdiscuss

Sure, in theory Twitter’s website could be very simple and straightforward, built on tried and true web technologies. In practice, they wrote an entirely bespoke web app that is every bit as complex as a native app but shittily executed and with a terrible UX.

RodoBobJon

hace 6 añosdiscuss

But the implication of this argument is that the benefit of PWAs is to the developer rather than the user, right? If PWAs actually benefited users, then creating one instead of an Android app wouldn’t be waste of time even if you had to create a separate iOS native app in either case.

RodoBobJon

hace 6 añosdiscuss

This is the contradiction:

Apples’s defense of its in-app payments rule is that having a single payment system owned by the platform used by every app on that platform provides the best experience for users. According to them, Apple isn't being greedy but rather they are ensuring their users have the best experience on their platform.

But if a single payment system for a platform is such a great user experience, why does Apple not offer that superior experience to their Apple Music customers on Android?

Of course, one could argue that Google's refusal to require apps on their platform to use their in-app purchase system means that superior user experience of a uniform payment system is out of reach regardless of what Apple does with their own apps on Android, so maybe it's not a contradiction after all.

RodoBobJon

hace 6 añosdiscuss

I think they're mad about the "Apps" section on the Summary tab. But I don't really get the complaints or see it as an advertisement; it's at the very bottom and users may genuinely be wondering how they get more data into the Health app, and a curated list of apps that do that is useful.

RodoBobJon

hace 7 añosdiscuss

The idea that minimum wages kills jobs is not as well supported as you might think. People commonly take overly-simplified econ 101 labor market theories as gospel when the empirical evidence about the effects of minimum wage increases is decidedly mixed: https://www.vox.com/future-perfect/2019/11/20/20952151/shoul...

RodoBobJon

hace 7 añosdiscuss

This drives me crazy with Slack. In 2019 I can't have two chats open at once? Madness.

RodoBobJon

hace 7 añosdiscuss

Yes, but FaceTime is not attempting to be a camera; it is attempting to simulate a face-to-face conversation. That it uses a camera is an implementation detail. The fact that the distance between the camera and the face on the screen makes it look as though the person you are conversing with isn't quite looking at you is an implementation detail leaking out of the intended abstraction.

RodoBobJon

hace 7 añosdiscuss

FWIW, the Apple developers discussing SwiftUI on Twitter are careful to point out that SwiftUI is not designed to be a wrapper around UIKit. Much of the implementation currently uses UIKit under the hood, but that's an implementation detail that is subject to change and there are already significant parts of SwiftUI that don't use it.

It seems as though they are viewing SwiftUI as a successor to UIKit/AppKit on all their platforms, not just a higher level wrapper.

RodoBobJon

hace 7 añosdiscuss

SwiftUI has state. The idea is that all layout code is defined as a pure function of the state. Basically you can annotate properties with `@State` and each time one of those properties is updated, your view `body` function is re-run to produce an updated view.

SwiftUI tries to do clever stuff under the hood to only update the portions of the view hierarchy affected by the state change for performance.

comments