Yeah. I'm typing this on my safari which shows both vertical tabs and the horizontal tabs - looks so weird. And I always end up clicking a tab and then typing away, and Safari starts switching me to tabs starting with whatever letter I type - very annoying.
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 (.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...
reply