OFIBO Goes Real-Time: Firebase Push Notifications Are Now Live
September 17, 2026
September 17 was one of those development days where a feature that looks simple on the screen required a huge amount of work behind it.
Today we built the foundation for real push notifications in the OFIBO mobile app, connecting the Android application, Laravel backend, Firebase Cloud Messaging, background queues and our production server.
The result is important: OFIBO can now automatically notify users on their phones when meaningful activity happens on the platform.
Firebase Is Now Connected to OFIBO
The biggest part of today's work was integrating Firebase Cloud Messaging into OFIBO.
We configured the Firebase project ofibo-app and aligned the Android application with OFIBO's production package:
com.ofibo
The Android Firebase configuration, Expo configuration and native Android project now point to the same production application identity.
This sounds like a small configuration change, but it touches several layers of a React Native / Expo Android application. Package identifiers, native Gradle settings, Kotlin packages, Firebase configuration and EAS credentials all have to agree with each other.
We Moved OFIBO to the Correct Production Android Identity
Another major job today was standardizing the mobile application around
com.ofibo.
We updated the Expo configuration, Android namespace, application ID and native Kotlin package structure so the project uses one consistent production identity.
We also worked through stale Android build and code-generation artifacts that had been left behind by the old package structure.
After cleaning those native build references, React Native code generation was able to run successfully again.
Native Android Push Tokens
OFIBO does not simply send a generic notification through the frontend. Each signed-in mobile device now has its own Firebase Cloud Messaging token.
We created backend support for registering those devices with OFIBO.
The mobile app can now register its native FCM token after authentication and update it when Firebase rotates that token.
When a user logs out, the device can also be deactivated so OFIBO does not keep sending authenticated account notifications to a device that should no longer receive them.
A New Device System in the Laravel Backend
On the backend, we introduced dedicated device registration for push notifications.
OFIBO now stores user devices and whether each device is currently active.
We added authenticated API endpoints for registering and deactivating devices:
POST /api/push-devices
DELETE /api/push-devicesToken registration was also made race-safe using an atomic database upsert. This is important because mobile applications can trigger device registration more than once during authentication, token refreshes or application startup.
Firebase HTTP v1 From Laravel
The OFIBO Laravel API can now communicate directly with Firebase using the modern Firebase Cloud Messaging HTTP v1 API.
Instead of placing sensitive Firebase credentials inside the application repository or public web directory, the production Firebase service-account credential is stored separately on the server.
Laravel uses those credentials to authenticate securely with Firebase and send notifications to registered Android devices.
Followers Can Be Notified About New Music
The notification system is already connected to one of the most important relationships inside a music platform: following artists.
When an artist publishes a new public song, OFIBO can identify that artist's followers, find their active mobile devices and prepare notifications for them.
We connected this to both the Artist Studio upload flow and the administrative song-upload flow, so the behavior does not depend on which OFIBO interface was used to publish the track.
The logic is based on the publication of a new public song rather than on a particular music category, which keeps the feature flexible as OFIBO grows.
New Published Posts Can Generate Notifications Too
The same infrastructure was extended beyond music.
Newly published OFIBO posts can also be dispatched through the push-notification system, giving us a common notification foundation that can later support many different types of platform activity.
Notifications Run Through Laravel Queues
One important architectural decision was to keep Firebase work away from the user's upload request.
Publishing a song should not become slow just because hundreds or thousands of followers may need to receive notifications.
Instead, OFIBO creates a background queue job.
The upload completes normally, and the notification work is processed separately.
This also means a temporary Firebase problem cannot prevent an artist from successfully publishing a song.
We Put the Queue Worker Into Production
Building queue jobs locally is only half of the job. Something has to keep processing them continuously in production.
Today we configured Supervisor to run OFIBO's Laravel database queue worker permanently on the production server.
That means notifications no longer depend on somebody manually executing:
php artisan queue:workThe worker stays alive and automatically handles new notification jobs as they enter the queue.
We Found a Real Production Permission Problem
During production testing, we hit one of the more interesting problems of the day.
Firebase appeared to be configured correctly when commands were executed as the server's root user, but the permanent Supervisor queue worker still reported that Firebase was not configured.
The reason turned out not to be Firebase itself.
The Firebase credentials directory had filesystem permissions that allowed root
to access it but prevented the www user running the queue worker
from traversing and reading the credential path.
Once the correct group permissions and directory access were applied, the long-running Laravel worker could authenticate with Firebase properly.
That was an important production fix because it proved that the notification system worked under the actual server user and process that would be responsible for delivering notifications every day.
Then We Tested the Entire Chain
After all those pieces were connected, we performed the test that actually matters.
We published a real public song.
The complete chain became:
New song → Laravel → queue job → Supervisor → Firebase → Android device → notification
And it worked.
More importantly, the next notification worked automatically through Supervisor without manually starting a queue worker.
That confirmed that this was not just a successful development test. The production notification pipeline itself was functioning.
Preparing OFIBO for Production Android Builds
We also continued preparing the Android application for its proper production build pipeline through Expo Application Services.
The OFIBO EAS project is connected to the production application and now uses
com.ofibo as its Android package.
We verified the Firebase configuration against that package and checked the Android signing credentials stored by EAS.
The production build profile is configured to create an Android App Bundle and use remote version auto-incrementing, which is the direction needed for future production releases.
Expo Doctor also completed successfully with all 21 checks passing, giving us a much cleaner foundation for the next production mobile build.
Much More Than a Notification Popup
From the user's perspective, today's work eventually appears as something very simple: a notification arrives on the phone.
Behind that notification is now an entire OFIBO infrastructure:
- Firebase Cloud Messaging
- Firebase HTTP v1 authentication
- Native Android FCM tokens
- User device registration
- Token refresh handling
- Device deactivation on logout
- Follower discovery
- Song publication events
- Post publication notifications
- Laravel queue jobs
- A permanent Supervisor worker
- Production credential management
- Android package migration to
com.ofibo - Expo and EAS production configuration
A Huge Step for OFIBO Mobile
September 17 was not about adding one button or changing one page.
We connected multiple independent systems and made them work together as one production pipeline.
OFIBO now has the technical foundation for real-time communication between the platform and its mobile users.
Today it can tell followers that an artist has released a new song. The same infrastructure can eventually power many other meaningful OFIBO events without rebuilding the notification system from scratch.
It was a huge amount of invisible work, but it moved OFIBO considerably closer to behaving like a complete native music platform rather than simply a website inside a mobile application.
September 17, 2026: Firebase, Android and the OFIBO backend finally started talking to each other in production.