Technical insight
Integrating Grafana into iOS apps with authentication for fast HMI prototyping
14 Mar 2026
- Grafana
- iOS
- HMI
- Prototyping
Grafana is useful when an HMI prototype needs real operational data before a product team has built its own charting layer. Existing queries and dashboards can put trends, event markers and equipment state onto an iPad quickly.
Displaying the dashboard is the easy part. An iOS application still needs a controlled way to establish a session, keep it alive and decide which Grafana resources the user may reach. A web view does not automatically inherit the authenticated state of Safari or of the native application.
The prototype should therefore begin with an access decision: is the app opening a complete Grafana experience, showing a fixed operational view or using Grafana only as a temporary source of visual output?
Why browser-based authentication changes inside an app
Grafana deployments commonly sit behind single sign-on, a reverse proxy or their own login. In a desktop browser, redirects and cookies are handled within a familiar browser session. A WKWebView has its own cookie store and lifecycle. Policies around cross-site cookies, redirects and storage can also differ from the environment in which the dashboard was first tested.
Common symptoms include:
- a login loop inside the web view;
- a successful login in Safari that the embedded view cannot see;
- a session that disappears when the view is recreated;
- an identity provider refusing an embedded sign-in flow;
- dashboard assets loading while data requests return unauthorised responses.
These failures are usually boundary problems rather than Grafana rendering problems. Debug the redirect chain, cookie attributes, origin changes and proxy headers before changing the dashboard.
Access patterns for a prototype
Several approaches can be valid, depending on the risk and expected lifetime of the prototype.
Open an authenticated browser session
The app can send the user through the normal browser-based sign-in flow and open Grafana outside the embedded product. This preserves the identity provider’s supported process and requires little native session work.
It is suitable for engineering tools where leaving the app is acceptable. It gives a weaker integrated experience and less control over navigation.
Establish a web-view session through a supported handoff
A backend can issue a short-lived, single-use handoff after the native user has authenticated. The web view opens a controlled endpoint, the server validates the handoff, establishes the permitted web session and redirects to a known dashboard.
This avoids putting a long-lived Grafana credential in the app. It needs careful design around expiry, replay prevention, logout and dashboard permissions. The handoff should grant only the access required for the view.
Put Grafana behind an authenticated proxy
In an internal environment, a trusted proxy may map the application’s identity to a restricted Grafana user or organisation. This can centralise access control and hide Grafana from direct public access.
The proxy becomes a security-sensitive component. It must validate every request, constrain destinations and prevent users from changing headers or paths to reach another tenant’s data.
Serve snapshots or rendered output
When the prototype needs a small number of read-only views, the backend can provide rendered panels or images. The app no longer manages a full interactive Grafana session.
This is easier to constrain and can work well for a status overview. It loses drill-down interaction and requires a deliberate refresh policy so users understand how current the image is.
Query a dedicated API and render the view in the app
For a narrow HMI, the application can request selected data through its own API and render native components. Grafana may remain useful for engineering analysis while the product UI owns the operational screen.
This requires more interface work. It gives the product full control over touch behaviour, offline state, accessibility, error messages and the distinction between current and stale data.
Keep production boundaries visible during prototyping
Fast experiments are allowed to be temporary. Temporary access decisions should still be documented. Avoid shipping a shared administrator password, disabling authentication on a network endpoint or embedding a permanent service token in the application bundle. Mobile applications cannot keep a distributed secret.
Record:
- who can access the prototype;
- which dashboards and data sources are reachable;
- how sessions expire and are revoked;
- whether the environment contains production data;
- what must change before wider rollout.
If the prototype sits on a restricted factory network, that network remains one layer of protection rather than the identity model itself.
Know when the web view has done its job
Embedding remains attractive when engineers already maintain the dashboards, users need Grafana’s own exploration tools and the application is mainly a secure entry point. It becomes less suitable when operators need a small number of highly controlled actions, predictable touch targets, offline behaviour or a layout tied closely to machine state.
At that stage, keeping the data path and replacing the embedded presentation may be the cleaner product decision. The prototype has already answered valuable questions: which signals matter, which time ranges users inspect and where the source data is incomplete.
Test the session as seriously as the chart
An HMI prototype should be exercised across app restarts, session expiry, network changes and identity-provider failures. Confirm what the user sees when data is old or unavailable. Test that logout clears both native and web state, and that a user cannot navigate from an approved dashboard into administrative areas.
Grafana can shorten the path from live data to a testable operational view. The integration is ready for a real pilot only when access, session lifecycle and failure behaviour are as deliberate as the visualisation.