This article first appeared on the Triplebyte blog and was written by Aphinya Dechalert. Aphinya is an Angular-heavy, full-stack developer embarking on a series of learning projects with defined outcomes, documented through Medium and LinkedIn.
Once upon a time, I was part of a software development project that had an Angular-based front-end connected to a Java-based API. The decoupled layer made it possible to reuse the back-end in other spaces, and our Java dev did that cleanly for our mobile Android app ... until that person left the team.
What happened next was, in perfect timing, our boss decided we needed to add on iOS app to our suite – one that would launch alongside a refresh of our Android app. Since everyone remaining on our team was Angular-based, the way to get this done would obviously be to hire a couple of new native app developers, right? Wrong. The task fell to us. And though we all knew how to read and write Java, jumping into an Android development environment when we’ve been working on the front-end for so long seemed like it would have been a potential recipe for spaghetti code. Never the less, the team and I had to buckle down and make these new mobile apps a reality – and in a reasonable timeframe.
Hybrid apps became our solution.
Hybrid apps in a nutshell
For the uninitiated, a hybrid app is a mobile app that is installed natively on a mobile device. However, rather than being developed specifically for Android or iOS, it's created on a different platform that compiles to be compatible with the native and operating system.
These hybrid apps often come with wrappers that allow them to be installed on the device, but under the hood, it is actually something else. For example, Ionic and React Native are JavaScript-based frameworks that have the ability to create cross-platform native mobile apps without the need to code in Java or Swift.
The idea behind hybrid apps is that they are coded once and deployable across different platforms. It is often used to cut down costs and development time required to create and deploy a feature or change. Parts of this code-once, deploy everywhere setup can also be extended to other platforms such as web and wearables.
While all this sounds great, how does it really stack up in real life? Back to my story...
Getting up and running
In our hybrid app scenario, we already had the Angular modules and a fully functioning suite of APIs. This meant that all we had to do was put our elements into Ionic, our platform of choice.
What did it look like in code?
Structurally, every layer of the Angular app that was available on the web application was good to go in the Ionic app. To do this, we installed and ran Ionic's tooling, which allowed us to tap into Ionic's CLI.
npm install -g @ionic/cli native-run cordova-res
We then created a blank Ionic Angular app using the --type=angular flag. For example, starting up a hypothetical shopping Ionic app would look something like this:
ionic start shopping --type=angular
This will generate the scaffold files required to get you started. Once this is done, the Angular app sits inside the src folder. This allowed us to leverage our Angular knowledge and continue with the code as per usual.
So rather than building everything up from scratch, we just transposed all the other layers – the component, the factory, and service layers – over and created a new interface that was more geared for a mobile experience.
The good news: With only minimal bits of new Angular code needed to polish things off, we delivered on time.
It worked well and not so well
Now, despite this easy, breezy experience, I'd never go so far as to claim that native app development (and native app developers) don't have their merits. For one, the ease and accessibility of a native mobile app provides additional business opportunities, like simple push notifications.
The biggest issue that we had was keeping the desktop web version in sync with the native mobile code.
This is because we ran two different repositories and changes in one didn't always translate that well to the other. Over time, the team got split into two groups and new members came on board. Trying to keep the common parts between both repositories in sync became a mission that everyone eventually slacked off on.
After the team split and a few sprint cycles, the repositories moved so far away from each other that trying to swap code could potentially induce unnecessary bugs. This came up due to the lack of structural understanding from new developers who later joined the team. Each had their own idea on how to create modularity inside Angular but failed to consider the wider context of its usage between the two apps.
Even still, there were definitely things specific to the hybrid app approach we loved. For example, the ability to rapidly develop for both Android and iOS by using a hybrid app platform let us easily experiment and create A/B testing campaigns for visuals through external connections and configurations that didn't require any code updates. When data is king, testability is the queen.
Final thoughts
All in all, as the project veered off into its own spaces and the common code lost touch with one another, it begs the question: Was it worth it?
The answer is yes.
We had an objective with clear time constraints. Putting Angular into Ionic gave us breathing room when our team was understaffed and lacked the time to properly pick up a new skill. It also allowed a predominantly web-based team to quickly foray into the native mobile space and produce a robust application that everyone understood. It worked well when we translated existing code to Ionic.
The messiness only began when we started becoming too relaxed with ourselves and disregarded the long-term relationship required between the two applications to maintain the common code.
The speed of the sprints and the divergent trajectories eventually broke the general gains on the mobile app and its ability to share code with the web version. Trying to refactor one app to be like the other over time lost us the edge we originally had. As a result, the speed of development for both applications slowed as refactoring took over.
Despite all this, the hybridization provided a learning experience into how to deal with mobile apps – and the skills picked up from it were transferrable when we switched over to a Flutter and Kotlin stack.
Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.
Top comments (0)