The problem
A browser header bar. A browser-style back button. Web-style tabs. None of it matters on a normal Swoogo microsite — until that microsite loads inside a client’s own mobile app instead of a browser tab. For this client, the agenda widget wasn’t just a page to browse. It had to disappear into the app around it. Any leftover browser chrome broke that immediately.
The approach / solution
- Built the mobile-app agenda widget directly inside Swoogo’s own Twig templating system, since that’s the only route its page builder supports.
- Refined it across three successive versions as the client’s requirements changed. This wasn’t a one-off build; it kept evolving alongside the app it lived in.
- Hid the browser-style header so the widget reads as a screen inside the app, not a loaded web page.
- Fixed the back-button behavior inside a modal view to match the app’s own navigation patterns.
- Redesigned the tab bar to match the mobile app’s native tab conventions.
Outcome / result
Three versions later, the widget runs as a screen inside the client’s mobile app that a registrant wouldn’t mistake for a web page. Header, back button, tabs — all of it matches the app around it now.
Why it matters for enterprise event-tech
A bank’s mobile app carries strict expectations about what “native” looks and feels like, and a registration flow that breaks that illusion undercuts trust at exactly the wrong moment. Building it this way gets a financial-services client an in-app-quality agenda without the cost of a second native app screen just to hold it.
