ntfy
ntfy copied to clipboard
binwiederhier
IOS16.x doesn't tell you anything
I have the same problem. Since the update to iOS 16 i don't get any notifications anymore.
Same here. I receive the push popup but nothing appear inside the app. I remain available if you need some tests from me.
Ok just tested public server and it is working.. self hosted one doesn't
When having issues with ntfy on premise and iOS, did you set the proxy option if applicable and more importantly the base-url in config?
Search for "iOS" here: https://ntfy.sh/docs/config/
This is mandatory for timely notifications.
When having issues with ntfy on premise and iOS, did you set the proxy option if applicable and more importantly the base-url in config?
Search for "iOS" here: https://ntfy.sh/docs/config/
This is mandatory for timely notifications.
Yes, i have set :
upstream-base-url: "https://ntfy.sh"
in the configuration, but still no notifications on self hosted instance.
I want to acknowledge that I have seen this ticket, and I know that iOS support is a little brittle right now. My apologies. I wanted to get something out there, even if it wasn't 100% awesome. When I have time, I will look at iOS again, but don't hold your breath. I am quite busy at the moment.
That said, please READ and follow this guide for instant iOS notifications using a selfhosted server: https://ntfy.sh/docs/config/#ios-instant-notifications
You MUST set the upstream-base-url to https://ntfy.sh (NOT your own server URL), and you must set your base-url to the exact same URL that you use in the iOS app to subscribe. Otherwise you won't receive any notifications.
@binwiederhier did everything according to docs/instructions as you said. base-url - selfhosted url upstream-base-url - https://ntfy.sh
But still having issues, at least it works flawlessly on android and browsers 😄
Sorry, I don't have further advice.
I can confirm everything working for me on iOS 16 and 16.1b. Docker container behind Nginx, configuration set according to config. Notifications take just seconds.
I have encountered the same problem.
I use ntfy behind a reverse proxy. My reverse proxy connects to ntfy internaly through HTTP. But my proxy manage SSL certificate for me and I connect to ntfy externally through HTTPS.
In the server.yml file, I've changed http to https in my base-url line.
Yet, everything works fine with iOS 16.0.2.
I was having an issue with the iOS notifications despite following the instructions at https://ntfy.sh/docs/config/#ios-instant-notifications
On my case it appears like it was caused by bad indentation in the server.yml file. The upstream-base-url was incorrectly indented and it seemed to have been preventing it from being picked up. When I made sure all the keys had no tabs/spaces before them everything started working as expected.
Maybe that helps someone else who is running into something similar.
My server.yml:
behind-proxy: true
base-url: "https://ntfy.xxxx.xxx"
listen-http: ":80"
upstream-base-url: "https://ntfy.sh"
cache-file: "/cache/ntfy/cache.db"
attachment-cache-dir: "/cache/ntfy/attachments"
Notifications do appear instantly in the webinterface, but not in the iOS app (iOS version 16.1.1, app version 1.2)3)). The messages only appear in the iOS app after manually refresh the app. Does anyone have a clue?
My server.yml:
behind-proxy: true base-url: "https://ntfy.xxxx.xxx" listen-http: ":80" upstream-base-url: "https://ntfy.sh" cache-file: "/cache/ntfy/cache.db" attachment-cache-dir: "/cache/ntfy/attachments"Notifications do appear instantly in the webinterface, but not in the iOS app (iOS version 16.1.1, app version 1.2)3)). The messages only appear in the iOS app after manually refresh the app. Does anyone have a clue?
I don't use the listen-http, but nontheless find it weird to listen on 80 with a https url.
My server.yml:
behind-proxy: true base-url: "https://ntfy.xxxx.xxx" listen-http: ":80" upstream-base-url: "https://ntfy.sh" cache-file: "/cache/ntfy/cache.db" attachment-cache-dir: "/cache/ntfy/attachments"Notifications do appear instantly in the webinterface, but not in the iOS app (iOS version 16.1.1, app version 1.2)3)). The messages only appear in the iOS app after manually refresh the app. Does anyone have a clue?
I don't use the listen-http, but nontheless find it weird to listen on 80 with a https url.
I understand what you're saying, but the SSL is being handled by my proxy (hence the behind-proxy: true), and internal it is an http connection between the proxy and the docker container. So everyhting seems to work fine, except for the iOS notifications.
My server.yml:
behind-proxy: true base-url: "https://ntfy.xxxx.xxx" listen-http: ":80" upstream-base-url: "https://ntfy.sh" cache-file: "/cache/ntfy/cache.db" attachment-cache-dir: "/cache/ntfy/attachments"Notifications do appear instantly in the webinterface, but not in the iOS app (iOS version 16.1.1, app version 1.2)3)). The messages only appear in the iOS app after manually refresh the app. Does anyone have a clue?
I don't use the listen-http, but nontheless find it weird to listen on 80 with a https url.
I understand what you're saying, but the SSL is being handled by my proxy (hence the behind-proxy: true), and internal it is an http connection between the proxy and the docker container. So everyhting seems to work fine, except for the iOS notifications.
I take it back then. I wish i could help, but i haven't used the Applephone in many moons.
As many other users stated before the iOS app on my iPhone 11 with iOS 16.6 does not display any notification using our self hosted server, until I manually refresh the page in the ntfy app. What's weird, is, that my Apple Watch, which is connected to my iPhone, sometimes (not always) does display exactly the same push notifications from my self hosted server more or less in real time. Because of that I don't think, that the problem with the ntfy iOS app mentioned above can be solved by the user or by changing the configuration in server.yml. If my server or network configuration would be incorrect, my Apple Watch would also not display those push notifications. For me it seems to be a problem either in iOS or in the ntfy app.
:loudspeaker: A new version of the ntfy iOS app is currently in TestFlight. This version (hopefully) fixes the issues with the UI not properly refreshing, as well as fixes for subscriptions "getting lost". It contains no other fixes. More to come. To test the app, please use this TestFlight link: https://testflight.apple.com/join/P1fFnAm9
I installed the test flight version on an iPhone 11 the day it was released and notifications have been working for me. I see ‘ntfy 1.3 (4)’ as my installed version.
Sorry, but I could not test the app sooner. I also installed the test flight version 1.3 (4) a few moments ago and for me it seems to work much, much better now. I installed the version, booted my iPhone and after that every single test message I sent from the web GUI was received and displayed as a push notification on my iPhone immediately. All messages will also appear in the ntfy app itself immediately.
After a little more testing I found, that here seems to be an issue with the "Subscribed topics" list in the test flight version 1.3 (4): At least for me this screen does not seem to update after notifications have been received. I have to manually refresh this screen to update the counters. For me this is more a cosmetic issue, because I can see the message itself as push notification. Can someone else confirm this?
For another data point, I opened the “Subscribed topics” screen and had several notifications come through with the notification up top and the text under the topic did update, both the count for the topic and the time.
On my iPhone 15 Pro with iOS 17.1.1 and the testflight app this doesn't work - the counters will not be updated. I tested this with WiFi and mobile network. I even unsubscribed from the topic and subscribed again. What iPhone/iOS version are you using?
Thanks guys for the feedback. I have gotten very little of it, so I think I will just slowly release the version I have. The notification counter updates just fine on mine and Tom's phone, so it's impossible to figure out what's up here.