Notices by Rob Napier (cocoaphony@mastodon.social)

@inthehands @arroz hmmm. Hadn’t thought about the SSID specifically. I named my networks the same thing here as in Raleigh. I’m wondering if it’s put that into the database and it’ll stay locked for some time until it gets some data telling it it’s changed.

I'm having trouble getting macOS to update its current location. It still thinks I'm in North Carolina, even though I'm in Connecticut. Can't find GPS maybe? (Is there somewhere to see error messages for that?) My phone knows where I am, but two MacBooks, about 5 ft apart, both are having trouble updating location.

I'm at the "How does this ever work?" stage of debugging…

oh wow, yes, I just broke out one of my 30-pin connectors to charge up this iOS 5.1 iPad because I don't have any other iPads with large, unbroken screens handy…

Do I miss skeuomorphism?

Hmm…

Hmmmmmm…

Yes. Yes I do. We've fallen so far.

This really drives home something about LLM systems. They’re very expensive to run, both to train and per-query, and hard to make cheaper. I expect them to get more expensive to run. They’re currently sold at a big loss to establish monopoly power and then raise prices dramatically. That’s the *stated* business plan.

If you’re building your business to rely on LLM, you need to factor in what you‘ll do when they pivot to making money, or they pull back because they can’t.
https://geeknews.chat/@theregister/112116266764229145

Trying to get things to build in Xcode is infuriating, yes...

But have you tried getting things to build in Android Studio?

Also infuriating.

Fight all day with SwiftPM…

Turns out I also fight all day with Maven.

Maybe it's just our whole profession? I don't know… Good grief. How is it we ever ship software? Truly, we are heroes.

oh no. Seriously, while I was typing this post:

apk:dexBuilderBetaDebug -- java.lang.OutOfMemoryError: Java heap space

😭

A reminder: When that major security bug shows up in one of your dependencies, and you need to ship a fix right now, that's not the time to discover you're 3 years and 6 API-breaking changes behind the version that has the fix.

Upgrade your dependencies when you don't *have* to. That way, when it is critical, it will be fast and low-risk.

This is *especially* true about that risky upgrade you've been avoiding. Take the hit now when you can schedule it. Don't let others schedule it for you.

@mergesort @kylebshr @jsq and yet still, I can’t say 3 sentences about Swift concurrency without making 2 misstatements. Check the replies from @rjmccall and @justkwin who actually know what they’re talking about.

@justkwin @mergesort @kylebshr @jsq @rjmccall true for the community. But Apple is saying explicitly up on stage that it is “the best way to write apps.” So we’re kind of struggling. I’ve recently backed off my push in my team for “no more non-actor classes.” It turned out almost everything I tried to write required hours of research and no definite answer. So now it’s closer to “if you feel like doing the hard work of figuring it out, then it would be nice if you tried some async/await.”

@rjmccall @jsq @kylebshr @justkwin @mergesort I’ve been treating MainActor classes as just another kind of actor. (Maybe that’s confusing terminology?)

But in large programs, “just not sending between concurrent domains” sounds a lot like what we’ve been doing and failing to do correctly (and the problem actors are supposed to help).

How did I wind up writing C++ again?

@crazybutable @inthehands I've heard many devs say "I don't know how this feature will be used. It seems dumb, but the product managers are the ones who know the customer, so I have to do what they say."

My answer is always the same. It's our job to learn those things, and they're learnable. We may have different skills; Swift or SQL or graphic design or testing or analyzing user feedback. But every one of us is responsible for delighting our users, and we can only do that if we know them.

@crazybutable @inthehands IMO it's an unhealthy shop if the designers systematically know more about the customer than the developers do. That suggests developers who are too isolated, and need to be more engaged with the product and the users.

I've had great experiences with designers who've incredibly improved my work. But I've never personally seen great software from orgs where design held unilateral approval decisions. Those are the orgs I've most often seen make terrible "x-platform" UX.

@inthehands @crazybutable I think we often forget that part of the job is learning the space we're working in. If we refuse to learn anything about our client's experiences, we cannot deliver them good software. No amount of checklists will fix that.

A common example I've used is a car. You expect any car you buy will have a steering wheel, brakes, headlights, and the like. You expect the car manufacturer to know you need them even if you don't ask. They can't say "I don't know your use case."

@inthehands My definition of "requirement" is a thing that, if it were impossible to deliver, we would cancel (or at least seriously reconsider) the project. If its impossibility causes the "requirement" to vanish, then it was never IMO a requirement.

BUT! devs often forget that minimally delivering just the "requirements" may still result in a worthless product, and the goal is a worthy product. Checklist-obsession is not useful. The goal is to delight; not barely meet "requirements."

Every so often some question on SO is just a rant about Xcode and says something like "the worst IDE ever created" and I'm just floored thinking what a tiny slice of our history this person must have experienced. They've tried a few IDEs from JetBrains and think they've sampled the world?

Come with me, summer child, into the world of Qualcomm firmware IDEs. Custom IDEs built by Nortel. The cult classic of USCD Pascal (with its admittedly primitive glory, but you don't want it to replace Xcode).

@ZachWeinersmith I spend an unfortunate amount of time helping new coders with ChatGPT-generated code. Repeatedly, the code is worse than nothing. It takes them down the wrong road (often a nonexistent road), making it harder for them to find the right approach. Code-reviewing AI code is very difficult because its mistakes are not like the mistakes human coders make.

You should not use an AI to write code you couldn’t have easily written yourself. You must be able to carefully judge its output.

I was really hoping that Xcode 15 would include some incremental build performance improvements, but I'm not seeing any so far. SWIFT_USE_INTEGRATED_DRIVER=NO is still 2-3 times faster. ~20s to recompile a one-line change, which isn't great, but it's workable. With the integrated driver, it's about 1m for every build, not counting getting it onto the sim/device, etc.

Worse, AppIntents extraction is now more aggressive, and adds an extra 70s even if AppIntents is not linked. FB12215849

It looks like "Extract App Intents metadata" is happening in Xcode 15 even if you don't link the AppIntents framework. This can add significant time to every build, including incremental builds (in our project, ~70s). FB12246243

The build setting LM_ENABLE_LINK_GENERATION=NO disables App Intent extraction entirely. I don't believe this is documented anywhere; I reverse engineered it from Xcode.

🎶 SwiftData SwiftData SwiftData SwiftData SwiftData SwiftData SwiftData SwiftData 🎶

<deep breath>

Sing it with me! (You may pick your own tune.)

🎶 SwiftData SwiftData SwiftData SwiftData SwiftData SwiftData SwiftData SwiftData 🎶