They used to support that. Isn’t possible to do unified memory in those configurations? If not, then I expect it’s a headache Apple does not want to deal with. For example, earlier versions of Metal have unified/discrete memory modes with different API availability and behaviour in each - what a nightmare to support and maintain and keep bugs out it would be
I stopped reading almost immediately. The stylistic choices in the writing just felt like LLM to me. Examples:
"depth estimation that beats PyTorch on CPU in half the memory" — "…beats X in Y…"
"Most LocalAI backends wrap somebody
else’s engine, and that is the right default." — "…and that is the right"
"MLX and the rest are maintained by people who are better at those models than we are" — "better at those models than we are" — it's this thing that LLMs do where they are kind of weirdly confident but overly deferential
"This post is about what those ports buy" — "…buy" used in this context
"Same model, 1.31x the speed" — "Same X, something Y" — it's this overconfident yet deferential writing style
The further I read, the more tells there are. I find it incredibly tiring to read LLM generated prose and I'm not sure why. Is it because I'm aware it's not human written and have an unconscious bias? Or is it because the style is just full-on, "Not X but Y. Those performance gains are bought, not earned. This stops, that starts. Read on, or don't, that's the follow-up"
For me, it's that AI writing is always trying to be clever for every single point it makes (and constantly uses the same language patterns when doing so).
Its like listening to an insufferable clever dick, who is not as bright as they think they are. You would also find it incredibly irritating if a human talked like that
I've always used em-dash. I got familiar with the hotkeys when I started using Mac OS X in 2002. Option+Hyphen for en-dash, Option+Shift+Hyphen for em-dash. It's unfortunate that it's an LLM tell. I'm glad the LLMs haven't subsumed proper ellipses yet…
SwiftUI has a lot of failings, but it can also do a lot of things that are really tricky in UIKit.
I can render Metal shaders trivially in SwiftUI. Rendering glows, and blurs, and animated effects is much easier in SwiftUI than in UIKit, just use `.blur(radius:)` or `.blendMode(...)`
I have used AppKit and then UIKit since its inception. Creating visual effects like layer masks that modulate the opacity of underlying views is trivially easy in SwiftUI — far easier than the boilerplate and constant bookkeeping that CALayer's mask requires.
So a lot of the advanced full-screen animations in some of my games and apps are SwiftUI, because they are performant, provide the cool effects and animations, and work great. A lot of the simple get-the-job-done views and tool palettes in my apps are also SwiftUI, again because they don't ask much and get the job done, and look great.
However, where SwiftUI falls down is exactly what was demoed in the video: large collections of thumbnails that fetch asynchronously? Use UIKit. Multi-thousands of items in large, complicated lists? You can try SwiftUI, but you'll need to learn how to optimize it.
Other things, not mentioned in the video, that are more annoying in SwiftUI: want to take control of a transition between views, end-to-end? Not really possible in SwiftUI. There are bugs with ZoomNavigationTransition that affect all of Apple's own apps, and you aren't gonna be able to fix them without switching to UIKit.
It’s incredible some of the little details in LEGO instructions.
My son and I were assembling a set, and one of the corner pieces was strangely absent. My son asked, “why can’t we put this piece in yet?”
The answer came when we turned the page and saw the model had to be flipped. That missing corner piece was the only thing we could use to guide our placement of pieces on the underside of the model.
Similar things in more complex sets include using different, bright colours for bricks on the left/right sides of the internal parts of models. It makes it easy to keep your place as the model rotates through the steps.
Their docs seem entirely LLM written. It seems especially obvious in the FAQ. While I'm not against using LLMs for writing assistance, they've left a lot of the unnecessary language and typical stylistic choices in there, which erodes my trust in the project a bit. Perhaps it's a very good game-oriented version control system, but the lack of human attention on the docs makes me wonder how much they care
I reluctantly agree. I was interested to read the system design doc[1] but it's so many pages long and so full of redundant statements and needless details[2] that I gave up a couple sections in. The numerous "it's not X, it's Y" constructions give the game away. If they can't be bothered to read these docs themselves, why should I?
Anyway it's probably fine software and I am genuinely going to give it a shot for a usecase I have involving large image files. But the LLM-generated docs don't inspire confidence.
[2] They literally have a section header "10.1 Revision state as a 320-byte fragment". The byte size isn't even relevant in the code as an implementation detail, much less belongs in a design doc. No one read this doc before publishing it.
Yeah, I agree about the docs. I started on the system design page and my head started to swim after about 5 minutes. So exhausting to read!
On the flip side, I expect the project itself will be workable - well, assuming they're actually using it themselves! UE is a big pile of Stuff on its own, and Fortnite must have god knows how much additional crap in there, so if this is (or will be) their replacement for Perforce internally, then it'll be getting a good deal of testing. (If they're just chucking it over the wall, though... well, sheesh, you first...)
(Perforce is the standard thing for games, and pretty well it works too, and hopefully this will deliver it a well-needed kick. It was sold to private equity about 10 years ago, and it feels like they've been coasting ever since. (Perhaps users in other sectors are happier though?))
Yeah, I hope I'm wrong, but it feels a little bit like "planned project no longer has internal support, let's see if we can make it open-source to garner goodwill and recoup some of our investment." Which isn't the worst thing that can happen.
There are a lot of ways that AI speeds up software development processes that aren't the actual software development.
I am finding that lately I do not allow LLMs to write any code I am interested in maintaining. Or if they do, I have to micromanage them and it usually takes longer. They produce mediocre solutions, and often add redundant state ("Why did you add that state?" "Because we might need it in the future")
That said, they are extremely good at:
- Dev tools: creating debug tooling, debug screens, scripts that get the job done
- Auxiliary development: landing pages, "what's new" screens, tedious boilerplate, gathering strings for localization
- Prototyping: building full implementations quickly so you can see all the problems rather than having to anticipate them
- Pure transformation: porting from one language or paradigm to another
So while I agree with the article that the actual spec of the feature you are building needs just as much human thought, regardless of AI, the speed-ups around that are worth exploring
An example I have from a recent feature development is adding CarPlay support to an existing app. We could have talked about it and designed it for weeks, but with an LLM I was able to get it running in my car in an hour, go for a drive, and feel it to understand whether it was a valuable direction.
The code was a mess, most of it had to be thrown away, and the LLM couldn't even get the initial build functional (not much CarPlay training data, I expect). But it was an accelerator to answer the question "is it worth investing more time in this?"
To repurpose a quote from Walt Disney, I don’t make software to make money, I make money to make more software.
I want my hobby project to be my job, because I don’t want to work for someone else. I want creative control, freedom to explore and ship ideas, and financial stability.
The only way to get there, that I can see, is to charge for my work.
I always wondered how this compares to the 1999 algorithm Texture Synthesis by Non-parametric Sampling [1]. The results look very similar to my eyes. Implementation here [2] — has anyone tried both?
Woah. As an adult man with five kids, two of them infants, the most natural thing in the world is for them to be present in almost every second of my life.
It’s not difficult at all. Minutes after birth, naked baby was on my naked chest, and bonding started. This never felt contrary to my instinct.
Ok, you may consider it easy after 5, and kudos to you, but kids are definitely not “not difficult.”
I agree that it’s the most natural thing, and I consider most of my time spent elsewhere to be a waste, but our youngest is very active and worrying about her wellbeing for extended periods is definitely exhausting!
We had a contention between MCP / Skills for our product and ended up offering both. We built a CLI tool that could interface with the MCP server [1]. It seems redundant but our app is a coding app on iOS (Codea), and the issue with offering a plain MCP server meant that the agentic coding harness found it harder to do its job.
With the CLI the agent could check out the project, work on it locally with its standard file editing / patching / reading tools, then push the work back to device. Run and debug on device, edit locally, push.
With MCP the agent had to query the MCP server for every read and write and was no longer operating in its normal coding loop. It still works, though, and as a user you can choose to bypass the CLI and connect directly via MCP.
The MCP server was valuable as it gave us a consistent and deterministic language to speak. The CLI tool + Skill was valuable for agentic coding because it allowed the coding work to happen with the standard editing tools used by agents.
The CLI also gave us device discovery. So the agent can simply discover nearby devices running Codea and get to work, instead of a user having to add a specific device via its IP address to their agent.
reply