Overcast’s New Foundation

I’ve been a daily user of Overcast since its inception. It’s probably in the top five of my most used software. This is an embarrassing update for a ten-year-old app. Especially after being stagnant for years. The number of bugs I encountered in just two days makes it borderline unusable. It’s so obviously rushed, it feels like an early, early beta that’s yet to receive constructive feedback. The user interface and information architecture are full of beginner mistakes that are typically made by programmers with a lack of expertise and an untrained eye. I’m quite certain that the only part that was touched by a professional designer is the app icon.

I don’t use this app normally. Installed to test the new version. In the postcast list, I saw “ATP (Expired Subscription)”, so I deleted it. Pulled the list to refresh, and the “ATP (Expired Subscription)” entry reappeared. I have no idea what backend is used for data management, but initial impression of the new “foundation” is … not good.

@D. i had to chime in after reading your comment because…

i just listened to the latest episode of accidental tech podcast in which arment expressed his hope for receiving next year's apple design award. it's great to have pride in your work, but man oh man.

after listening to his co-hosts and seeing reactions of the usual apple-media-clique, i'm starting to think that i'm the one who's actually completely out of touch with reality.

You can avoid updates, by installing the app in a special way. It's best done with apps whose configuration or data lives in the cloud.

https://blog.gingerbeardman.com/2023/08/17/going-back-to-the-old-pre-x-twitter-ios-app/#avoiding-updates

@matt Good to know! But you need iTunes for Windows to get the old IPA?

I see in the blogpost something called Blackbird mentioned. Let’s take a look:

https://github.com/marcoarment/Blackbird

> Philosophy:
> - Prioritize speed of development over all else.

I guess that’s more important than data correctness too? When did the development world become so shallow? Is this why everything is so terrible in modern software? Developers thinking “me me me over everything else”.

@Leo I take that to mean that it prioritizes development speed over runtime speed, or simplicity and debuggability over prettiness, or similar tradeoffs, not that it doesn’t care about correctness. Development speed would be compromised if you’re always trying to track down bugs…

One huge bug for me is if you use high priority podcasts (I do) and have the setting “play top episode next” turned on (so if a high-priority episode is downloaded while you’ve been listening to another episode Overcast will play the first episode in the queue rather than the next episode in the queue) the app simply stops playing and won’t play anything. I listened to that episode of ATP which suggested that several people tested the app - how was something like this missed?

Otherwise it’s working fine for me, though, and has one new feature - ranked high-priority rather than grouped by podcast - that I’ve long wish it had.

I love Overcast and used it daily for years. Also like it because it's a native obj-c / Swift app, unlike its competitors;

This update however, is a downgrade, and like others i also encountered many bugs.

Also: in terms of UX / accessibility, it's a major downgrade. My (older) mother now can't cope with it anymore unfortunately. She now uses the Apple Podcast app instead.

Let's hope for improvements soon... (i'd hate having to use a non-native app like Pocketcast, etc.)

@Michael But we know this tradeoff is done all over in the software world, at the expense of UX quality, and, often, stability and bugs. SwiftUI is a perfect example of this. Marco’s new foundation is a perfect microcosmos of a modern software development world, where instead of doing a lot of work, sometimes adding hacks, to get a great user experience, emphasis is put on the developer “velocity” and “experience”, while, in the good case, the UI is an afterthought and incoherent, or, in the worse case, broken software. Obviously, it’s not just Marco. Apple, for example, is rewriting software feature by feature, app by app, making any feature they rewrite worse and lacking, any app rewritten in SwiftUI is broken in spectacular ways. Microsoft software quality is in shambles too. Anywhere one looks, you see these trends.

Not having waited, your decision not to update seems to have been very smart. It's version 1.0 style mistakes (and an over-reliance on data subscriptions for the UI I think), and I'm hopeful he'll fix it soon, but it is a mess.

That said, this update does solve the 30 seconds of molasses and then a spasm of activity on initial open issue and makes the app [for me] almost usable again. I was stuck in that unresponsive mode from (afaict) having too many active podcast episodes in the queue. I have gigs on gigs, but I was scared to delete b/c so many episodes are no longer accessible online from subs that delete or put older episodes behind a paywall every few months.

But no, don't update yet if you can stand not to.

I think his issue was lack of beta testing, not bad programming. He said he had 30 testers, but they all must have similar usage patterns -- or there was a good number of lazy testers, which is all too common, even with well-meaning folks.

I believe him when he says the app worked for him, I bet it worked for his friends, but like all software (mine included!) everyone has a plan until the release punches them in the mouth. Version 1.2 of this (whatever that works out to in his year-release pattern) is probably going to be the sweet spot. I hope. It is, essentially, a variation of The Netscape Mistake.

All new source code! As if source code rusted.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material?

Here's a video of download trouble that I mention in the whatever you call a Mastodon post (a 'don?) above. Seemed to get better after posting yesterday, but then I was hit with it (exactly) again this morning.

I do keep wondering if there's a chance some of what I'm seeing is b/c of the podcast hosts (bad files, bad downloads, bad servers), but I'm suspicious it's not all coincidental timing.

I find the comments here a little overblown. I've been a heavy user of Overcast since almost its inception (indeed, it shows that I have the purchase from almost exactly ten years ago). The new version is some good and bad, but mostly shows promise, IMHO.

I _will_ say that releasing it as an update that's hard to downgrade from may have been the wrong choice. As Michael says, the smaller beta group and shorter beta period (presumably to hit the artificial "ten years in" deadline) doesn't help here. This version isn't quite ready to replace the old one: some people are running into significant bugs, some features are — as Marco acknowledges — missing entirely (so it's arguably an alpha), and some designs Marco isn't really sure about (I believe he alluded to this on ATP).

A few design quibbles that I hope get improved:

* a horizontal single scrollable row for all playlists? Maybe that works for some people, but certainly not for me. Scrubbing galore for me. I hope he either changes this, or makes the playlist section more customizable. I guess he found that people weren't using playlists much?
* navigating from the currently playing episode to its underlying show used to be obvious. Now it's so confusing that I (and someone else on Reddit) first thought it wasn't currently possible at all. It is! You tap on the circled 'i' (so far, so good), then on the circled ellipsis (er), and then you get a menu with a single item, which is "Go to Podcast". This feels about as silly as some of the UI in macOS System Settings.
* I also disagree with making the circled 'i' keep much of the main content around, but the chapter list instead show up as a sheet that hides all playlist controls.
* and then the sleep timer / audio settings sheet… looks differently yet again. Just unify these three?

Good:

* the 'go back' popup. Accidentally scrubbed / hit a chapter / etc.? Just tap that, and you're back where you were.
* _generally_ (I'll get to that), the UI feels _a lot_ smoother on my setup. I bet this differs a lot based on how many shows people have.
* overall, I think it also feels fresher/cleaner/more modern, in an ineffable way.

Bad:

* streaming is gone. I don't really care that much about streaming _per se_, but having to download _an entire episode_ just to even _begin_ listening to it is going to be annoying.
* audio playback is still very hit and miss. You'd think this is a key function of the app, but either Marco, Apple, or my audio devices, or a combination of those three, disagree. The app will randomly decide to stop playing. Then it will freeze for twenty seconds and then decide whether or not to resume playback. Or the OS will tell you it _is_ playing when the app disagrees. Or vice versa. Or both agree that it is playing, but you're not hearing anything, because it is not in fact outputting audio in a human-perceivable manner.

But again, I think overall, the only real misstep, if that, is that he should've made it a separate "Overcast Early Access" app while 1) features are missing, 2) new bugs are present, 3) he is himself unsure about some design choices. If he still had real version numbers, he could've even given it a big new number. _Then_, as the app gets closer to being ready to replace the other one, release it as an upgrade.

@Obra Dinn Downcast is an old horse but it still works great, is platform native. I use, works well for me, FYI.

I've been an Overcast user since essentially the beginning, and I respect the heck out of Marco. I am definitely one of those, "main thread gets blocked" users.

I see two buckets of critique worth making:
1. new design and layout. I don't *love* a couple of the changes, but overall I see what he's going for and I'm not mad about it.
2. SwiftUI implementation. Wow, this is a major red flag to me. Either he's made some serious errors in his use of SwiftUI or there are some serious problems with how it does layout timing.
* Every time I go to episode details I get flashing text.
* when I load the app after some time away, the next episodes list view is in all kinds of unloaded/reloading/etc states.
* so many animations lack the smoothness of the previous versions
* lastly, I get jumpy scrolling (on a iPhone 13 mini, sometimes in low power mode), but those are simple cells with fixed height and should not be a major problem.

So, I absolutely salute his effort to dive in and start fresh. I'm sure most of the problems can be resolved, but it is indeed in rougher shape than I expected.

The first thing I noticed that was bad about the update was that I saw an ad on the now-playing screen.

In my bug-report email I thought about having a subject line of "★☆☆☆☆ Ads" but after a little bit more reflection I figured it would be unlikely that he'd be in the head space to enjoy an Overcast/ATP in-joke like this so I went for a clearer, more conventional subject line.

I'll take his advice for "wait a couple days [before complaining about changes]". I suspect the next time I use the new stop-playback timer UI I'll still strongly dislike it, but I'll give it a second college try.

> The first thing I noticed that was bad about the update was that I saw an ad on the now-playing screen.

Hasn't this always been the case if you are not a subscriber?

In general I'm a bit disappointed reading the comments here. This is a single developer, rebuilding his own app that's his income and people are treating it like it's a big faceless corporation that owes them something.

As Marco said on ATP he's using it for the past 6 months so I doubt it's "borderline unusable" as some people here said. I upgraded immediately, was excited to see the refresh and I'm looking forward to using it for many years.

I don't want to sound like I'm hating on another indy dev (I'm not), Bugs happen...shit happens. But I wonder why he felt the need to rewrite such a popular app in SwiftUI? Why not experiment with SwiftUI in a new app / side project? He already has a lot of happy users why take such a risk for essentially no reward (users don't care what UI framework you're using).

>2. SwiftUI implementation. Wow, this is a major red flag to me. Either he's made some serious errors in his use of SwiftUI or there are some serious problems with how it does layout timing.
>* Every time I go to episode details I get flashing text.

SwiftUI magic implicitly refreshing all your shit I bet makes it very easy to trigger stuff like this. The same kind of stuff has been found in Apple's SwiftUI apps.

>A few design quibbles that I hope get improved:
>* a horizontal single scrollable row for all playlists? Maybe that works for some people, but certainly not for me. Scrubbing galore for me.

Devs seem to be willing to experiment a lot more with layout when they use SwiftUI. You probably wouldn't do that in UIKit. A side effect of having to spend a bit more time implementing something is that it forces you to think harder about it, which is a good thing.

Perhaps this will end up being one of those case studies in why you shouldn't completely rewrite a stable codebase. Or perhaps it will be a case study in the perils of chasing SwiftUI and Swift Concurrency. Or perhaps both.

@ObjC4Life Marco discusses this a lot in the linked podcast episodes. In brief, the old code was making it hard to evolve the app. I guess he could have rewritten it with UIKit, but he says that SwiftUI makes iteration faster and requires less fiddling to get animations and layout right.

@Dave Or maybe he fixes the bugs over the next few updates and finds it much easier to add new features going forward? I guess we’ll see.

Hasn't this always been the case if you are not a subscriber?

Overcast Premium was a shut-up-and-take-my-money kind of thing, so I might have seen _one_ ad a while back after turning ads on just to see what they're like. I have a lot of unplayed podcasts and I haven't been aggressively trying to get the number down, so the last thing I need is an ad for more podcasts.

At least I got a reminder of why there's so much unused vertical space in the now-playing screen.

Like John Siracusa said on ATP #596, hopefully with his newfound Swift UI-powered velocity Marco'll be able to fix the bugs that got introduced in the rewrite lickety split and Overcast will be better than ever.

> @ObjC4Life Marco discusses this a lot in the linked podcast episodes. In brief, the old code was making it hard to evolve the app. I guess he could have rewritten it with UIKit, but he says that SwiftUI makes iteration faster and requires less fiddling to get animations and layout right.

Thanks. I’m giving it a listen now (in the new Overcast app). I’m at the part where they are talking about sheet presentations in SwiftUI vs UIKit. My jaw is dropping. I found sheet presentation in UIKit to be limiting as well but by default I don’t see how the sheets in the new Overcast are any different than UIKit (I assume SwiftUI sheets wrap the UIKit implementation). I wrote my own presentation controller to make a sheet in UIKit to meet my needs (UIKits built in sheet API wasn’t good enough for me but my app required more customization). Took me around half a week to do but I can’t imagine doing the same thing in SwiftUI would be any easier.

I get the sense that the philosophy here is this: if the default design implemented by SwiftUI feels wrong…shrug your shoulders and do it anyway. That guy who said the best way to make a new app at WWDC a couple years ago should find another place to work.

I agree with ObjC4Life. It's not smart to spend so much time rewriting it (especially in a worse language) instead of using that time to fix bugs. (Then again, I do not use Overcast because I find Marco and the ATP guys too condescending in general. I use Pocketcasts, which I find works better anyway.)

@ObjC4Life Yes, it does seem like part of the new philosophy is settling for the quick 95% solution, whereas before he would spend a lot of time getting it perfect. In theory, it will eventually be fixed at the SwiftUI level, so the time he could have spent developing and maintaining a series of dead-end hacks can be spent more productively on something else. I can see the logic to this, but it may end up feeling wrong for a very long time.

If _Marco_'s impression is that the old code base was tedious to evolve, and that the new one (at least for now) feels like he can add features and fix bugs much quicker, isn't that reason enough to be a valid take?

Yes, I'm familiar with Spolsky's "things you should never do". But Netscape was different in that 1) the codebase wasn't quite as old, and the new codebase wasn't that much more modern, and 2) this was (part of) Netscape's bread and butter, at a time when they were already losing steam (and share). It's only a side project for Marco. If this were his main business, I would probably advise him to go with a gradual transition. But it isn't, so he can afford to be bold, and to do the project in a way he finds more enjoyable. Which, hopefully, in turn translates to the app evolving faster again.

As for whether Apple's strategy to tie SwiftUI improvements to OS releases is great, well… personally, I don't love it. But I can see how that's great for Federighi's org.

re: @Ruffin (July 19, 2024 9:14 AM)

That said, this update does solve the 30 seconds of molasses and then a spasm of activity on initial open issue and makes the app [for me] almost usable again.

I've been dealing with the same blocking the main-thread issue as well.

I didn't upgraded because of all of the negative reports I've been seeing everywhere.

I was stuck in that unresponsive mode from (afaict) having too many active podcast episodes in the queue. I have gigs on gigs, but I was scared to delete b/c so many episodes are no longer accessible online from subs that delete or put older episodes behind a paywall every few months.

Same.

I recently learned that you CAN export audio files via the share sheet for individual episodes:

https://reddit.com/r/OvercastFm/comments/184045f/how_do_i_export_audio_file_on_older_podcasts_not/

https://reddit.com/r/OvercastFm/comments/1dz2s8a/trying_to_keep_old_episodes/

I haven't tested this fully but it seems to work as you'd expect.

I doubt there's a way to do this in bulk though. Which sucks.

Something like:
Put all of the download episodes in a single Playlist, Select all, Share, Export All Audio Files.

---

I've wanted to send Export All Audio Files as a Feature Request. Or be able to access the raw audio files via the "Files" tab in the Finder when a device is connected to the computer via USB. Like you can with VLC and other apps that pull from a media library.

But I assume Marco has already thought of this and rejected it, and I don't want to waste time sending an email into his ignore/Mark all as read/Delete all email "workflow".

I remember someone either leaving a comment here — or perhaps a link to a Mastodon post — something to the effect of, "SwiftUI destroying the platform one app at a time". Seeing many of the complaints with regard to bugs in Overcast here in the comments is now starting to make me worry.

I remember Tim Cook mocking Android tablet apps as just being blown up phone apps, and yet with SwiftU,I it seems as though we are on the fast track to that on iOS as well. When listening to the episode of ATP, I just got the impression in many cases where Marco and many other developers just say, "thats good enough because doing X with SwiftUI is hard", or make excuses for subpar interfaces and interactions because of limitation of the Framework.

There was also a few parts of the ATP episode where I started getting a bit annoyed as it started to feel like a sales pitch for SwiftUI, trying to rationalize a complete re-write with it by making it seem like the framework was providing something that wasn't capable before. In particular, when he was describing a publisher, and any part of the UI that is interested in changes to said value can be notified automatically of said change, as if NSFetchedResultsController or KVO never existed on the platform. That was at the point in the podcast where Siracusa mentioned "your describing model view controller".

And he's right. With proper MVC principles, your view controller can pass your model objects appproriately to the views that require the data, which they can register themselves as KVO observers of said data. When the data in your cache changes, any view registered as an observer to the particular model that changed, then the view can simply update itself, no code needs to be written to watch the cache or data model layers.

I also feel as though this whole notion of "SwiftUI makes iteration faster" is coming from developers who just refuse to use Interface Builder because of the ridiculous, "Real Developers Write Code!!" mentality.

I can't think of a better way to iterate a design quickly, than by dragging and dropping interface components onto a canvas (and not having to wait for the fake "Live Preview" to catch up). And once you've got your View Controller code implemented, swapping out the view with something completely different is just a matter of changing the name of the Nib you want to load the UI from.

I often would make a Nib, drag and drop some UI in place, make a rough layout based on my sketches, then test it out. If I want to experiment more, duplicate the file and re-name it, move some things around etc. When I've got something that I think I like, then I can go in and add the polish and constraints to ensure great resizing and dynamic text behavior.

Its a shame that Apple had a UI Framework that blew away, and was miles ahead of anything offered on Android, and are seemingly wanting to just start over, and in many cases I feel as though they are just reinventing the broken wheel.

JohnC wrote:

>I remember someone either leaving a comment here — or perhaps a link to a Mastodon post — something to the effect of, "SwiftUI destroying the platform one app at a time". Seeing many of the complaints with regard to bugs in Overcast here in the comments is now starting to make me worry.

That was me: https://mjtsai.com/blog/2024/06/13/redesigned-photos-app-in-ios-18/#comment-4105286

Sören wrote:

>If _Marco_'s impression is that the old code base was tedious to evolve, and that the new one (at least for now) feels like he can add features and fix bugs much quicker, isn't that reason enough to be a valid take?

No. The only thing that is valid is the quality of the software you release. Your personal impressions mean nothing. Any experienced developer has released something with lots of unexpected bugs and got hit with negative feedback; I don't want to sound like I'm trying to take down the dev of Overcast. BUT it remains to be seen if the Overcast SwiftUI app can recover. However, I'd like to note that this developer is *very experienced* (more experienced than me...I think he is about a decade older or more).

With that said...I think he's following Apple off a cliff. *ALL* of Apple's SwiftUI apps suck and SwiftUI is *NOT* new anymore. ENOUGH already! If they haven't figured it out by now, I don't think they ever will. More than half a decade in, they need to kill this thing already. Josh Schaffer, John Schaffer, whatever his name is should retract his strong endorsement of SwiftUI and/or resign from Apple immediately. While he may have the benefit of a nice corporate salary with virtually no accountability for quality, indy developers everywhere have to deal with this bullshit. Telling us to spend our precious time learning a tech stack that clearly isn't good is harming us all! We cannot follow Apple off the cliff! UIKIT FOREVEVER! JUST SAY NO TO SWIFTUI! DO IT NOW!

Josh Schaffer, John Schaffer, whatever his name is should retract his strong endorsement of SwiftUI and/or resign from Apple immediately.

I think one or more of us are getting our wires crossed between:

Josh Shaffer
John Ternus

In the WWDC video he's acting as a corporate mouthpiece, so blasting him personally for delivering the corporate line seems uncalled for.

Being a long ways from Apple dev, SwiftUI seems fine, in theory. Apple's just putting too little engineering time into it, as usual, to make it good on anything shorter than an infinite timescale. If they could remove internal barriers to hiring more quality engineers to make SwiftUI do more with less bugs, I'd be in favor of that.

On the Holly Borla and Ben Cohen interview episode, John floated the idea of evangelizing to the rest of Apple how great it is for Apple engineers to be able to interact directly with bug reporters instead of having to do all kinds of internal telephone game to ensure that nothing gets leaked to the public (that may actually be hostile actors probing engineers for information under the guise of submitting a bug report). Still, none of us are seeing any signs that this sort of thing is weakening, so we should expect maximum engineer time used per bug fixed.

@ObjC4Life

I just went back and listened to the part of the episode about the issue with the sheets. Like you, I was scratching my head a bit listening to that originally, as I just implemented a sheet earlier in the week in my project at work. It took me about 5 to 10 minutes to make a sheet change from .medium, .full and my custom size. I just pulled up my project in Xcode, and it was 6 lines total to make that happen. Grab the sheet presentation controller, specify my detents along with the detent resolver to specify my custom size. Set a couple properties to make the grabber always visible and the prefersScrollingExpandsWhenScrolledEdge set to true. Then I set my presenting view controller as the delegate.

I then implement the sheetPresentationControllerDidChangeSelectedDetentIdentifier to adjust behavior of my content in the presenting view controller upon changes to the detent sizes.

Overall, my presenting view controller is a total of 70 lines of code while my presented view controller displayed in the sheet is 37 lines of code, including comments and spacing. All view layout and setup in the Storyboard (good ole fashion MVC).

Granted, a very simple use case and straight forward UI that displays a sheet with some editing controls over the displayed content.

So when I hear Casey lead that conversation off with:

"This is a really good case study in SwiftUI because to get a sheet that comes up from the bottom of the screen, especially a few years ago, maybe its different now in UIKit…but a few years ago, that was a real pain in the hindquarters, on UIKit. It was fraught with errors, you’re reimplementing half the damn world in order to do it, and its just a pain, not fun work because you just want a sheet that comes up from the bottom…"

He continued, "with SwiftUI you could just do “dot sheet”… it just happens magically, its cake, its easy, its just chefs kiss, its great… until you want to customize it then everything falls down."

I don't get it. The API for sheets I don't think has changed since introduced, so to say it was a pain in UIKit (for me 6 lines of code plus a delegate method), go on about how its chefs kiss in SwiftUI, but then spend the next few minutes with Marco going on about the difficulties of getting full screen to work, as he said: "there are ways around this but they are super hacky and super awful and I've tried all of them and they all had negative effects when its full screen..."

Whats going on here? It seems like everyone using SwiftUI to build apps that actually ship all say, "yeah SwiftUI is so great... when it works", like with this sheet example. It just seems like once Josh said "SwiftUI is the best way to build apps for Apple Platforms", all Apple developers went into full blown cognitive dissonance and started rationalizing or making excuses for some ridiculous issues with this framework. I just watched a WWDC Session Video on how to mitigate "accidental animations" in SwiftUI, something I've never had to worry about in my decade plus using UIKit.

Like you said, we're 5 years into this thing... whats the stop loss? Is there any pushback inside Apple? Unfortunately, we're not seeing much push back on the outside. Does Apple have data and metrics that show that SwiftUI is saving them time and reducing bugs? And if they're not measuring... then they have no clue. If you aren't measuring you have no ability to know if things are improving. From my perspective as a user, the apps are getting worse, not better; especially that new Sports scores app that I found really frustrating to use that I just ended up deleting it.

I don't think you're wrong when you say they're following Apple off a cliff if Apple doesn't straighten things out (ideally they decide to cut their losses soon before getting to the point where they realize SwiftUI is not scaling well, while all this time letting UIKit stay stagnate).

For a long time, I've observed the entire tech community act as a heard of sheep (see the classic example of the mass migration to Mastodon once the memo went out that Elon bad man now). So am I surprised that once Josh said SwiftUI is the best way to build an app for Apple's platforms that all the Apple developers fell in line? No, absolutely not. They all think and act exactly alike, never daring to offer a differing opinion, which is ironic, given all the Apple centric podcasts (which have become dreadfully boring) covering a company whose motto used to be Think Different.

> Being a long ways from Apple dev, SwiftUI seems fine, in theory. Apple's just putting too little engineering time into it, as usual

I disagree. They are putting too much engineering time into it. They are obsessed with it. So much WWDC time is dedicated to SwiftUI. Nearly half the “What’s New in AppKit” video is about integrating SwiftUI in a AppKit app.

> In the WWDC video he's acting as a corporate mouthpiece

If I can’t criticize the people making the decisions then who can I blame? Apple management seems to have very little accountability as they sit on a lead built by giants who came before them, fiddling while Rome burns.

> I often would make a Nib, drag and drop some UI in place, make a rough layout based on my sketches, then test it out. If I want to experiment more, duplicate the file and re-name it, move some things around etc.

Great. Now Trisha made a feature branch and wants you to review, but you’ve pushed your layout changes to main, so she has to rebase, and no worries, we’ll see the differences in the diff view and oh oops, no we won’t because xib is an awful format for that. It’s XML, it’s full of inscrutable internal IDs, and it has little correlation to how the layout will look visually (which you’d think XML might be useful for). Code generation is awful for version control.

SwiftUI solves that. The view is just code. If you change the HStack for a VStack, the diff will simply tell Trisha that, and she’ll be able to decide whether her added feature fits into this change, or whether to revert it.

> For a long time, I've observed the entire tech community act as a heard of sheep (see the classic example of the mass migration to Mastodon once the memo went out that Elon bad man now).

But that isn’t quite what happened, disproving your point. Some moved to Mastodon, yes. Some moved to Threads, Bluesky, post, Nostr, and so many others. Many stuck on Twitter. Some used multiple.

As for Apple developers, they’re just a segment! Web developers do things differently. Windows developers have other worries. Firmware/embedded developers do. Heck, even between iOS and Android, different choices get made. And then there’s the huge swath of people who make mobile apps but use Flutter, React Native, MAUI to do it.

What is someone who uses Apple’s stack supposed to do? Ignore their guidance? Following it isn’t being a sheep; it’s a survival skill. You either move on to a different platform or try to accommodate recommendations; everything else is going to hurt your career.

@JohnC My experience is that design iteration isn’t that great in Interface Builder. Yes, you can easily tweak view positions, but as soon as you try to restructure things, connections and localizations break. I also don’t think it ever worked very well with auto-layout. So I’ve moved off Interface Builder even though I’m using AppKit.

I am not a UIKit programmer, so I don’t know the details, but when experienced developers like Marco and Casey say that something is really hard to get right in UIKit, I assume that they know what they’re talking about, that they didn’t just miss the obvious 6-line solution. Maybe that is actually solving a different problem or maybe there are pitfalls to it when combined with other things. That said, I certainly am SwiftUI-skeptical, especially based on what I’ve seen on the Mac side.

@Sören Yes, there is certainly a huge element of seeing where the puck is going and not swimming against the tide. We saw this with the migration to Swift itself, too.

> I am not a UIKit programmer, so I don’t know the details, but when experienced developers like Marco and Casey say that something is really hard to get right in UIKit, I assume that they know what they’re talking about, that they didn’t just miss the obvious 6-line solution.

UISheetPresentationController has been around since iOS 15. It is around six lines or so, depending on how many of its properties you need to set. Then you just present the view controller. 🤷🏻‍♂️

I think that there is a lot of validity that SwiftUI is quicker for iteration. I say that as an engineer working on a 100K+ line codebase that is essentially 100% UIKit + Storyboard.

The result of this Overcase rewrite is really making wary of just going whole hog into SwiftUI.

It's making me feel like you can get the UI knocked out more easily with SwiftUI, but the ability to refine how that UI behaves is much more difficult. So if the default behavior is not working correctly, it's much trickier, b/c the framework is not built for that. With UIKit, getting a tableview/collectionView setup is slightly more tedious than SwiftUI, but having gotten over that hump, there are a lot more options for event-level adjustments.

The way the entire lists flashes and pops when I first load the "next episodes" at the beginning of the day, is really something to behold.

Again, beyond these cosmetic issues, the app is behaving just fine for me and the performance, likely due to Blackbird, is fantastic.

This is a ton of work for a solo developer, and I am confident that the vast majority of issues will get solved. I just really think there is a clear smell to the type of bugs that SwiftUI creates vs. UIKit.

> The result of this Overcase rewrite is really making wary of just going whole hog into SwiftUI. [...] Again, beyond these cosmetic issues, the app is behaving just fine for me and the performance, likely due to Blackbird, is fantastic.

I wasn't going to write this here because I do want to be kind to the developer but selecting a chapter in the "Chapter List" sheet sometimes causes the Podcast to start playing from the beginning. Sometimes it works though. I have no idea why that would be.

In UIKit creating such a bug would be a lot harder, in a typical implementation of -tableView:didSelectRowAtIndexPath:

I think SwiftUI is going to fail spectacularly. We just need someone in management to show a little courage.

@Sören, yeah it's impossible to know if a UIStackView within a Nib had its orientation changed from Horizontal to Vertical in the XML diff. It's not like the diff tool will ever highlight the addition of the axis="vertical" attribute within in green. 🤷‍♂️

I don't know what happened, but when I first started off as an Apple platform developer, no one was struggling to diff a basic text file of XML. And back then we didn't have such great tools like Kaleidoscope. I even recall when the initial iOS SDK launched, some folks were upset that Interface Builder for iOS apps wasn't ready at launch! Somewhere along the line, the herd mentality decided that Interface Builder was bad.

I also wouldn't call blindly following something a survival skill. One needs to be malleable, and be able to ride the trends. You need to know when to hit the gas on something, but also when to pump the brakes when things may be heading in the wrong direction. I didn't go "all in" on Swift in my personal projects right out of the gate. But waited, and then after the "great renaming" (whatever version that was). Thats when I started to hit the gas. Swift also had very clear benefits and many quality of life improvements too (so long block syntax). But 5 years into SwiftUI, I just can't say the same, though I do think the SwiftCharts framework is really great so far.

Both @Objc4Life and I want to see quality, well polished apps on this platform. We want the platform to be healthy, but things seem to be trending down and as a result, and thus there should be some healthy push back. How else can things improve if no one willing to point out issues. And what Apple says publicly and what they do internally can be two different things, I know I got bit jumping too soon into iCloud Core Data despite the community saying to avoid it because it was a hot mess. What happened to that technology? Never lived up to the promised and got replaced quickly despite Apple's initial promises.

@micheal I've not built an AppKit app in a long long time, so I don't know if AutoLayout is different for AppKit, but on UIKit I find AutoLayout support in Interface Builder for iOS to be fantastic. The best book on the topic is the one by Keith Harrison (useyourloaf.com/autolayout), but again this book is focused on iOS so not sure how much carries on over to AppKit. A brilliant book, but who knows, maybe a moot point now.

I think what we're seeing time and again over the past five years is that SwiftUI is great for simple apps and not great for anything of significant complexity or that has hard requirements that its cookie-cutter approach doesn't support. In short, it doesn't scale. Sure, pop it in for some of the views in your 100K lines of code app, but don't use it for the whole thing. Or build your 10K lines of code app with it, but when you get to that very tricky performance critical area you may realize you made a mistake and go back to UIKit.

That actually happened to me earlier this year. I prototyped a fairly small app that was completely built around a collection view like interface. It had extreme performance issues for doing something relatively simple in SwiftUI. I ultimately rewrote the entire app in UIKit and shipped it. No performance issues at all in the same areas and what did it cost me? Maybe a little extra code, but all-in-all a much more straightforward experience as a programmer with less gotchas or weird hard-to-debug-and-explain behaviors/performance problems.

In my opinion SwiftUI is conceptually too high level in terms of abstraction. You save a little code but pay for it in performance and loss of control. I keep trying to give it a shot over the past five years and walk away disappointed every time. I only ever shipped one very small app with it end-to-end. And I could've shipped the same app in UIKit with not much more grief. For indie developers, it's only popular because it has lowered the barrier to get started and because Apple is pushing it hard in my opinion. But it just doesn't scale. Or if it does, only with just as much grief and for no benefit over UIKit.

> yeah it's impossible to know if a UIStackView within a Nib had its orientation changed from Horizontal to Vertical in the XML diff. It's not like the diff tool will ever highlight the addition of the axis="vertical" attribute within in green. 🤷‍♂️

IME, xib/storyboard diffs are simply noisier, less semantic (_why_ did this change occur? You didn’t explicitly write it; IB did it for you) and more prone to merge conflicts than swift diffs. No fun to review in a PR.

Haven't noticed any severe bugs after upgrading yet. But I do miss easy access to the sleep timer. It's a bit annoying that it's hidden now in a sub-menu. It was much nicer to have it accessible from the main playback screen.

Sören wrote:
> IME, xib/storyboard diffs are simply noisier, less semantic (_why_ did this change occur? You didn’t explicitly write it; IB did it for you) and more prone to merge conflicts than swift diffs. No fun to review in a PR.

Generally I have not found this to be a problem as a solo dev; but if a lot of people on a dev team are touching the same xib at the same time and it's causing a lot of conflicts that are difficult to deal with, it would make sense to have a company policy set where you'd have Trisha duplicate the xib and work on a duplicate. It probably is best to treat the xib more like an image resource than source code in version control. Just change the xib name to load the duplicate while working. Treat the xib just like a bag of design data.

In theory one could (Apple) make a side by side view that would *render* the xib changes (though that would be hard to view with Storyboards).

In any case "Live Previews" are available and UIKit and Interface Builder is optional. While your gripe is valid, UIKit/AppKit/Interface Builder has proven itself and I'm not convinced that this one issue (which I would consider to be minor) is enough to justify an entire transition to SwiftUI, which clearly has lots of problems.

>I'm not convinced that this one issue (which I would consider to be minor) is enough to justify an entire transition to SwiftUI, which clearly has lots of problems.

I think it's an issue of increasing importance, with modern code review flows (pull requests, etc.).

But yes: that _alone_ is arguably not enough to justify moving to SwiftUI.

It seems to me that it would be perfectly feasible to build a xib file so that the file and its diffs are human readable. Yes, it requires not reindexing the graph's node identifiers, but frankly that's not rocket science. As it is we moved from Nibs to Xibs, so we could move to Hibs (or whatever) quite easily.

> Update […]
> I’m not sure what to make of the mixed reports, with some saying the interface is much more laggy than before and others saying that it’s much faster and smoother than before. I thought maybe it was that the actual drawing is slower but much of the work is async so that the interface isn’t blocked, but there are also reports of freezes. It does seem like Arment is working quickly to fix the bugs.

@Michael Tsai I think what we’re seeing here is that the developer has a lot of friends in the Apple media. And friends look out for each other (which is not necessarily a bad thing as long as you aren’t trying to mislead people ). And he’s a co-host of a popular podcast so there are people who like him and are willing to give him extra slack based on that. But if the replies to Gruber’s toot are any indication of how his users feel about the update…this is not good.

This will be a big moment in the history of SwiftUI I think. If he struggles to make the app stable for a really long time I’d say this may be the most severe case of the SwiftUI virus diagnosed outside of Apple. At the very least I think he put a lot of work on himself unnecessarily.

> It seems to me that it would be perfectly feasible to build a xib file so that the file and its diffs are human readable. Yes, it requires not reindexing the graph's node identifiers, but frankly that's not rocket science. As it is we moved from Nibs to Xibs, so we could move to Hibs (or whatever) quite easily.

Yes, making IB’s output friendlier to diffs should be feasible, but at the end of the day, it’s still code gen. Whether it’s VB, WYSIWYG HTML (e.g. FrontPage), NeXT/Apple IB, I find that code gen approaches to a UI lead to code a) whose purpose the developer and/or reviewer aren’t clear on, because a human didn’t write it, or 2) which isn’t necessary or needlessly verbose.

But still: as far as “should Apple invest in making xib more amenable to diffs or migrate to a format which is” goes, absolutely I’d be for that.

(The xcodeproj format has the same issue. Directory-based settings in Xcode 16 help and are a step in the right direction, but it’s still a verbose, redundant mess. Something as simple as “this project has Swift package x, and this target uses it” is ~10 lines of code spread into multiple sectors of the file. And, again, that’s got to lead to a lot of confusion and mistakes during a PR.)

> I think what we’re seeing here is that the developer has a lot of friends in the Apple media. And friends look out for each other (which is not necessarily a bad thing as long as you aren’t trying to mislead people ). And he’s a co-host of a popular podcast so there are people who like him and are willing to give him extra slack based on that.

I do think there’s a bit of a bubble with Apple podcasters, bloggers, etc.

But I also don’t think it’s quite that terrible.

I gotta say, though, the “oh, I’ll just decide your playback progress is zero. Enjoy starting over!” bug is getting on my nerves.

Version 2024.7.2, the second bugfix release, got onto my phone today. It's got a long list of fixes and additions in it after only a couple days since the previous update.

I think Marco's strategy of "release it a bit too early and let the avalanche of mixed reviews and bug reports fuel your determination to crank out bug fixes" is working out OK for him, although it'll be a bumpy ride for a couple of weeks.

I'm not seeing a fix for Sören's playback-progress bug in the .2 release notes. If that were happening to me I'd be very annoyed, to put it mildly.

> If that were happening to me

It seems to go something like

1) Overcast requests playback from iOS
2) iOS errors out / times out (during this span, about ten seconds?, the play head is stuck)
3) Overcast decides “welp, guess the actual position must be 0:00:00”

Something like, in pseudo code:

let newPosition = try? await fetchPositionFromAudioEngine() ?? Position.zero

This *may* be related to being on iOS 18 beta 3, but step 3 shouldn’t be Overcast’s conclusion regardless. It should go back to whatever position was “safe”.

@Sören SwiftUI is also “code gen”. It’s middleware that gets translated to actual UIKit/AppKit objects.

I just saw an article about the Sonos app refresh having lots of problems as well. I wonder what tech they are using.

@a

Something like:
Put all of the download episodes in a single Playlist, Select all, Share, Export All Audio Files.

This would've been heavenly.

But I assume Marco has already thought of this and rejected it, and I don't want to waste time sending an email into his ignore/Mark all as read/Delete all email "workflow".

:Kristen Bell laugh into a cry gif:

On the most recent Under the Radar, he says he just found the Overcast Reddit. I understand not wanting to reply to every email, but there's gotta be a better way to broadcast changes than Mastodon.

I'm finding I'm using Castro more. /shrug