# Finb/Bark: pushing custom notifications to an iPhone through APNs > Bark is an iOS app plus a small HTTP endpoint that turns a GET or POST request into a notification on your own phone. It is free to install, and the README says the server can be self-hosted. **Finb/Bark** — Bark is an iOS App which allows you to push custom notifications to your iPhone - Repository: https://github.com/Finb/Bark - Website: https://bark.day.app - Stars: 9,208 · Forks: 712 - Language: Swift - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/finb-bark ## What Bark solves, and who it is actually for Getting a notification onto your own phone normally means registering an app with APNs, managing a device token, and writing a server. Bark removes that work. The README describes it as "a push notification tool app" that is "free, simple, and secure, leveraging APNs without draining device battery." The unit of use is a URL. You open the iOS app, copy the test URL it shows, and then any script, cron job, or webhook that can make an HTTP request can send you a push. The audience is narrow and specific: people who already own an iPhone, want notifications addressed to themselves rather than to a user base, and are comfortable pasting a URL into a shell script. It is not a customer messaging platform. There is no audience segmentation in the README, no delivery analytics, and no per-user device registry beyond the key that the app issues. The advanced iOS notification features it exposes (grouping, custom icons, sounds, time-sensitive notifications, critical alerts) are the reason to pick it over a plain webhook into a generic push service, because those are exactly the fields most generic services do not let you set from a URL. ## The URL is the API: how a request becomes a notification The whole mechanism is path matching on the server side. The README states the URL structure as "The first part is the key, followed by three matches", with the shapes /:key/:body, /:key/:title/:body, and /:key/:title/:subtitle/:body. The key identifies the device; the remaining path segments become the notification fields. Both GET and POST are accepted, and for POST "the parameter names are the same as above". Optional behaviour is expressed as query parameters on a path segment. The README gives url for a tap target, group for grouping pushes, icon for a custom icon on iOS 15 and above, sound for the alert sound, call with call=1 to "Play sound repeatedly for 30 seconds", and ciphertext for an encrypted payload. Notification interruption level is set with level, where the documented values are active (the default, which lights the screen), timeSensitive (shown during focus mode), and passive (added to the notification list without lighting the screen). A separate criticalAlert path with level=critical is documented as ignoring silent and do not disturb modes. Note that the time-sensitive example in the README uses a Chinese path segment, so the segment is a label rather than a fixed English keyword. One design consequence is worth stating plainly: the key travels in the URL path. Anyone who sees that URL, in a log, a shell history, or a screenshot, can push to your phone. The README offers ciphertext as an encrypted push option but does not document how the client derives or stores the key, so treat the ciphertext parameter as something to investigate in the linked documentation rather than as a guarantee you can assume. ## Installing Bark and sending a first push There is nothing to build. Bark is distributed through the App Store, and the README's download section links to the Bark Custom Notifications listing. Install it there, open it, and copy the test URL the app displays. The README gives the request shape directly. A GET or POST to the key URL with a body segment produces a push: ``` https://api.day.app/yourkey/url?url=https://www.google.com ``` ``` https://api.day.app/yourkey/group?group=groupName ``` ``` https://api.day.app/yourkey/icon?icon=http://day.app/assets/images/avatar.jpg ``` ``` https://api.day.app/yourkey/sound?sound=alarm ``` ``` https://api.day.app/yourkey/call?call=1 ``` The README states that you can send GET or POST requests and that you will receive a push notification immediately upon success. For a POST, the parameter names are the same as the path segments. If you would rather not depend on api.day.app, the README states that Bark supports self-hosted servers; the documentation site at bark.day.app is where the server setup is described, not the README itself. ## Where Bark stops being the right tool The first limit is the platform. Bark is an iOS app, and the README describes only iOS notification behaviour. There is no Android client in the repository or the README, even though people search for one. If your phone is not an iPhone, this project does not address your case at all. The second limit is delivery semantics. The README says you "will receive a push notification immediately upon success", which frames the HTTP response as the confirmation. It does not document retries, queueing, or what happens when the device is offline. For a personal alert that is usually acceptable; for anything where a missed notification has a cost, you need your own acknowledgement path, and Bark does not provide one. The third limit is configuration surface. Critical alerts are documented as ignoring silent and do not disturb modes. That is a real capability, and it is also a switch that can wake a phone at any hour, so it belongs behind a deliberate decision rather than a default in a script. Similarly, call=1 repeats the sound for 30 seconds, which is useful for an incident and unpleasant for a routine job. The README documents the parameters; it does not document rate limits or abuse controls on the hosted endpoint, so a loop that fires on every log line is a risk you are taking on yourself. ## Bark compared with running your own push server The obvious alternative is to register an app with APNs directly and send notifications from your own backend. That gives you control over the device token lifecycle, retry policy, and delivery records, and it is the right choice if you are notifying other people rather than yourself. The cost is that you now own an APNs client, certificate or key rotation, and the failure modes that come with them. Bark trades all of that away for a URL. The difference in approach is that Bark centralises the APNs work in an app you install and a server you may or may not run, while a custom APNs integration centralises it in your codebase. A second alternative, visible in the README's own list, is to use one of the community clients rather than the raw URL: a browser extension, a Windows push client, a cross-platform command line application, a GitHub Action, or SDKs for Java, Python, PHP and JavaScript. These do not change the mechanism; they wrap the same URL API so you do not hand-build query strings. If your sending side is a CI job, the GitHub Action entry in that list is the shortest path. If it is a JVM service, the Java SDK entries cover it. Choosing among them is a matter of which runtime you already have, not of which one delivers better. ## Maintenance, licence, and what running it costs you The repository is not archived, and the last push was on 2026-09-21, so the project is being worked on. The licence is MIT, which is permissive: you can use, modify and redistribute the code, including in closed products, provided the copyright notice and permission notice are preserved. That is the standard reading of MIT and not legal advice; if you plan to redistribute a modified app or server, read the LICENSE file in the repository. The upgrade cost depends on which half you use. If you only use the hosted api.day.app endpoint and the App Store app, upgrades arrive through the App Store and there is nothing to maintain on your side, but you are also dependent on a service you do not operate. If you self-host the server, you are tracking a Swift project with a Podfile, a Bark.xcworkspace, and a NotificationServiceExtension, which means Xcode and CocoaPods on your build machine. The repository also carries fastlane and a check_unused_translations.py script, which suggests a release and localisation workflow you would inherit. Budget for that before deciding to self-host; the README does not describe a server upgrade procedure, so the release notes and the documentation site are where you would look. ## Conclusion Adopt Bark if you want a personal notification channel on iOS that you control from a URL and do not want to build an APNs client. Do not adopt it if you need Android delivery, server-side delivery guarantees, or a delivery audit trail, since the README describes neither. Before relying on it, verify that your key still works against api.day.app, that your chosen notification level appears on the device, and, if you self-host, that the server you point at is the one you intend. ## FAQ ### How much does Bark cost per month? The README describes Bark as free, and the app is distributed through the App Store listing linked in the download section. No subscription or monthly fee is mentioned anywhere in the repository README. ### Can you put the Bark app on an iPhone? Yes. Bark is an iOS app, and the README's download section links to the Bark Custom Notifications listing on the App Store. You install it there, then open it and copy the test URL it displays. ### Is there a free version of the Bark app? The README describes Bark as free, and it does not mention paid tiers or a separate paid edition. It also states that self-hosted servers are supported, so you can run the server side yourself. ### What does the Bark app do? Bark pushes custom notifications to your iPhone using APNs, triggered by a GET or POST request to a URL containing your key. It supports notification grouping, custom icons, sounds, time-sensitive notifications and critical alerts, per the README. ## Sources - [Finb/Bark on GitHub](https://github.com/Finb/Bark) - [Issues](https://github.com/Finb/Bark/issues) - [License: MIT](https://github.com/Finb/Bark/blob/master/LICENSE) - [Project website](https://bark.day.app) - [README](https://github.com/Finb/Bark/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/finb-bark