New mobile app (Android, iOS, Windows), plus 7 new integrations!

Permissions to send notifications are typically granted and controlled on a per-app basis, so probably Nectar should request permission and send its own push notifications in-app.

Once the app has permission and tokens etc to send notifications, if it wants to implement notifications on the zeno schedule, it could use the zeno webhook urls – – to get a zeno notification from beeminder, and then push through to the app user if they’ve allowed notifications. Hmm. Though at the moment there’s not a way to set the through the api, and those are designed more for the user themself if they want to set something up – since there’s only one per goal.

Oh wait! If you want to follow the zeno notification timing, you can send notifications after/from your autofetch_callback_url response. That callback is us checking for new data / fetching data on the zeno schedule for the goal.

1 Like

@bee Thanks for your response. We would like to have notifications for all the user’s goals, not just the user’s Nectar integration goals. The best way to do that is to subscribe to your existing zeno polling/push notification system. This would be extremely easy for me to configure and users would receive notifications faster and more accurately then with the other options.

Yes, we would need to request permission from the user to receive push notifications. If they granted permission, we would get a [device_token] to send to your API endpoint:[access_token]&device_token=[device_token]. Then, when the user is about to derail on any of their goals, they would receive the zeno notifications on their device.

I just need your permission to use those API endpoints in the Nectar mobile app and the SENDER_ID for the Android platform.

The device token endpoint has nothing to do with zeno notifications, and is private because it’s related to some hokum specific to both the android and ios apps.

Goals, nectar-created or not, will get notifications on the zeno schedule in whatever ways the user has configured their notifications. We don’t currently have a way for an app to register for zeno notifications. Here are your options:

  • If your app sets the zeno_callback_url for a specific goal then you’d get a zeno push specific to that goal. However that’s a field that the user has access to in their settings, and was meant with the idea in mind of the user hacking up their own stuff. You should definitely not overwrite that field if it’s already set, and your app should not count on getting those notifications, or at least be aware that your callback might get ousted if the user is messing with their settings or whatnot.
  • Your app has registered an autofetch_callback_url, which means you get a ping from our servers whenever we want new data for a goal. This is almost equivalent to the zeno schedule. You will get some extra notifications because we check for new data:
    • at the end of the day before the day rolls over to the next calendar day
    • before sending a reminder or zeno
    • whenever the user pushes the Refresh button.

Conclusion: we should consider allowing apps to register a zeno callback url, which would parallel the user’s zeno callback, and give a registered app the ability to subscribe to its users’ zenos.

In the meantime, you can attempt to use the user’s individual goal settings, or you can use the autofetch callbacks to determine when to send alerts (with some additional filtering logic to verify that it is indeed an eep day or whatnot).

1 Like

@bee Thanks again for your response.

OK, that private API endpoint is in a function named saveDeviceTokenToServer, which is called from a function named didRegisterForRemoteNotificationsWithDeviceToken. Because the function has “Remote Notifications” in the name, the device token needs to be sent to a server for push notifications and these were the only two private API endpoints in your iOS app, it seemed logical that the API endpoints were used for your push/zeno notifications.

Users (like @kenoubi) want to get zeno notifications for all their goals without having to install two apps.

This would solve part of the issue, but mobile apps do not have URLs, so developers would have to run their own separate server for push/zeno notifications, which would be prohibitively expensive and complex for most mobile developers (including us).

Again, the easiest solution to enable zeno polling in the Nectar mobile app is to allow Nectar to use your existing push notification system. Notifications are the last feature of both your Android and iOS apps that Nectar does not yet include. With your permission, I would be happy to configure this.

As I said in my e-mails, we would be thrilled if you would consider using Nectar as your official Beeminder app. Beeminder’s recent blog post said you want to include “Mobile-friendlier goal creation” in your iOS app, however Nectar already fully supports adding Beeminder goals. In addition, it would save you a lot of development time and money in the future. The Nectar mobile app has one user interface and one codebase that supports three different platforms. Your existing apps have two user interfaces, two codebases and only supports two platforms. If you wanted to add a new feature to Nectar, you would only have to add it once, whereas with your existing apps you would have to add it twice. This is why I was able to add so many additional features to Nectar. Because your existing apps were made by different developers, they have completely different user interfaces and features (see comparison table in first post), making it very difficult for users to seamlessly switch between your Android and iOS apps.

Running a separate server is part of the “standard” model for implementing push notifications.

@csu Yes of course, but there is no need to reinvent the wheel by creating our own separate server for push/zeno notifications when Beeminder already has a server.

Thanks for all the hard work you’ve been putting into this! I was thinking about push notifications and there are a few things to consider here.

In order to send a push notification to an app, the server sending the notification has to have an SSL certificate installed on it that’s associated with that app in order for the push notification service (APNS in the case of iOS) to accept and deliver the notification. So this presents a fundamental barrier to delivering push notifications to different Beeminder apps for a given platform. Even if you did send the device token to that endpoint and we saved it to the server, we would now have to keep track of which device tokens were associated with which apps, and probably also update the UI to let the user indicate if they no longer wanted to receive zeno’s for the given app. We’d also have to get the certificate and install it on our servers, which wouldn’t be terrible to do once but would get tedious with lots of apps (they also expire every year in the case of APNS). The setup for Android might differ a bit in the details but is essentially the same.

@bee’s suggestions of allowing people to subscribe to zeno notifications would be a workaround, since it would mean that anyone could register a Beeminder app, set up this callback, and then run a tiny server ($5/month) which would have as its only job to receive the callback when a goal gets a zeno alert, host the push certificate, and send the notification to the push notification service.

1 Like

I meant running a separate server shouldn’t be “prohibitively expensive and complex” for developers, considering it’s the standard way of implementing push notifications and most mobile apps have been doing it that way.

+1 for the zeno callback idea. Plus, isn’t already a backend server with paid-for hosting? Couldn’t the push notification provider server just be added to that without any additional cost?

1 Like

@apb Thanks for your reply.

Given the thousands of hours my team and I have spent on developing Nectar, it is extremely unlikely that anyone else would be interested in developing a mobile app for Beeminder and sending zeno notifications to users.

We cannot generate the certificate for iOS for the same reason that we cannot publish the Nectar mobile app to the App Store. It requires a $99 a year Apple Developer account.

I am not sure how much you know about our team, but @dreev and @bee sponsored us to create Nectar between approximately November 2016 and March 2017. Since then, I (@tdulcet) have completely rewritten Nectar and added many additional features. Before I finish, I would like the Nectar mobile app to include all the features of both Beeminder’s Android and iOS apps. Notifications are of course, the last feature that it does not include.

As I said to @bee, we would be thrilled if you would consider using Nectar as your official Beeminder app. If you choose to do so, setting up push/zeno notifications would not require you to make any changes to your server. I would be happy to configure the Nectar mobile app and I could help rebrand it to Beeminder if needed. You could test it on the Windows Store first, since Beeminder does not currently have a Windows app.

@csu Yes, if Beeminder updated their API to allow developers to subscribe to zeno notifications, then the push notification server could be implemented in Ruby on Rails and added to the Nectar web app, but someone (Beeminder?) would still have to let us use their Apple Developer account. In addition, it would increase the complexity of the Nectar web app, which is limited to just 10,000 database entries. If we went over that, there would be an additional cost. Pull requests welcome!

We are aware that the Nectar web app is offline. I have contacted Heroku and hopefully they will fix the issue shortly. We apologize for any inconvenience.

The issue was resolved right after my post.

I made another small update to the Nectar mobile app. It now displays more information on the goal detail page and the home page should look better on devices with a small screen.

I also updated the comparison image from the first post to fix two errors with Beeminder for iOS and reflect that it is now open source again:

@dreev can you please give me permissions to edit the first post, so I can replace the image.

1 Like

Sure! I just made it a wiki. Does it let you edit it now?

1 Like

Yes. Thank you!

Seriously, that’s unacceptable failure of the free market. It hurts me so much that there aren’t more open source apps in the app store. Can you please email me at and we’ll get you set up with an apple developer account?


I just sent you an e-mail. Thank you! Based on feedback we have received, many Beeminder users will appreciate your offer!

I made a small update to the Nectar mobile app. The countdown timers on the Home page will now all update at the same time and should be faster for users with many goals. In addition, I made improvements to the timer datapoints feature.

I also updated the comparison image from the first post to reflect that Beeminder for iOS now supports adding timer datapoints.


The heroku based web app seems to be down. Is this still an actively maintained project? :slight_smile:

1 Like

Beeminder turned off the Nectar web app in January.

Nectar is open source, so there is always the possibility that someone else could start it up again in the future or that it will be merged with

@matti – I assume you are asking because of your Beeminder Integrations MEGALIST thread. You can still add these seven integrations to that list. Users can always run their own copy of the Nectar web app if they want those six integrations and the Pebble integration does not require any backend service.

Thanks for everyone’s support and sorry for the inconvenience.


Hi! Sorry about the downtime! I actually thought it didn’t have any users and it seems like that was true since it took a couple months to notice but I can totally turn it back on if there are! Huge thanks to @nectar for making it open source too so anyone has the option to run with it.