Fig Brings iOS Push Notifications to Discourse Forums
We rely on the Discourse discussion system for comments on TidBITS articles and for the TidBITS Talk discussions. Discourse has become popular over the past decade, and it’s used by an ever-increasing number of sites, including (to name a few you may recognize) the note-taking app Agenda (which integrates its forum within the app), the Chrome-derived browser Brave, the information management app DEVONthink, the must-have automation utility Keyboard Maestro, camera-maker Wyze, and virtual fitness company Zwift.
At the start of the year, I also set up a Discourse forum for the local Finger Lakes Runners Club to replace a crufty decades-old mailing list run in Mailman. One of my goals in switching to Discourse was to provide a self-hosted alternative to a variety of Facebook groups that were fragmenting the local running community. I consider Facebook to be a cancerous growth on the global Internet, and I wanted to ensure that the club’s discussion forum wouldn’t end up at the mercy of a soulless and ethically bankrupt megacorp.
But Facebook does one thing notably better than Discourse—its mobile apps provide push notifications, which was often helpful for coordination when people were a little late to a group run, for instance. Although Discourse uses a responsive Web design that degrades to small mobile screens well and even offers iOS and Android apps, those apps are basically Web views and don’t support push notifications for self-hosted sites. (I don’t begrudge Discourse’s developer, Civilized Discourse Construction Kit, the fees for hosted sites that do get push notifications, but when comparing $100 per month for a hosted site to the $12 per month we pay for our installation on Digital Ocean, I have to go with the self-hosted option.)
I hadn’t realized the notification limitation when I installed Discourse for the club, so I was quite pleased when I recently learned about Fig, a new iOS app that offers its own interface for Discourse and provides full notification support. Fig boasts native iPhone and iPad interfaces, helps you find new Discourse-based communities, and brings all your Discourse discussions into a single spot.
Fig is free with in-app purchases that largely amount to supporting the app. With them, you get unlimited communities, unlimited posts, access to private communities, and free alternative app icons, but I haven’t yet run into any of the limitations that would require the $14.99 per year subscription. The big win for the subscription is probably access to private Discourse communities.
On an iPad, Fig provides full multitasking support, so you can open Discourse in Slide Over, where it takes on the iPhone look. Or you can use it in Split View, either with another app or with multiple Fig views such that you can easily refer to a topic in one view while composing in another.
With two forums where I have to read every message (TidBITS Talk and FLRC), I don’t have extra time to look for or participate in many more Discourse communities. Nonetheless, in its Discover screen, Fig catalogs over 7500 forums on a wide variety of topics, including arts and entertainment, development languages, education, finance and cryptocurrency, makers, and numerous products. And yes, you can find TidBITS Talk there.
Subscribing to a forum—which means adding it to the list of communities that Fig tracks—is as simple as tapping Subscribe while previewing the forum or tapping the + button next to its name in a search. If you want to add a forum directly, there’s a + button in the Topics screen that lets you enter the URL for any Discourse-based community. If you accidentally add a forum you don’t want to keep around, press and hold on its name in the Communities list on the Topics screen to bring up controls for moving (within the list) or deleting the forum.
All changes you make are synced to your other devices running Fig, presumably through iCloud, since you don’t need a special account for Fig itself.
For browsing forums that you haven’t joined yet, start at the Topics screen. It starts with a list of Communities—the forums to which you’ve subscribed in Fig—and a tap on one displays its main screen, which is likely either the latest topics or a list of categories. You can view the forum by those, or by top topics, new topics, unread topics, or bookmarks by tapping the View By button.
One tip that you might find useful: pull down on any topics list to reveal a search field that lets you search across all posts in the forum.
Regardless, once you tap a topic title, you see the full discussion, either in the main pane on the iPad or taking over the screen on an iPhone. Fig even shows Discourse’s familiar blue dots to indicate the number of unread posts in a topic and properly scrolls you to unread posts in a topic if you’ve visited before.
To collect all your Discourse-based discussions into one place, Fig provides the Inbox screen, which works much like the Inbox in Mail. Each forum that you’re logged into gets its own inbox, so you can focus on what’s new there, or you can use All Inboxes to see what’s new across all your communities. What appears here is up to you—the inboxes show your notifications much like the menu that appears when you click your avatar in the upper-right corner of any Discourse forum’s Web interface. More on notifications in a bit.
Once you’re reading posts in a topic, things work pretty much as you’d expect from Discourse. You have infinite scrolling through all the posts, with more loading at the bottom as necessary. Fig displays who has replied to what and when, and you can like (with the heart button), bookmark, share, or reply to a post with buttons at the bottom of each one. A ••• button provides access to hidden toolbar buttons and notification controls, and for those of us who are admins, the capability to edit or delete posts.
The only place I’ve found that Fig falls down somewhat is in its post composer. To be fair, Discourse’s native Web composer is brilliant, making it easy to quote small bits from previous posts merely by selecting them and clicking a Quote button that appears nearby, and offering clean, Markdown-based styling of text. It even provides a live preview off to the right, which is especially helpful when you insert links (which get summary “oneboxes”), images, and special things like custom date ranges and polls.
Fig makes a valiant effort at supporting everything Discourse can do, but most notably, when you select text and tap a Quote & Reply button, you get a dialog telling you the feature is under construction. Luckily, it’s not a complete deal-breaker because you can always copy the text instead, start your reply, and use the Quote button (or just type >) before pasting the text to quote it. There is no live preview, even on the iPad, but you can always tap the Preview button to see what your post will look like.
Everything I’ve said so far supports the contention that Fig is a full-featured Discourse client for the iPhone and iPad. But since the free DiscourseHub app for iPhone does much of the same, including the Quote button when composing, what about Fig’s raison d’ être: push notifications?
Put bluntly, they just work, thanks to Fig being a native app. In the Topics screen, tap the gear icon at the top to bring up Fig’s Settings screen, and then tap Notifications. For each of your logged-in forums, you can enable or disable notifications. When they’re enabled, Fig displays notifications with brief excerpts, just like any other app, and if you want, they can even flow through to your Apple Watch. Tapping one opens it in Fig, as you’d expect.
That does raise the question of exactly what Fig will notify you of. The short answer is that Fig simply passes Discourse’s notifications off to the system-wide iOS notification system. For a more complete answer, you need to understand how Discourse notifications work. For every category or topic, you can choose (click the bell icon at the top for a category or at the bottom for a topic) from four notification levels:
- Watching: You’re notified of all new posts.
- Watching First Post: You’re notified of the first post in every new topic.
- Tracking: You’re notified if someone mentions your @name or replies to one of your posts.
- Normal: For the purposes of Fig notifications, Normal is effectively the same as Tracking.
It can get more complicated. If you reply to a post, you’re automatically set to Tracking for its topic. And, of course, if someone sends you a private message, Discourse notifies you of that too. Happily, the default end result is usually what you want. If it’s not, you can tweak all the settings in the Notifications screen of any Discourse forum’s preferences.
To summarize then, given that it has to compete with Discourse’s own Web-based apps, Fig does a good job of providing features that go above and beyond replicating the browser experience. They include:
- A native iOS/iPadOS user experience with support for multitasking and dynamic type
- A browsable, searchable catalog of thousands of Discourse communities
- Push notifications for anything that generates a Discourse notification
- A unified inbox that brings together all your notifications from multiple forums
- Nearly full-fledged support for composing message content, with improvements coming
Fig is essential for anyone who wants push notifications on their iPhone or iPad—nothing else can provide that. It’s also worthwhile for anyone who wants an elegant interface for participating in multiple Discourse forums from a mobile device. And it’s free, so it’s easy to give it a try and see if it fits into your preferred strategy for participating in online conversations.
This is very nice, but does anybody know if push notifications for iOS browsers will be a thing in iOS 14? If not, is it a feature that Apple is principially opposed to?
I don’t believe (nor have I noticed) any change in iOS 14 with regard to Web push notifications. I suspect Apple is opposed them on the grounds that such a feature should be limited to apps, perhaps because Apple limits what app notifications can do in some way that affects privacy or security. But that’s just a guess.
Far more likely because it would hurt their bottom line. If it’s really privacy or security related, then the fact that they let it happen on the Mac means they are not protecting privacy or security on the Mac.
If web apps were allowed to be full-featured, many companies that feel it necessary to have an app in the Apple app store wouldn’t feel the need anymore. Apple makes money by preventing people from seamlessly switching to Android. Native apps as opposed to web apps help prevent that. Apple makes money from apps being on their store. Web apps would allow people to bypass Apple to charge for app features. Apple even makes money from developers and companies paying their annual dev fee. Fewer people and companies would need to pay that if they could just use web apps.
I don’t mean to imply that native apps aren’t superior in some ways or that the ideal would just be web apps. I just mean that Apple has a huge vested interest in hamstringing web apps, and they have been doing so for years.
Push notifications are important for mobile devices, but much less so for desktop/laptop systems.
Why?
On a desktop/laptop system, it’s no big deal for an application to open a TCP socket and keep it open for an extended period of time. A remote service can write data to the socket at any time and the system of IP hosts, servers and routers that comprise the Internet will ensure that the data is reliably delivered to its destination.
On a mobile device, this is a very bad way to design an application. In order to maintain a TCP connection over an extended period of time, the device pretty much can’t go to sleep. One of two things will happen. The app will manage to keep the device awake and with its network hardware operating, resulting in high power consumption and reduced battery life. Or the operating system will force the app to sleep, causing the TCP connection to timeout - and data won’t flow if the socket is closed.
A workaround might be to switch from a “push” to a “pull” model where the app periodically connects to a remote server to see if anything happened. This works, but it wastes CPU cycles and battery if there is rarely any data to read. And if a lot of apps are doing this at once, it will keep the network hardware running constantly, resulting in battery drain.
And both of the above solutions can waste data (running up a customer’s bill) when connected to a metered network (like most cellular systems).
Apple’s push notification system is designed to avoid these problems. Notifications reside on an Apple server somewhere. That server collects notifications intended for a user and bulk-alerts apps about the data using a single message. I seem to remember reading that it uses the text messaging system internally where possible, in order to take advantage of the fact that the cellular modems in phones are already maintaining a persistent connection to the phone network, so it won’t create a significant additional power drain.
Anyway, this bulk delivery mechanism allows the Apple server to send one message to one system process. This process can then bulk-read the notifications from the server, cache them locally, and deliver them to their respective apps at appropriate times (e.g. when they’re not asleep).
It’s a great system, and its one that allows modern smart phones to work efficiently, given their extreme power and network limitations. But on a desktop/laptop computer where batteries are much bigger, AC power is often available, and network bandwidth (Ethernet or Wi-Fi) is usually plentiful (if not unlimited), it’s harder to make the argument that all the added complexity is necessary.
So the modern Android phones that have excellent battery life without crippling the browser are using witchcraft?
Wrong.
Why the hostile-sounding response?
I never said a thing about Android. I never said Apple was the only company to have solved this problem. And I never said my understanding of Apple’s solution is the only possible way to solve the problem.
Based on the (extremely limited) description in the article you liked to, it looks like Google’s solution is doing something very similar to Apple’s - they are also forcing all notifications to arrive through a single common system process, which in turn dispatches it to applications only when the app is awake to receive them (possibly as a result of user interaction with the popup notification object)
The question is why doesn’t Apple allow notifications in web apps. I have an opinion. I think the answer is money. You presumably have an opinion, too. I thought I knew what it was. I thought your answer was “to improve battery life.” Apparently I was wrong.
At any rate, battery life is not a reasonable answer to the question.
I wasn’t talking about web apps at all, but in terms of native apps running on desktop systems. But since that’s what you really care about, here’s my thought on the matter, which is only tangentially related to Apple.
Implementing push notification for web apps has one serious problem - it needs to be cross-platform. You can’t require a web server to use one notification API for Apple devices and another for Android. You therefore can’t require the use of any kind of central notification-delivery server. You also can’t leverage the cell phone network, because the app needs to work on desktop systems and Wi-Fi-only mobile devices.
The Google link you shared is very short on details about how they solve this problem, assuming they did. I suspect they require use of a Google API that shunts everything through a single Google-hosted server pool whose identity is well-known and built-in to Android. This may be fine for Google supporting their own web apps, but it clearly can’t work as a web standard.
In general, Apple has been very strict about conforming to web standards. There are many cases over the last 20 years where Apple has deliberately chosen to not include popular browser features because they are not standards (e.g. proprietary features from Microsoft, Google or Netscape/Mozilla). My personal suspicion is that push notifications for web apps is one of these.
There is an IETF RFC for push notification on web pages, but it is based on a draft W3C API that has not yet been approved as a standard.
The IETF solution requires establishment of push servers that can act as a broker for notification delivery to browsers, much like what I described with respect to native apps.
But this approach doesn’t scale well. A standards body like the IETF or W3C is not going to mandate a single server (or pool of servers) for the entire Internet. They are (correctly) going to allow any number of service providers to establish their own notification servers which web apps may choose to use.
But when your browser starts using them, it (or the OS’s notification service) is going to need to maintain a network connection to each server used by each app. If users subscribe to notifications from many different apps and the apps all use different push servers, then you’re back to multiple persistent network connections. Again, this is not going to be a real problem for desktop/laptop systems, but it creates real problems for mobile devices.
This is actually a very hard problem and I don’t think the web development community has actually solved it. There are some proprietary solutions (like Google’s), but Apple has never been one to jump on the bandwagon. The only proprietary solutions they promote are their own.
I personally think Apple will roll out push notifications only after the W3C completes the standardization process so the spec will no longer be a moving target. Then they’ll implement something that conforms to that standard, whether or not it is compatible with Google’s services. Very much like they did when they refused to allow Flash (a proprietary Adobe product) on mobile devices and ended up forcing most web apps to move to HTML5 (a W3C standard).
No. This is a solved problem, and your suppositions about how it works are wrong. I run a website which (just like this one) offers push notifications to every browser on every platform except iOS. Apple simply doesn’t allow push notifications to iOS devices.
Edited to add: It’s been a completely solved problem for about 5 years now. Apple added it to Safari on the Mac even longer ago, back in 2013. No problems with centralization. No reason it would hurt battery life. For the best possible spin on why Apple is still refusing to allow it, you can read (an overly optimistic and generous post, in my opinion) here:
Edited again to add: Meanwhile, the “solution” is for us to create a native app for our website. But Apple refuses to allow native apps that are only a wrapper around a website without adding additional functionality. The only functionality we want to add is push notifications, but Apple doesn’t consider that enough of a reason to allow an app. So… Apple has completely blocked us from sending push notifications to our members. We can’t do it from our website, and we can’t do it from an app.
Since you are clearly an expert in this area, and you believe that everything I wrote is wrong, please educate me on how it really works.
What services are you implementing? What IETF and W3C standards do they comply with? What push servers are you using? Do you run your own or do you lease someone else’s? If you run your own, how do you avoid the problem of the browser needing to maintain persistent connectionns to your app server?
Basically, the company that wrote the browser runs the messaging servers. The messages are encrypted before being passed to them by the website. More here.