BluEclipse
☰
BluEclipse platform engineering
A Mobile App Should Be Another Door Into the Platform
Not another platform to maintain. The shared foundation that lets one backend serve web, Android and iOS — and the deployment pipeline nobody puts in a portfolio.
- Category
- Mobile and platform engineering
- Core technologies
- Capacitor, Android, iOS, Firebase, push notifications, APIs, web technologies
- Built for
- Bringing web-connected systems onto Android and iOS
BluEclipse's Mobile Application Infrastructure is the shared foundation for putting web-connected systems onto phones — connected to the existing authentication, APIs, notifications, data and business workflows rather than rebuilt beside them.
“Wrap the website” is an accurate description of about ten percent of the work. An application has to behave like part of the device it is installed on, and the device has opinions:
- Authentication persistence
- Push notifications
- Device permissions
- Native navigation behaviour
- Application lifecycle
- Deep linking
- Mobile layouts
- Platform packaging
- Android signing
- iOS certificates
- App store distribution
Roughly the first half of that list is engineering and the second half is release process, and a product is not shipped until both are done. The infrastructure exists so that neither has to be worked out again for the next application.
One backend, three front doors
Where it makes sense, shared web technologies are used across the mobile and web products, so the same backend infrastructure supports a web application, an Android application and an iOS application without three independent systems being maintained in parallel.
The qualifier matters: shared where appropriate, with mobile-specific behaviour introduced where it is genuinely required. Sharing everything produces an application that feels wrong on both platforms; sharing nothing produces three codebases that disagree with each other by the second release.
Clients
Web
Android
iOS
Shared platform infrastructureOne identity, one API surface, one event architecture
Backend
Authentication
Business logic
Data and integrations
One account, whichever way you arrive
A user should not have a different account depending on whether they opened the web version or the app. Shared authentication keeps identity and permissions consistent across clients — which matters most in business platforms, where a user's role determines what operations they are allowed to perform at all.
Getting that wrong is not a login inconvenience. It is two systems with two opinions about what someone is permitted to do.
Notifications as part of the event architecture
A mobile client makes it possible to tell someone about something while the application is closed, which is when most of the important things happen. Firebase Cloud Messaging carries events such as:
- New orders
- Booking updates
- Delivery changes
- Payment events
- Business notifications
- Customer activity
These originate in the platform's existing event flow rather than in a separate mobile notification feature, so a push is another delivery channel for something the system already knows — not a parallel mechanism that has to be kept in step by hand.
The part that is not programming
Building the application is the half of mobile work that people expect. The other half is getting it onto a device that is not yours, and it is where projects quietly lose weeks.
BluEclipse has taken Android applications through the full release process:
- Application packaging
- Signing
- Versioning
- Play Console configuration
- Store assets
- Release builds
- Publishing
iOS brings its own infrastructure requirements, and less forgiveness:
- Certificates
- Provisioning profiles
- App Store Connect configuration
- Build signing
- Archive creation
- Distribution
None of this is intellectually difficult and all of it is unavoidable. A signing key that was not stored properly, a provisioning profile that expired, a version code that went backwards — each is a small mistake with an outsized cost, discovered at the least convenient moment. Treating deployment as infrastructure rather than as a final step is what stops it from being rediscovered per project.
The client is one layer
Whatever the application looks like, it still depends on backend services for:
- Authentication
- Data persistence
- Business logic
- Payments
- Orders
- Notifications
- Permissions
- Integrations
Which is why mobile work here is not a separate discipline practised by a separate team. It is closely tied to the backend and platform architecture, because nearly every interesting thing an application does is a question it asks of something else.
Solve it once
Once deployment, authentication, notifications, API communication and application lifecycle have been worked out, those patterns are reusable. The next product needing a mobile client inherits them instead of paying for them again, which is the only reason any of this counts as infrastructure rather than as a project.
Businesses increasingly expect their systems to work wherever they happen to be, and for a lot of products a desktop-only platform is simply not enough. A mobile application should be another interface into the platform — not another disconnected platform to maintain.
Built by BluEclipse. Used across real production applications.
For businesses needing an app
If you already have a working platform, the question is how much of it can come with you onto a phone. Usually more than expected.
For technology clients
Cross-platform delivery, shared authentication, push architecture and the full Android and iOS release pipeline.