I don't know if this is a good place for feature requests, but the only thing keeping me from switching to this at at the moment is download settings per podcast.
For example, some podcasts I don't want to miss an episode and I want them all downloaded. Other podcasts I only check in on occasionally and would only want the latest episode to be kept on device.
I subscribe to a lot of podcast and downloading and keeping every episode is going to eat up a lot of storage.
Besides that, love the simplicity of it. Well done!
Thanks! That makes a lot of sense. It actually only downloads at most 2 episodes per podcast at a time, but that's still not great for your use case. I do plan to add per-podcast settings in probably the release after next, so stay tuned for that!
I have the same requirements but started to think these use cases might be different enough to warrant different apps. So I’ve gradually shifted to those “don’t miss” ones in a dedicated podcast app and the occasional ones to Spotify. Could probably do with another app for the tiny daily ones too..
I've considered the multiple apps to manage content consumption but it's such an inelegant solution I've been unwilling to try it.
I want to be able to categorize content. I want a category of podcast to work to, work out to, go to sleep to, or to simply sit a learn. I want different categories of music. I want to be able to set a group of content on YouTube that I will watch everything on, and one that I can sort through and pick the few videos I want to watch.
Given the value of that data in just my sorting and prioritizing of content, I don't know why I don't have the tools so that data can be harvested and sold.
"Boost voices" is a cool feature a lot of apps have, but what is really needed is a "compress voices" feature. So many podcasters speak loudly 75% of the time, but then trail off randomly or almost whisper. Then you turn it up and they're projecting loudly again and blow your ears out. It's especially annoying in the car trying to compete with road noise.
Sure! I have a whole library dedicated to integrating Racket and Swift and you can find some of the nitty-gritty details there[1]. The gist of it is:
1. You build Racket for iOS in an interpreted mode (regular Racket works a bit like a JIT in that it needs to load code into memory at runtime, which is a no-go on iOS)
2. You link to it as a regular static library.
3. You call Racket's C API[2] to load and run Racket code.
Here's[3] a somewhat outdated video I did a while back on using that library for Mac app development. Many of the things in this video are now much simpler/more straightforward, but maybe it serves to give you an idea. I also have some source-available Mac apps built this way that you can take a look at[4, 5].
I support a number of podcast creators on Patreon, and apparently they’ll (at some stage) allow creators to have multiple RSS feeds. Until then, I’d love to be able to regex match on titles for download. This one creator I follow has about 6-7 different shows on the same feed, but I only listen to 2 of them.
I’ve been a Pocket Casts users since I can remember. I’ll +1 the CarPlay support that you mention was already on your list. The other, which they’ve recently introduced, is to disable Lock Screen scrubbing. Been a life saver!
Looks great though! I’ll keep an eye on the change long as it evolves.
> The other, which they’ve recently introduced, is to disable Lock Screen scrubbing
I was so happy I happened to read through their recent changelog and caught that. WAY too many times I accidentally swiped along the scrub bar and put myself at a random place in a 4 hour podcast episode and had to spend 5 minutes trying to figure out where I was.
Thanks! I used Pixelmator Pro to put the images together. I just made one long image that I cropped at the end into the screenshots you see on the App Store. For the iPhone templates, I think I exported a template from Sketch, but I later found out that Pixelmator also has them (you can find them under the Mockups category in the New dialog).
The app store labels are somewhat broad, but that refers to the error tracking that the app does. When an unhandled exception occurs in the app, that error is sent to Sentry.
Yeah, that is plainly not “no tracking”. Developers are not entitled to the events that occur on devices that belong to me unless they obtain my permission for such surveillance first.
I will never understand why developers believe that they are entitled to information from devices that they do not own.
A botched deploy that I didn't notice ended up crashing the server, which then failed to recover when the systemd unit tried to restart it (it couldn't bind the port and ran out of retries quickly) overnight, so that's why that was failing. It's back up now and I'll put a fix in today.
The app looks really good! Based on the title I thought it’d be something you made most as a testbed for Racket so I was surprised to see the app itself actually looks great :D
I tried looking through your blog but couldn’t find anything except the 40 minute YouTube video for your other app. It sounds like both the UI and the audio-related code are in Swift? What code ends up actually being in Racket then?
That's right, the UI and the Audio Engine bits are in Swift, because it's easier to interface with those Frameworks directly from Swift (and not fight the platform). Everything else (the Database management & the models, the download manager, ID3 parsing, parsing release notes, syncing with the backend server, etc.) is implemented in Racket and is portable.
> Database management
> syncing with the backend server
Do features like these, when implemented in Racket, consume more resources (battery, CPU, etc.) than if they were implemented using the native API equivalents (e.g., NSURLSession or whichever is more applicable)?
In the larger context of cross-platform apps with a common core written in a non-native programming stack, I often wonder this about network and disk I/O management. I understand using the native APIs for other "I/O" like UI, hardware interfaces (bluetooth, accelerometer, etc.), because they often don't have an
equivalent API in the programming stack used to implement the common core.
As far as I know, Capacitor wraps over the native APIs.
Ultimately, you end up calling some system API for I/O, so the only difference is how efficient the implementations of those Frameworks are compared to the embedded language's implementations. On iOS, embedding Racket requires using an interpreted mode (as opposed to Racket's usual native compilation mode), so there is a small hit, but it's not one that is really noticeable in battery or CPU consumption. In fact, Podcatcher seems to do better in battery consumption compared to the competition in my (and my friend's) testing, but I would guess that's not necessarily _because_ of Racket; it probably has more to do with how the system as a whole pays attention to perf.
That makes sense. Do you keep the in-memory data in Racket data structures? I imagine keeping the data fed to Swift UI in sync with data maintained by GC'd Racket would involve some work.
Yes, the app uses Noise under the hood, and the way to think about it is a request-response model[1]. Swift makes an async request to the Racket backend, it constructs some data (either by querying SQLite, or making a request to the backend, etc.) and returns a response. If it doesn't retain any of the data, then it gets GC'd. The ser/de is relatively low overhead -- if you try the app and go to Settings -> Support and take a look at the logs after using it a little, that should give you an idea of how long the requests take. The lines that start with `#` refer to Swift->Racket RPCs. Here's an example from my logs:
Some things on the Racket side are long running, like the download manager. It's like an actor that keeps track of what's being downloaded and the progress of each download. Whenever a download makes progress, it notifies the Swift side by making a callback from Racket->Swift. In this example, there is some duplication since both the Swift and Racket sides each have a view of the same data, but it's negligible.
What's not as great from a memory use perspective is how large Racket's baseline memory use is. Loading the Racket runtime and all the app code takes up about 180MB of RAM, but then anything the app does is marginal on top of that (unless there's a bug, of course).
[1]: I did this precisely because, as you say, keeping keeping data in sync in memory between the two languages would be very hard, especially since the Racket GC is allowed to move values in memory. A value you grab at t0 might no longer be available at t1 if the Racket VM was given a chance to run between t0 and t1, so it's better to just let Racket run in its own thread and communicate with it via pipes. Probably, the same would be true for OCaml.
- Both sides pass messages to each other. Both of them talk through C ABI. My model was synchronous though. Async is certainly better.
- I used the protobuf binary protocol for message passing. Faster and probably more efficient than, say, JSON. But both sides may have copies of the same data for this reason.
I've written down my approach, which roughly aligns with yours, in the project's README.
What I wanted to do was for OCaml side to allocate data in memory, and for Swift to access the same memory through some commonly agreed upon protocol (protobuf itself maybe?). But I haven't yet explored how difficult this could be with GC coming in play. I think OCaml does have a few tricks to tell GC to not collect objects being shared through C ABI (https://ocaml.org/manual/5.3/intfc.html#s:c-gc-harmony), but I haven't looked into this enough to be sure.
Your projects will sure help me figure out the concepts!
Nice! Yeah, using protobufs seems reasonable. Re. GC, Racket has support for "freezing" values in place to prevent the GC from moving them, but freezing too many values can impact the GC's operation so I'd watch out for that if that's possible in OCaml.
Looks cool! If I may, a couple of feature suggestions:
1. You mentioned it already but bookmarks. In particular bookmarks that can be added through iOS Shortcuts (so we can each build whatever crazy automation we need) and that can be exported (so we can keep LARPing productivity in our Obsidian vaults).
2. An "undo" function, somehow. I know this is weird but I've misclicked the seek bar so many times (esp. in the lock screen) and lost where I was... a solution for that would be so cool.
I've been using the same podcasts app for... well over 10 years. But yours looks really cool, I may just switch.
Noted! There is already an undo function, though. If you seek, an undo button pops up. Also, if you go to settings, there's a "History" view where you can also undo from.
satoshis, derivative of bitcoin I think? I have a poor understanding of it. Essentially it's a way to pay podcast producers directly. Streaming means it sends whatever you set per minute so you auto-support podcasts. Boosts are short messages with dollar values tied to it. The show has to support this though, not all podcasts do.
Yeah, based on Bitcoin lightning (which is quite different from normal bitcoin) meaning no transaction costs and very low energy use. Basically it happens off-chain until someone syncs-up (then it becomes a btc transaction). It makes payments in fractions of cents possible, ie I stream 10 sats/min which is about 60 Eur cent per minute (so 1 cent per second).
You can also send messages to creators and attach amounts (those are called boosts), so you'd send a short message and attach 10k sats (or whatever you want), which is about 10 euros/dollars.
Some podcasts I listen to use this to read messages on the show (the highest ones). It's fun and casual but remains highly technical for now, https://getalby.com/ takes away some friction (but you're still self hosing a lightning wallet using docker compose). Easiest I think is Fountain [0, 1], which has it all built in. But I never tried that, I use Castamatic [2] with Alby.
I have to say, it seems to divide the Linux podcast world a bit with some shows embracing this, and some just calling it crypto-bs. A well, people seem to enjoy it and creators get real value, enough to have to rely less on ads even. I think this is one of the babies we'd throw out if we banned crypto currencies (which I agree are 99.999% bs).
I will definitely check it out. I've never done iOS development but I have been considering doing this very thing as a way to learn and to give myself the podcast player I really want. :) Good luck!
Can it handle feeds that aren't available on the public internet?
I have a personal feed that I can connect to over TailScale. But I've found that most podcast clients have a server-side component, which means their backend server must be able to access the feed.
I tried adding my private feed to Podcatcher and am getting "Server Error (500)".
Yup, unfortunately Podcatcher works the same way and that explains why you'd be getting that error, since the server can't access your feed. That's certainly something that it could support though, but you would obviously not get any push notifications for that feed.
Thanks for the feedback. Subscribing in particular is slow, especially for podcasts with lots of episodes, because it tries to save all the episode metadata locally, to avoid roundtripping later. So, it’s slow initially so it can be fast later and work offline, but I understand how that can be annoying!
I did not use this app yet, but I want to share my issue with the current native podcast player in iOS.
Some podcasts are news related and require hearing the latest episode. Other podcasts are more serial like history narrations and require hearing the series in the order it appears. Download options should be reflective of these two functions. And "play next" should also be reflective of these two functions.
Some podcasts have fast speakers and need to be slowed down. Other podcasts have slow speakers and need to be sped up. The speed setting should be saved per podcast.
New View: A play next queue list should be present. Swipe right to play. Swipe left for other options
Condensed View: Upon expanding an episode, swipe left to see other episodes in the list ordered by date based on preference. Scroll down to see options for the episode. Scroll up to see other episodes in Queue.
Native iOS podcast player allows to customize per-podcast episode order (newest first/oldest first)
I guess playback speed is a global playback property though.
I don't know if this is a good place for feature requests, but the only thing keeping me from switching to this at at the moment is download settings per podcast.
For example, some podcasts I don't want to miss an episode and I want them all downloaded. Other podcasts I only check in on occasionally and would only want the latest episode to be kept on device.
I subscribe to a lot of podcast and downloading and keeping every episode is going to eat up a lot of storage.
Besides that, love the simplicity of it. Well done!
I don't know if this is a good place for feature requests
If you've checked out the thing being showhn enough to have a feature request, you're doing Show HN right.
Thanks! That makes a lot of sense. It actually only downloads at most 2 episodes per podcast at a time, but that's still not great for your use case. I do plan to add per-podcast settings in probably the release after next, so stay tuned for that!
I have the same requirements but started to think these use cases might be different enough to warrant different apps. So I’ve gradually shifted to those “don’t miss” ones in a dedicated podcast app and the occasional ones to Spotify. Could probably do with another app for the tiny daily ones too..
I've considered the multiple apps to manage content consumption but it's such an inelegant solution I've been unwilling to try it.
I want to be able to categorize content. I want a category of podcast to work to, work out to, go to sleep to, or to simply sit a learn. I want different categories of music. I want to be able to set a group of content on YouTube that I will watch everything on, and one that I can sort through and pick the few videos I want to watch.
Given the value of that data in just my sorting and prioritizing of content, I don't know why I don't have the tools so that data can be harvested and sold.
I think it will lead to better content.
You don't need two apps – Overcast does all of this.
"Boost voices" is a cool feature a lot of apps have, but what is really needed is a "compress voices" feature. So many podcasters speak loudly 75% of the time, but then trail off randomly or almost whisper. Then you turn it up and they're projecting loudly again and blow your ears out. It's especially annoying in the car trying to compete with road noise.
That's a great point! Shouldn't be hard to add.
For those of unfamiliar with Racket, could you go over what it takes to run a Racket app on iOS?
Sure! I have a whole library dedicated to integrating Racket and Swift and you can find some of the nitty-gritty details there[1]. The gist of it is:
1. You build Racket for iOS in an interpreted mode (regular Racket works a bit like a JIT in that it needs to load code into memory at runtime, which is a no-go on iOS)
2. You link to it as a regular static library.
3. You call Racket's C API[2] to load and run Racket code.
Here's[3] a somewhat outdated video I did a while back on using that library for Mac app development. Many of the things in this video are now much simpler/more straightforward, but maybe it serves to give you an idea. I also have some source-available Mac apps built this way that you can take a look at[4, 5].
[1]: https://github.com/Bogdanp/Noise?tab=readme-ov-file#usage
[2]: https://docs.racket-lang.org/inside/cs.html
[3]: https://www.youtube.com/watch?v=aTvU0j4hBR0
[4]: https://github.com/Bogdanp/remember
[5]: https://github.com/Bogdanp/Franz
I'd love to know as well - I found some documentation on the Racket site, but I'm not entirely sure what I'm looking at here.
https://docs.racket-lang.org/inside/ios-cross-compilation.ht...
I support a number of podcast creators on Patreon, and apparently they’ll (at some stage) allow creators to have multiple RSS feeds. Until then, I’d love to be able to regex match on titles for download. This one creator I follow has about 6-7 different shows on the same feed, but I only listen to 2 of them.
I’ve been a Pocket Casts users since I can remember. I’ll +1 the CarPlay support that you mention was already on your list. The other, which they’ve recently introduced, is to disable Lock Screen scrubbing. Been a life saver!
Looks great though! I’ll keep an eye on the change long as it evolves.
> The other, which they’ve recently introduced, is to disable Lock Screen scrubbing
I was so happy I happened to read through their recent changelog and caught that. WAY too many times I accidentally swiped along the scrub bar and put myself at a random place in a 4 hour podcast episode and had to spend 5 minutes trying to figure out where I was.
Wow! I have searched for the feature in the settings so many times after losing my spot in a long podcast. Thank you for pointing that out!
I have the same problem with Patreon feeds -- I use [siftrss][1] to manage this for now. Though it's slightly hacky, it works!
[1]: https://siftrss.com/
Just want to say, I love the design of your website!
Thanks! It's built with Chakra UI[1] so I can't take full credit for it.
EDIT: Oh, I just realized you might be referring to my blog, in which case I _can_ take credit for that :P. Thanks again!
[1]: https://www.chakra-ui.com/
Is that font Valkyrie on your blog?
Yep, it's one of Matthew Butterick's fonts[1].
[1]: https://mbtype.com/fonts/valkyrie/
yeah, really good looking page, congrats! btw - out of curiosity - what tool did you use to create app screenshots for AppStore?
Thanks! I used Pixelmator Pro to put the images together. I just made one long image that I cropped at the end into the screenshots you see on the App Store. For the iPhone templates, I think I exported a template from Sketch, but I later found out that Pixelmator also has them (you can find them under the Mockups category in the New dialog).
> It's also free, has no ads or tracking, and it's local-first except for the podcast directory and sync.
The app privacy label says it tracks diagnostics.
The app store labels are somewhat broad, but that refers to the error tracking that the app does. When an unhandled exception occurs in the app, that error is sent to Sentry.
Yeah, that is plainly not “no tracking”. Developers are not entitled to the events that occur on devices that belong to me unless they obtain my permission for such surveillance first.
I will never understand why developers believe that they are entitled to information from devices that they do not own.
Well done; will test and possibly switch. But, for me more importantly, using Racket for this is more really nice. Thanks for that.
I’m getting an error going to the Discover tab and also when hitting “search” after typing a search term (newlines added):
A botched deploy that I didn't notice ended up crashing the server, which then failed to recover when the systemd unit tried to restart it (it couldn't bind the port and ran out of retries quickly) overnight, so that's why that was failing. It's back up now and I'll put a fix in today.
Went looking for the source, but when following a link to podcatcher.net, Cloudflare is saying the podcatcher.net backend is “502 Bad Gateway”ing.
edit: oh right,
> I am still debating whether or not I want to make the app itself source available, like I've done for Franz and Remember. Maybe if there's interest.
The app looks really good! Based on the title I thought it’d be something you made most as a testbed for Racket so I was surprised to see the app itself actually looks great :D
I tried looking through your blog but couldn’t find anything except the 40 minute YouTube video for your other app. It sounds like both the UI and the audio-related code are in Swift? What code ends up actually being in Racket then?
That's right, the UI and the Audio Engine bits are in Swift, because it's easier to interface with those Frameworks directly from Swift (and not fight the platform). Everything else (the Database management & the models, the download manager, ID3 parsing, parsing release notes, syncing with the backend server, etc.) is implemented in Racket and is portable.
> Database management > syncing with the backend server
Do features like these, when implemented in Racket, consume more resources (battery, CPU, etc.) than if they were implemented using the native API equivalents (e.g., NSURLSession or whichever is more applicable)?
In the larger context of cross-platform apps with a common core written in a non-native programming stack, I often wonder this about network and disk I/O management. I understand using the native APIs for other "I/O" like UI, hardware interfaces (bluetooth, accelerometer, etc.), because they often don't have an equivalent API in the programming stack used to implement the common core.
As far as I know, Capacitor wraps over the native APIs.
Ultimately, you end up calling some system API for I/O, so the only difference is how efficient the implementations of those Frameworks are compared to the embedded language's implementations. On iOS, embedding Racket requires using an interpreted mode (as opposed to Racket's usual native compilation mode), so there is a small hit, but it's not one that is really noticeable in battery or CPU consumption. In fact, Podcatcher seems to do better in battery consumption compared to the competition in my (and my friend's) testing, but I would guess that's not necessarily _because_ of Racket; it probably has more to do with how the system as a whole pays attention to perf.
That makes sense. Do you keep the in-memory data in Racket data structures? I imagine keeping the data fed to Swift UI in sync with data maintained by GC'd Racket would involve some work.
Have you used https://github.com/Bogdanp/Noise? I assume serde would take up memory on both sides (Racket and Swift).
Sorry for a barrage of questions. I am quite curious about how all of this works. I am mulling over using OCaml for what you've used Racket for.
No worries! I like talking about this stuff.
Yes, the app uses Noise under the hood, and the way to think about it is a request-response model[1]. Swift makes an async request to the Racket backend, it constructs some data (either by querying SQLite, or making a request to the backend, etc.) and returns a response. If it doesn't retain any of the data, then it gets GC'd. The ser/de is relatively low overhead -- if you try the app and go to Settings -> Support and take a look at the logs after using it a little, that should give you an idea of how long the requests take. The lines that start with `#` refer to Swift->Racket RPCs. Here's an example from my logs:
Some things on the Racket side are long running, like the download manager. It's like an actor that keeps track of what's being downloaded and the progress of each download. Whenever a download makes progress, it notifies the Swift side by making a callback from Racket->Swift. In this example, there is some duplication since both the Swift and Racket sides each have a view of the same data, but it's negligible.What's not as great from a memory use perspective is how large Racket's baseline memory use is. Loading the Racket runtime and all the app code takes up about 180MB of RAM, but then anything the app does is marginal on top of that (unless there's a bug, of course).
[1]: I did this precisely because, as you say, keeping keeping data in sync in memory between the two languages would be very hard, especially since the Racket GC is allowed to move values in memory. A value you grab at t0 might no longer be available at t1 if the Racket VM was given a chance to run between t0 and t1, so it's better to just let Racket run in its own thread and communicate with it via pipes. Probably, the same would be true for OCaml.
Thank you!
In my PoC (https://github.com/jbhoot/poc-ocaml-logic-native-ui) - a tiny hello world CLI on macOS, that has a Swift "frontend" and OCaml "backend" - I followed a similar model:
- Both sides pass messages to each other. Both of them talk through C ABI. My model was synchronous though. Async is certainly better. - I used the protobuf binary protocol for message passing. Faster and probably more efficient than, say, JSON. But both sides may have copies of the same data for this reason.
I've written down my approach, which roughly aligns with yours, in the project's README.
What I wanted to do was for OCaml side to allocate data in memory, and for Swift to access the same memory through some commonly agreed upon protocol (protobuf itself maybe?). But I haven't yet explored how difficult this could be with GC coming in play. I think OCaml does have a few tricks to tell GC to not collect objects being shared through C ABI (https://ocaml.org/manual/5.3/intfc.html#s:c-gc-harmony), but I haven't looked into this enough to be sure.
Your projects will sure help me figure out the concepts!
Nice! Yeah, using protobufs seems reasonable. Re. GC, Racket has support for "freezing" values in place to prevent the GC from moving them, but freezing too many values can impact the GC's operation so I'd watch out for that if that's possible in OCaml.
Makes sense. Thanks for the tip!
Thanks for the reply! That makes a lot of sense.
Racket has been on my bucket list of languages to learn. Seems really intriguing
This is great! I just switched over from Overcast. Very nice and simple interface, no clutter, and not a ton of unnecessary features. Love it.
Looks cool! If I may, a couple of feature suggestions:
1. You mentioned it already but bookmarks. In particular bookmarks that can be added through iOS Shortcuts (so we can each build whatever crazy automation we need) and that can be exported (so we can keep LARPing productivity in our Obsidian vaults).
2. An "undo" function, somehow. I know this is weird but I've misclicked the seek bar so many times (esp. in the lock screen) and lost where I was... a solution for that would be so cool.
I've been using the same podcasts app for... well over 10 years. But yours looks really cool, I may just switch.
Noted! There is already an undo function, though. If you seek, an undo button pops up. Also, if you go to settings, there's a "History" view where you can also undo from.
Any plans to implement podcast 2.0 features like boosts or sat streaming?
I streams sats to creators but also to the podcast app. I wonder what an app like Castamatic or Podverse or Fountain makes…
Sats?
satoshis, derivative of bitcoin I think? I have a poor understanding of it. Essentially it's a way to pay podcast producers directly. Streaming means it sends whatever you set per minute so you auto-support podcasts. Boosts are short messages with dollar values tied to it. The show has to support this though, not all podcasts do.
So it's a podcast client with cryptocurrency wallet functionality?
Yeah, based on Bitcoin lightning (which is quite different from normal bitcoin) meaning no transaction costs and very low energy use. Basically it happens off-chain until someone syncs-up (then it becomes a btc transaction). It makes payments in fractions of cents possible, ie I stream 10 sats/min which is about 60 Eur cent per minute (so 1 cent per second).
You can also send messages to creators and attach amounts (those are called boosts), so you'd send a short message and attach 10k sats (or whatever you want), which is about 10 euros/dollars.
Some podcasts I listen to use this to read messages on the show (the highest ones). It's fun and casual but remains highly technical for now, https://getalby.com/ takes away some friction (but you're still self hosing a lightning wallet using docker compose). Easiest I think is Fountain [0, 1], which has it all built in. But I never tried that, I use Castamatic [2] with Alby.
I have to say, it seems to divide the Linux podcast world a bit with some shows embracing this, and some just calling it crypto-bs. A well, people seem to enjoy it and creators get real value, enough to have to rely less on ads even. I think this is one of the babies we'd throw out if we banned crypto currencies (which I agree are 99.999% bs).
[0] https://apps.apple.com/us/app/fountain-podcast-player/id1576...
[1] https://play.google.com/store/apps/details?id=fm.fountain.ap...
[2] https://apps.apple.com/us/app/castamatic-podcast-player/id96...
I will definitely check it out. I've never done iOS development but I have been considering doing this very thing as a way to learn and to give myself the podcast player I really want. :) Good luck!
Can it handle feeds that aren't available on the public internet?
I have a personal feed that I can connect to over TailScale. But I've found that most podcast clients have a server-side component, which means their backend server must be able to access the feed.
I tried adding my private feed to Podcatcher and am getting "Server Error (500)".
Yup, unfortunately Podcatcher works the same way and that explains why you'd be getting that error, since the server can't access your feed. That's certainly something that it could support though, but you would obviously not get any push notifications for that feed.
Cool thanks! (I also realized I'm not the only one who loves listening to podcasts during the shower eheh)
Where does one learn how to interface with the podcast directories? Who provides free downloads? I had heard something about rss at one point.
Couldn’t find a good app for phosh and was thinking of writing one.
Every podcast has its own RSS feed. As for the index, I use Podcast Index[1] and the iTunes API.
[1]: https://podcastindex.org/
Check out this, it might help you with downloading podcasts to the filesystem: https://news.ycombinator.com/item?id=42841416
Four things that matter to me in a podcast app
- Privacy
- OPML support
- Ability to import from Apple Podcast
- Dark theme
Good job! If you need episode search, check out PodcastAPI.com
Really cool! Now if you can make an osX version, and also add the radios like "Receiver Radio" it would be perfect :)
Looks very nice.
I see Windbreaker Podcast featured in those screenshots on the App Store listing. A Z̶e̶r̶o̶ ̶P̶u̶n̶c̶t̶u̶a̶t̶i̶o̶n̶ Fully Ramblomatic fan?
Yep!
Yahtzee is one of my favorite writers. I need to get back into the last couple books of his I haven't read.
Bug report: go to Discover, serach for Mike Duncan, tap on Revolutions, exception pops up
Thanks! I'm not able to reproduce this on my end, but if you send me the exception (here or via e-mail), I'd be happy to take another look!
Hmmm it didn’t work yesterday but I didn’t take a screenshot. Works today! Guess it was a network issue
Not usable at all on iOS 18.2. Error popup when try to add any podcast.
Doesn't work! Clicking discover just shows a messagebox with a stack trace[1] - so I have no way of adding a podcast to try out the app.
[1] Error string::1: bytes->jsexpr: bad input starting #"error code: 502" context..: .../syntax/readerr.rkt:15:2: -raise- read-error ../private/arrow-val-first.rkt:486:18 .../private/backend.rkt:45:9: get-trending-podcasts .../noise-serde-lib/backend.rkt:69:22
Sorry about that! Looks like the server got OOMKilled at one point and failed to recover. It should be back up now and I'll work on a fix.
feedback: it's slow (clicking on subscribe, etc)
Thanks for the feedback. Subscribing in particular is slow, especially for podcasts with lots of episodes, because it tries to save all the episode metadata locally, to avoid roundtripping later. So, it’s slow initially so it can be fast later and work offline, but I understand how that can be annoying!
Does it work with CarPlay?
Not yet, but it's on the list!
i cant download it? cant find it
kudos well done! looks really cool
I did not use this app yet, but I want to share my issue with the current native podcast player in iOS.
Some podcasts are news related and require hearing the latest episode. Other podcasts are more serial like history narrations and require hearing the series in the order it appears. Download options should be reflective of these two functions. And "play next" should also be reflective of these two functions.
Some podcasts have fast speakers and need to be slowed down. Other podcasts have slow speakers and need to be sped up. The speed setting should be saved per podcast.
New View: A play next queue list should be present. Swipe right to play. Swipe left for other options
Condensed View: Upon expanding an episode, swipe left to see other episodes in the list ordered by date based on preference. Scroll down to see options for the episode. Scroll up to see other episodes in Queue.
Native iOS podcast player allows to customize per-podcast episode order (newest first/oldest first) I guess playback speed is a global playback property though.