This is the third of my yearly roadmap blog posts. You can find the last year’s post here.

Looking back

2020 was a complicated year for everyone, but I still managed to release 16 updates for Fiery Feeds iOS and macOS in total.

Mac Trial

It was the first thing on my list for 2020, and you can download it here: Fiery Feeds Trial

Full Text Search

Search everywhere. Full text search for articles. Search for settings, including otherwise hidden expert settings.

Also in version 2.4 a simple implementation of saved searches. It’s not yet the advanced iTunes smart playlist style saved searches, but a lot of things required are now in place for this to happen.

Native Article View

I’m still working on the native article renderer and fixing some edge cases here and there, but it is officially an option, and will become the default renderer in the next major update.

Performance

There were some performance fixes since 2.4 has been released and I am currently working on a few different more, as well as general code cleanup. Those changes will be part of the coming 2.4.x updates, that is, I want all of the known bottlenecks fixed before I start on the next feature release.

Planned 2021

The major features I’m planning to work on this year, roughly sorted by priority. As always, this is just a rough plan, not a guarantee that I’ll actually manage to implement all of them.

New Widget

iOS 14 and Big Sure brought support for new SwiftUI based widgets. Fiery Feeds already has a today widget, but the new widgets, while more limited in features, can be put on the Home Screen, which people seem to enjoy. I have some ideas for different kinds of widgets I want to support, but I do have to learn SwiftUI first, which feels like a big thing (most of Fiery Feeds is still Objective-C). Still, this is something for version 2.5.

New Services

Miniflux, Raindrop, Feeder.io, full FreshRSS (including feed management, i.e. using their Google Reader API) support. There’s a lot to do on the syncing side, even if it doesn’t sound like exciting new features.

Theming Improvements

A better (read native, instead of a website) in-app browser for themes, an in-app theme editor and a user directory of themes where anyone can submit their own creations.

General Design Refresh

While I don’t want to completely redesign Fiery Feeds, I do want to bring it a bit closer to the look of iOS 14 and Big Sur.

Also the new OS versions brought support for a lot of things I want to use. Native sidebar, native 3-pane-mode, the new window toolbar on macOS, more use of SF Symbols,… you get the idea. Some of those do require iOS 14/Big Sur as target, that means I’m going to release this after the next iOS/macOS versions are available so I can keep supporting to my usual current + 1 OS versions.

Drag and Drop / Multi Selection

One of the more macOS centered improvements. Selecting multiple article to mark read or tag at once, or simply dragging feeds / articles to folders / tags to assign them is something I’d expect from a Mac app. I’ve caught myself trying to do this and getting annoyed that it doesn’t work multiple times. Interestingly I’ve never missed those features on iOS – I still plan on supporting it on both platforms.

I think this is going to fit well with the updated design, since I have to completely re-do at least the feeds and folders list anyway.

Advanced Saved Searches

Like I said above, the foundation is already in place, but I still need to build the UI to create more complex saved searches. I like iTunes’ UI for smart playlists, and I hope that Smart Searches will end up looking and working like that.

Per Feed Settings

Over the time people have asked for different settings they want only on a per feed basis, not for the entire app. Showing Preview Images for example, or notifications only for specific feeds. Alongside that I also want to support automatically marked articles read after a certain time (for specific feeds), and some more.
Those will be ‘override’ settings, that is, if you never look into the feed settings view, the app should continue to behave exactly as it does today.

Fiery Feeds for Mac offers the same customisability as you’re used to. It’s build using Catalyst and on the same code base as the iOS version. I’ve written some more about it here.

It offers the same customisability as you’re used to in the iOS version, including multiple article list styles, custom themes, custom URL and Email actions, iCloud synchronisation, smart views, automatic full text extraction and all the rest.

The system wide action extension to subscribe or read later is coming in one of the next updates. It’s already working in my development builds, but I haven’t managed to convince the App Store servers to accept uploads with the extensions embedded. Let’s see if that changes after the official Catalina release, wouldn’t be the first time that the App Store isn’t quite up to date.

The new Bionic Reading feature from version 2.3 is also available on the Mac.

Pricing

I’ve thought long about how to price the Mac version. The most obvious option would be to make it part of the subscription that already exists on iOS, but this comes with some technical issues. The Mac and the iOS/iPadOS apps are two separate apps on the App Store (since universal apps between iOS and Mac are not supported). Apple allows syncing the subscription between separate apps, but doesn’t provide any help in doing so.

Right now there is only a single subscription (group) available in Fiery Feeds. That means, no matter what, a single Apple ID can not subscribe more than once. If I wanted to do subscription syncing, I’d have to at least offer a separate (because it’s separate app) subscription in the Mac app (for people who do not use the iOS app), which means users might subscribe twice by accident (if they didn’t follow the steps to synchronise the subscription from the iOS app exactly step by step). Together, with the fact that I can’t refund subscriptions (or purchases) even if I wanted to, that sounds like a support nightmare in the making. So a shared subscription is out, at least until it’s properly supported by the App Store.

Generally requiring a second subscription for the Mac app for everyone… feels just wrong. So that’s out too.

That leaves me with probably the most straightforward option. Fiery Feeds for Mac will be a single, paid upfront, onetime purchase, as Mac apps have been for a long time. It’s going to be $35 and I expect to support it with new updates and features for the next 3-5 years, before doing some sort of paid upgrade, be that a move to a subscription (if supported by Apple), or another paid version.

You can find Fiery Feeds on the Mac App Store.

Multi Timers 2.4 was just released with full support for iOS 10.

screen696x696img_1905

The today widget is now adapted to the new design in iOS 10, and you can restart or stop timers right from the widget without launching the app. Additionally you can now launch the app right into editing a timer from the widget.

Support for Siri: Just say “Start ” or “Stop ” to – you guessed it – start or stop a specific timer.

The Apple watch app now supports watchOS 3, and works as a standalone app. You can add, remove and edit all timers right on your watch.

Fiery Feeds Text Mode

Fiery Feeds 1.7 introduced the three article view modes Article, Web and Text. Where Article displays the article as contained in the RSS feed 1 and Web simply displays the linked website directly in the article view, the Text mode is a little more complicated.

There are three providers for Fiery Feed’s text mode. First there is readability, which uses Readability publicly available mobiliser 2 and might break whenever Readability changes their output or ends support for it 3.

The other two options are “Formatted” and “Text Only”. Both are open source scripts running on a server provided by Fiery Feeds 4. The Text Only more can parse articles more reliably, but does not include any images or other elements like lists.

The thing with providing a service like this is that a server costs money every month, while selling the app brings in revenue just once. That is why Fiery Feeds now also includes the option to become a patron and support both the ongoing development and my ability to provide services like text extraction. 5.

If you enjoy Fiery Feeds, please do become a patron. Thank you.

Multitimers 2.3 improves the today widget and adds full support for x-callback-urls. You can download Multitimers here

Actions

addTimer

multitimers://addTimer?sec&min&hr&d&title&tone

Needs to include at least one of the following parameters. The timer duration is the sum of all

  • sec: (Int) Seconds of the timer duration
  • min: (Int) Minutes of the timer duration
  • hr: (Int) Hours of the timer duration
  • d: (Int) Days of the timer duration

Additionally you can specify the following:

  • title: (Text) Title of the timer
  • tone: (Int, 0-3) Index of the alert tone

deleteTimer

multitimers://deleteTimer?id&title&index

Needs to include one of the following parameters:

  • id: (Text) UUID of the timer to delete, used by the today widget
  • title: (Text) title of the timer to delete
  • index: (Int) index of the timer to delete

restartTimer

multitimers://restartTimer?id&title&index

Needs to include one of the following parameters:

  • id: (Text) UUID of the timer to restart, used by the today widget
  • title: (Text) title of the timer to restart
  • index: (Int) index of the timer to restart

stopTimer

multitimers://stopTimer?id&title&index

Needs to include one of the following parameters:

  • id: (Text) UUID of the timer to stop, used by the today widget
  • title: (Text) title of the timer to stop
  • index: (Int) index of the timer to stop

x-callback-urls

multitimers://x-callback-url/addTimer?sec&min&hr&d&title&tone&x-success&x-error
multitimers://x-callback-url/deleteTimer?id&title&index&x-success&x-error
multitimers://x-callback-url/restartTimer?id&title&index&x-success&x-error
multitimers://x-callback-url/stopTimer?id&title&index&x-success&x-error

You can also supply these additional parameters

  • x-success (URL) URL to be called after successfully completing the action
  • x-error: (URL) URL to be called after an error