I think you're underestimating the "more expensive". It's not a 30% discount or similar. API is at least 10 times more expensive (own experience), ~40x as expensive if [1] is accurate.
At that price difference, lots of things that are viable to do in whatever harness the subscription allows are simply impractical via API, you'd be spending a whole developer's salary just for the benefit of using a different harness.
I tried for example Deepseek V4 Pro for a bit (via API pricing), but it's _more expensive_ than Sol via subscription, even though $1.7/Mtok is a lot less than 20$/Mtok.
> API is at least 10 times more expensive (own experience),
More. On CC I'm currently burning ~$5k a day (according to claudes own metrics) and I use up the weekly quota in about 3-4 days. Meaning I'm eating $20k worth of tokens for a $200 sub.
Current session I have running in the background, spinning up tests mostly
> At that price difference, lots of things that are viable to do in whatever harness the subscription allows are simply impractical via API, you'd be spending a whole developer's salary just for the benefit of using a different harness.
Could you elaborate on that?
Off topic:
You did the ISBN visualization thing! Awesome!
API costs are simply too high. If you go wild you can easily burn $3-5k a day. If you really hammer it (ie going full parallel agentic) you can exceed $10-20k. And this isn't even going crazy. Those costs are simply too high to make any sense.
+1 for Typora. One of the things I like is that it gives you some flexibility in how it handles images you drag into a document for embedding purposes.
My favorite option is the one where it automatically colocates assets by creating a folder with the same name as the file, appends `.assets` to it (<filename>.assets), copies the image there, and then automatically sets up the preview and embed.
I'm working a new Fantasy Football league/format that is category-based (like hockey/baseball) in an attempt to make games more "watchable". The problem with traditional Fantasy Football, is that half of the game (defence) is ignored, while not very economically-valuable positions, like RB and TE, are elevated far past their real world relevance. This new system is my attempt at fixing both problems!
I've noticed that developers who started with UIKit really have a hard time working with SwiftUI. I think this is because it's not just new syntax, it's an entirely different way to think: state is the source of truth, views are ephemeral, and you describe UI instead of managing it.
> I've noticed that developers who started with UIKit really have a hard time working with SwiftUI.
I think this is true. SwiftUI became "very good" as of iOS 26 (in part because the performance gap mostly evaporated) and continues to get better in iOS 27. Over and over, I see UIKit developers trying to do things "the UIKit way" in SwiftUI, and they'd rather write TFAs instead of considering that they may need to skill up and learn to write effective and idiomatic SwiftUI.
That's just not true. I am still finding the UI taking 40-50% of CPU time with many hours of wasted time on optimising it and ugly hacks. There's no convincing some people though. Because they can always say you just don't know how to use it.
Well I've been doing this for a pretty long time and I'd like to think I'm pretty good at it.
Now, if only that code you write for iOS 27 can also work on older versions of iOS, instead of having to maintain legacy code for old versions forever…
It becoming "very good" now is the problem, because it's not backward compatible. So for us developers who are still lingering around supporting those poor iOS 15 (soon 17 thankfully) users, you are stuck with UI acting anywhere between horrendous or not not working at all, to being slightly broken, to working as intended.
Apple has been adding Observable support to UIKit as well, so it's easier than ever for state to be the source of truth in UIKit too. Anyone writing more than simple UIKit apps has known that for a long time, it's just big a huge pain to actually implement without a lot of custom code or a dependency like RxSwift. If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API.
Personally, SwiftUI makes the 80% so much easier that, even if the remaining 20% requires dropping down to UIKit, it's worth it.
> If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API.
apple/obj-c had bindings and automatic ui updates more than 20 years ago in appkit; apple could have added that capability to view controllers in ios a long time ago
It’s also not possible to make super bespoke interfaces without going against the grain of the framework: anathema to old school AppKit and UIKit devs.
It's not just super bespoke that SwiftUI can't do well, there's lots of little things that are standard in UIKit and AppKit) widgets that inexplicably never made their way over to their SwiftUI counterparts. It's not unusual to have to drop down to the UIKit version for some little thing that Apple couldn't be arsed to port over.
This is incredibly frustrating, particularly now that more UIKit and SwiftUI widgets share underlying implementations.
I have always treated state as the source of truth in UIKit. Every view gets an equatable state struct, and mutating it triggers an idempotent view update. Self-mutating views (e.g. inputs) back-propagate their state up the view hierarchy.
SwiftUI/React/etc don't introduce that pattern, they simply enforce it (and add efficiencies).
If a developer isn't familiar with the pattern, it's not because they are a UIKit dev, it's because they are inexperienced.
I don't know iOS-specific links off-hand - I'm basically just referring to rudimentary state-driven UI. But implemented manually, without a framework, and therefore bug-prone for unfamiliar devs.
For example (this is pseudo-code, I haven't written Swift in a long time):
class ProfileViewController: UIViewController {
struct State: Hashable {
var username: String?
var profileImageURL: String?
}
var state = State() {
didSet {
if state != oldValue { updateView() }
}
}
// must be idempotent
// must only read state and only mutate the view
function updateView() {
usernameLabel.text = state.username
profileImageView.setImage(url: state.profileImageURL)
}
}
Lots of stuff can complicate this: External sources of truth (CoreData, UserDefaults), reference types (no memberwise equality), self-mutating views (UITextField), continuously changing values that state is derived from (the current time). But the pattern is so simple it's easy to extend it to account for these things as needed, usually with another layer of `update...()`, e.g. `updateState()` from a CoreData observer.
I don't know, in my circles Swift was welcomed like a long-awaited friend. We loved ObjC, but none of the advantages ObjC has over Swift are relevant to app dev. Conversely, everybody recognized the beauty of most early Swift features, notably Optionals.
Agreed. SwiftData is terrible for anything more than like 2 "Models". I have a bunch of apps written with SwiftData and a bunch more with GRDB... I hate touching the SwiftData ones.
What does this even mean? There are hundreds of thousands of apps in the App Store that are 100% SwiftUI. They are real. And they are very much "production grade".
The only people still complaining about SwiftUI 7 years later are the UIKit holdouts that never took the time to properly learn how to use it.
> There are hundreds of thousands of apps in the App Store that are 100% SwiftUI. They are real. And they are very much "production grade"
The first is a statement of quantity, the second is a statement of quality, dubiously supprted by the first.
The Mac Settings app still lags between panes years after it was redesigned to look like iOS. I would think that if they had a viable way build a high quality and performant app with even relatively basic UI components (if they cared to do so) they'd do it for the 1 app that's deployed to every mac.
SwiftUI does work in certain circumstances, and does work for allowing people to shit out their ideas faster, but it has struggled with the aspects described in the video. Some companies don't care either, and turnaround time is paramount, but in this discussion it's about quality compared to what came before.
I think it's a little of both, but last time I tried making a performant NavigationView/NavigationSplitView/VStack like that, it chugged along compared to the same layout built with AppKit
A daily meditation "instrument". I'm a big fan of Waking Up but I've kinda outgrown the catalogue. I know what to do now. I just need a timer and a couple of prompts...
The funny thing is at my current employer, they mentioned that "coding is increasingly becoming a solved problem" and in the same breath, mentioned that one project was too hard for anyone to do so they're not doing it and would rather sell existing features...
Weird. Coding isn’t really “solved” - because “coding” isn’t just the process of typing in characters as fast as possible - BUT the skill floor has been massively lowered while also raising the skill ceiling considerably.
We’re doing projects now that seemed impossible before because we have access to these powerful AI models. They can make things that would have taken weeks or months take days now, freeing up time for even more ambitious buildouts we never would’ve even considered before.
Sure but have you ever seen it actually play out in practice like it currently is? Whether or not it's true (of course it's not) people are currently behaving as if it is and firing/hiring accordingly.
Well, when was the last time you wrote machine code by hand?
... but then they went and changed what coding meant.
We've always been layering abstractions on top of abstractions. If we get to an abstraction that works well enough that you no longer have to dive down into the previous layer, we say we've solved coding, and change what coding means. Obviously LLMs aren't there yet.
I love that quote, especially considering the insane amount of bugs that are produced.
It’s as easy to debunk as someone claiming ”I can jump to the moon”.
There's your answer