From web to mobile: How we navigated the transition at Hedgehog

Igor Dudenkov, Head of Mobile @ Hedgehog

When I joined Hedgehog in August 2022, the team had recently launched an MVP in the form of a web app. Central to the MVP journey was a commitment to delivering an engaging UI/UX for individual investors. As Ole Mahrt, our Head of Product, mentioned in his previous blog, the focus was on reimagining the way in which individuals invested in real assets.

But to truly revolutionise real asset investing and deliver the UI/UX that a modern consumer demands, we knew we had to develop a mobile app to complement the web experience. This conviction was further strengthened by early user research, which indicated that the majority of Hedgehog sign-ups came from iPhone users. So, my first task upon joining was to launch a mobile app on the iOS platform. An exciting start, to say the least!

The challenge wasn’t entirely new to me. I had previously worked for a big fintech in the UK, giving me valuable experience working under pressure and meeting strict deadlines. I also had more than 8 years of experience in iOS development, so I had a deep understanding of the platform and its intricacies. This experience, combined with my desire to build an app from start to finish, helped me embrace the challenge.

Getting out of the blocks

We quickly realised that it would take quite some time to replicate all the existing features in an iOS app, so we first had to establish our key requirements. As part of that process, we determined that we wanted to extend both platforms (web app and mobile app) in a way that didn’t structurally disadvantage either platform. We wanted Hedgehog to be equally accessible on mobile and desktop, so that the end user could decide how to use our platform. In addition to that, we wanted to be able to make changes to our platform as quickly as possible, responding to user behaviour.

Eventually, we came up with these requirements for building an iOS app:

1. The app had to provide the same UX/UI as the one we had already developed for our web users
2. As an early-stage startup, we had to have the ability to make changes to the app quickly, and we had to minimise the risk of blockages coming from Apple’s review process
3. We wanted to hold ourselves to a tight timetable of three months to release the app

With these requirements in mind, we decided to build a hybrid mobile app, leveraging existing web pages that had been built on React, a mobile-friendly software framework.

In doing so, we could quickly release an iOS app that would run a web app under the hood, but at the same time, offer us the ability to replace web pages with native screens in every new app release. Ultimately, the iOS app would become fully native.

Architecting our hybrid mobile app

We wanted to build our hybrid mobile app in such a way that any web page would run in a well-isolated native wrapper that could easily be replaced by a native page at any time. In addition, a web page which is running in a native wrapper must have access to some capabilities provided by the mobile platform. For example, one of those capabilities might be initiating a KYC process by using a native SDK.

With these considerations in mind we defined the main aspects of the native foundation of the hybrid app.

Native Navigation: allows a mobile app to control the whole user navigation. Instead of embedded web pages opening other web pages, the native part of the application would intercept the users actions and open either another web page or native screen.

In this way, we were achieving two things:

• The App would feel more native, as most of the transitions were native
• Going forward, we could replace a web page with fewer code changes, because any web page was consumed as a native screen

Bidirectional communication between web and native: this functionality introduces communication between the web pages and the native part in runtime. There are many cases where we want the web page to notify the native part of certain user actions and vice versa.

User session management: this enables native parts of the app to take care of user authentication, including user registration with Hedgehog. This way, we can actually bring our hybrid app to a state where it only reuses some web pages, but behaves like a standalone native app under the hood. This includes the following parts:

• Sign In & Sign Up also supporting social accounts (Using native SDKs)
• Updating auth credentials if necessary
• Logging out the user on the device

With this approach in mind, we started from breaking down the existing functionality and features of the web-app, determining what we wanted to make native and what could remain in the web.

Here is the complete list of what we wanted our hybrid app to do natively:

• Sign In & Sign Up
• Native Navigation
• User verification (KYC)
• Viewing and Downloading Documents
• Push Notifications
• Deep Linking & Universal Links
• User Acquisition Tracking & Analytics

Building our hybrid iOS app

While we were developing the hybrid app, we overcame a lot of technical problems, and I would like to touch on some of them that had a direct impact on the user experience.

The first problem we had to solve was the seamless transition from the native part of the app to the one that relies on web screens. To be more specific, the web screens we reuse in an iOS app require user authorization, but user authorization happens just before loading any of the web pages in the native app. So we wanted to avoid users having to login again when they viewed embedded web pages.

We knew that our web-app retrieved authentication credentials from local storage. Using client-side JS code injection, the native part of the application was able to store the credentials in web local storage, which ensured a smooth transition to the web part of the iOS app.

Client-side JS injection has been heavily used to address other issues and has helped us achieve a robust user experience so that the end user doesn’t notice that they are crossing the line between native and web.

Obviously, there are many other implementation details that I have deliberately omitted in this article, mainly focusing on the reasons that led us to create a hybrid mobile app and the decisions we made during development. However, the decisions outlined above were critical in enabling us to meet our targets; namely, to deliver a mobile app that complemented our web app in its UI/UX while not only releasing it but also updating it as quickly as possible in the process.

For those out there also trying to navigate the transition from web to mobile, I hope this article has given you some useful insights for making this transition as smooth as possible.