← Back to home
Architecture decision / iOSBlackBerry UEM 12.24

Internal web app on iPhone: Access or Safari?

Two routes to the same intranet. Different boundaries for data, identity and operations. This is the decision map I would draw before touching a profile.

The decision in 30 seconds.

Conditional recommendation

If the web app and its data should remain inside the BlackBerry Dynamics environment, evaluate BlackBerry Access first. If the native browser is important and your data and policy boundaries allow it, evaluate Safari with Secure Connect Plus. Either way, backend authentication remains a separate architecture decision.

This is not a universal product recommendation. Data handling, supported authentication, actual entitlements and a pilot with the target app determine the answer.

One goal. Three questions.

Fictional example: 500 managed iPhones need to reach intra.example. The service is behind the firewall and uses existing enterprise authentication. People need to read pages and occasionally open files.

  1. Where may downloaded files end up: inside the Dynamics container or in other iOS apps?
  2. Is reaching the service enough, or must users sign in without re-entering a password?
  3. Who jointly owns the domain, DNS, certificates, UEM profile and backend?

The first question separates the candidates. The second separates network access from single sign-on. The third determines whether the solution remains operable.

These routes are not interchangeable.

A / controlled app environmentBlackBerry AccessDynamics Policy + Connectivity ProfileBlackBerry Proxy / selected routeInternal web app → backend sign-in
B / native browserSafariSafari Domain + iOS Per-App VPNBlackBerry Connectivity / BSCPInternal web app → backend sign-in

Keep separate: A tunnel transports traffic; it does not turn a web login into SSO. A VPN domain match does not confine Safari downloads to a container. Design and test those boundaries separately.

Where each route helps – and costs.

QuestionBlackBerry AccessSafari + BSCP
Data controlThe Dynamics container and Access rules can restrict sharing; the actual policy determines the effect.Safari sits outside the Dynamics container. Evaluate iOS and UEM protections separately.
ExperienceA dedicated browser; useful when Dynamics apps and their links work together.The familiar iOS browser; test app-to-browser transitions and repeat sign-in.
NetworkA Dynamics Connectivity Profile defines permitted destinations and routing.Enterprise Connectivity Profile, Safari Domains and BSCP DNS must align.
IdentityAccess can work with Dynamics and backend methods; KCD and certificates have their own prerequisites.Backend sign-in still applies; validate SSO with iOS, the IdP and the web app separately.
OperationsMaintain the app, Dynamics policy, connectivity and Proxy route.Maintain MDM state, VPN assignment, Connectivity app, domain and DNS.

Entitlements and cost depend on the customer environment. This table does not establish a general price advantage.

Which settings move together?

A · Access

  1. Deploy BlackBerry Access and assign it to the pilot group.
  2. Assign the Dynamics policy and Connectivity Profile; check target domain and route.
  3. Choose Access settings such as Enforce strict tunnel and Safari hand-off deliberately.
  4. Test backend authentication with identity and web teams. KCD is not a browser-only checkbox.

B · Safari + BSCP

  1. Activate iPhones with MDM controls; check entitlement and the BlackBerry Connectivity app.
  2. Under Policies and Profiles → Networks and connections → Enterprise connectivity, configure BSCP for the pilot group.
  3. Align iOS Per-App VPN and Safari domains with the target domain; check internal BSCP DNS.
  4. On the device, test domain access, VPN trigger, name resolution and backend login separately.

The field names and behavior are documented for UEM 12.24. Activation type and product version may add prerequisites; confirm them against the deployed release during the pilot.

A pilot that supports a decision.

I would use two small pilot groups on the same web app and tasks: open the site, sign in again, follow a link from another app, download a file, change network and restart the device. For each step, record user effort, file destination, service availability, errors and the responsible component.

The outcome

A one-page decision: chosen route, rejected route, reasons and remaining conditions. Alongside it, a dependency map covering the app, UEM objects, VPN/Proxy, DNS and authentication – usable by implementation and operations teams.

Scope and sources.

Author: Axel Lenz. Editorial update: 26 September 2026. Reference versions: BlackBerry UEM 12.24, BlackBerry Access 3.20 and Apple Deployment documentation. The example is fictional and includes no customer configuration. A specific recommendation requires testing the actual product release and target app.