Enable Mobile Gyroscope in Five Minutes for Virtual Tours: iOS Fix

Yes, you can enable gyroscope controls so mobile viewers steer a 360° tour by moving their device. Modern mobile browsers support this kind of motion-driven navigation, but three prerequisites come first: serve your tour over HTTPS, trigger the iOS permission request from a user gesture, and give viewers a visible toggle. This platform includes documented support for exactly this setup.

TL;DR:

Gyroscope support requires serving the tour over HTTPS, prompting permission during a user gesture on iOS, and providing a visible toggle for viewers.

Testing gyroscope controls on both Android and iPhone using secure links is essential to ensure permissions and movement tracking work correctly.

On iOS, calling DeviceOrientationEvent.requestPermission() must happen inside a user gesture, and attaching event listeners only after permission is granted prevents common issues.

Gyroscope controls are most effective in mobile-first real estate and tourism tours, where device movement enhances the virtual experience.

Platforms like Simple Virtual Tour facilitate enabling gyroscope controls through settings, with resources available for testing, optimization, and deployment.

Simple Virtual Tour

simplevirtualtour.com

Create More Engaging Virtual Tours

Build customizable interactive tours with intuitive tools, live sessions, and cloud hosted or self hosted deployment options.

Start a free trial

Enable gyroscope in your tour editor and preview on mobile
Browser and security requirements: HTTPS, iOS permission, and platform differences
UX best practices: mixing gyroscope with touch, toggles, and fallbacks
Diagnose and fix common gyroscope issues
Implementation checklist and code patterns for engineers
Simple Virtual Tour support and resources for gyro-enabled tours
When gyroscope navigation is worth prioritizing
Try Simple Virtual Tour to publish gyro-enabled mobile tours
FAQ
Sources

Enable gyroscope in your tour editor and preview on mobile

Turning on gyroscope navigation is mostly a matter of flipping the right switch and testing it the right way. Here's the sequence we recommend to every creator publishing a mobile-first tour:

Open your tour settings and look for the motion or gyroscope toggle, usually grouped under Settings → Advanced Controls in most editor interfaces.
Add a short piece of onboarding text near the toggle that tells visitors a permission prompt will appear on iPhone, so the request doesn't feel unexpected.
Publish a test version or use a secure local tunnel (an HTTPS dev tool like ngrok, or a local TLS certificate) so you're testing under real browser security conditions, not a bare HTTP preview.
Open that test link on an Android phone in Chrome, then repeat on an iPhone in Safari. Confirm the toggle appears, the permission prompt fires correctly on iOS, and the view actually tracks device movement on both.

Treat this preview step as mandatory rather than optional. A tour that works perfectly in a desktop browser can fail silently on mobile if the gyroscope toggle never shows up, often because the page was loaded over plain HTTP or because the permission button wasn't wired to a genuine click event. Testing on both platforms before you publish catches this early, when it's a five-minute fix rather than a support ticket from a confused viewer.

Browser and security requirements: HTTPS, iOS permission, and platform differences

Gyroscope navigation depends on a browser API called DeviceOrientationEvent, and that API comes with real restrictions you need to design around rather than fight.

Access to DeviceOrientationEvent is restricted to secure contexts, meaning your tour must be served over HTTPS before any browser will expose orientation sensor data at all.
On iOS, you must call DeviceOrientationEvent.requestPermission() from inside a user gesture, such as a button click; calling it automatically on page load gets blocked.
Android's Chrome and Firefox browsers will usually expose orientation events under HTTPS without an extra permission prompt, but device-specific quirks mean you should still test across a few handsets before trusting the behavior.

The permission requirement isn't satisfied by the function call alone. It also requires that the call happen during active transient user gesture, and that your event listeners attach only after permission is granted, since binding them too early can cause a race condition that fails without throwing a visible error. This single detail is the most common reason gyroscope controls "work on Android but not iPhone" during early testing.

UX best practices: mixing gyroscope with touch, toggles, and fallbacks

Gyroscope navigation feels natural only when viewers can override it the moment they want to. Build these patterns into your tour rather than treating gyro as an all-or-nothing switch:

Keep the gyro toggle visible at all times so viewers always know which mode they're in.
When gyro is active, allow a touch-drag to temporarily take over steering, since forcing someone to hold their phone at an odd angle to see a corner of a room breaks the experience fast.
Turn gyro off automatically during any scripted camera fly-through, then restore it once the sequence ends, so the device's motion data and your animation don't fight for control of the same view.
Offer a desktop-style drag pad or mouse-drag fallback for devices with no motion sensor, and a brief first-time message explaining how gyro mode works the first time someone opens the toggle.

Photo Sphere Viewer's gyroscope plugin reflects this exact philosophy: it exposes a touchmove option specifically to merge touch and gyroscope inputs rather than treating them as competing controls, and it only adds the gyroscope toggle to the interface when the sensor API is actually available on that device.

Pro Tip: Show a brief "tilt your phone to look around" hint the first time a visitor opens gyro mode, then never show it again for that session.

Hands tilting a smartphone during tour viewing

Diagnose and fix common gyroscope issues

Most gyroscope problems trace back to one of three causes, and a short checklist resolves nearly all of them.

If the view looks tilted or rotated from where it should be, check whether your viewer is reading absolute orientation data versus relative orientation. Capturing the device's yaw at the moment gyro is switched on, then applying only the deltas from that point forward, fixes the vast majority of offset complaints.
If the sensor appears unavailable entirely, detect that condition explicitly and fall back to touch controls with a short message rather than leaving a toggle that silently does nothing.
Work through a fixed test sequence every time: confirm HTTPS is active, confirm the permission prompt actually appears on iOS, test on at least one Android and one iOS device, and log raw orientation events to the console while debugging so you can see what the sensor is actually reporting.

Pannellum's gyro documentation notes that device reporting varies enough between manufacturers that calibration, not your tour file, is usually the real culprit behind rotation offsets.

Implementation checklist and code patterns for engineers

For engineers wiring this up directly, the permission pattern is short but strict: call DeviceOrientationEvent.requestPermission() inside a click handler, check that the response equals 'granted', and only then attach your deviceorientation (or deviceorientationabsolute) listener. Requesting permission anywhere outside that gesture window gets silently blocked on iOS, per MDN's documentation.

Two popular viewer libraries expose this through configuration flags rather than raw API calls:

Library	Relevant options	Platform notes
Photo Sphere Viewer	absolutePosition, touchmove, roll, moveMode	Adds gyroscope toggle only when sensor API is available
Pannellum	orientation, orientationSupported, orientationActive	iOS requires permission gesture, Android grants directly, desktop reports unsupported

Keep the permission request entirely client-side. Routing it through a server call or delaying it past the original click event is the single most common way engineers accidentally break the iOS prompt. Also expose a simple sensor-available flag to your UI layer so the toggle itself can show "checking," "inactive," or "gyro steering" states, which makes field reports far easier to debug.

Simple Virtual Tour support and resources for gyro-enabled tours

The platform enables creators to publish unlimited interactive tours for real estate, tourism, and similar spaces without needing a development background. It supports both cloud-hosted and self-hosted deployment, so users can keep control over their data and avoid ongoing costs if they choose the self-hosted route.

A few resources we've published go deeper on the mobile side of this:

Our guide on mobile-friendly real estate tours covers why mobile-optimized navigation, gyroscope included, tends to increase listing engagement.
Our mobile optimization walkthrough expands on testing and preview workflows beyond what fits here.
Our step-by-step piece on building interactive tours from 360° panoramas covers the scene-assembly steps that come before you ever touch a gyroscope setting.

Gyroscope controls earn their place fastest in mobile-first real estate and tourism tours, where moving the phone to look around a room creates a sense of physical presence that swipe-to-rotate simply doesn't match. If your analytics show desktop-heavy traffic instead, we'd suggest spending your time on other mobile-friendly improvements first and keeping gyro as an optional extra rather than a launch priority.

— Andrea

Try Simple Virtual Tour to publish gyro-enabled mobile tours

Gyroscope-ready publishing is part of the standard workflow, not an advanced add-on users have to hunt for. Whether deploying on a cloud service or on a private server, tours can ship with mobile navigation built in from the first scene created.

Start on our Free Forever plan to publish your first gyro-ready tour at no cost.
Compare the XS, S, M, L, and XL tiers, or the one-time CORE package, on our buy page when you're ready to scale up.

FAQ

Motion sensors add a modest continuous draw while active, similar to using a mapping app with live orientation. Turning gyro off when a viewer closes the tour or switches tabs keeps the impact minor.

Do I need separate code for Android and iOS gyroscope support?

You need one extra step for iOS: calling DeviceOrientationEvent.requestPermission() inside a user gesture before listening for orientation events. Android's Chrome and Firefox typically expose the same events under HTTPS without that extra prompt.

Why does my tour's gyroscope toggle not appear at all?

The toggle usually stays hidden because the page isn't served over HTTPS, since DeviceOrientationEvent access requires a secure context. Confirm your test or live URL starts with "https://" before troubleshooting anything else.

What's the difference between absolute and relative orientation modes?

Absolute orientation ties the view to real-world compass direction, while relative orientation tracks movement from wherever the viewer started. Most tours feel more natural in relative mode, since it avoids the sudden jumps that absolute mode can cause when a device's compass reading drifts.

Can I build gyroscope-enabled tours without writing code myself?

Yes. Some platforms expose the gyroscope toggle directly in the editor, so mobile motion navigation can be enabled through settings rather than writing permission-handling code manually.