Hybrid applications combine native and web application parts. The latter allow us to reuse code for specific parts across platforms. If you’re using an iPad for learning with Babbel, you have already been in touch with those. Since a few months ago, all trainers for iPad are now implemented via web technology, mounted to a WKWebView. It’s the same code that is being executed when using Babbel in a desktop browser.
This article wants to give an idea of why and how we introduced web technology to our mobile apps, starting with iPad with the goal to bring it to iPhones as well as Android devices, too.
Introduction
The composition of learning content, didactical concept and user experience is one of the many domains inside Babbel’s tech department. Being a learning company inside-out, each of the disciplines evolves continuously. To let our learners benefit from this in most efficient ways means to reduce uncertainties when it comes to implementation strategies. Catering our service to multiple different platforms, this premise has moved the focus to review our trainers. Unless learners are provided with the same UX for each platform, it is difficult to ensure equal learning experience with our service.
Maintaining trainer implementations across different environments and platforms has benefits and trade-offs. Native implementations of trainers ensure better performing animations and user interaction, whereas a Web-based implementation erases almost any overhead for maintenance, due to a shared codebase and a standardized runtime environment. With HTML5, Web technologies are providing us with a good standard for user interactions and device APIs.
These aspects aside, as Babbel is growing for more than ten years now, the engineering department has also built up a legacy of its own. Speaking from my experience, the more you identify with the mission of a project, the more you become attached to the work you’ve put into the code you write, the concepts you draft, the time you (have) put into this.
It is not easy to let go, but we decided to do so.
Why – Origin / previous stack
Babbel iOS
Alike all early iOS applications, the Babbel App’s source was written in Objective-C. With growing demands to engineering and new engineers joining Babbel after 2014s introduction of Swift, its share in the source has grown to a point, where only a relatively small set of trainers represent a legacy in Objective-C.
Babbel Web
For learners that prefer using a desktop browser for learning, trainers were implemented with a proprietary framework in JavaScript (ES5) called b3. We started moving to React in 2017, replacing the b3 framework step-by-step. As of today, similarly to iOS, only a small part of the Babbel web application is still implemented with b3.
Motivation
To prepare our app for SplitView, we either needed to refactor the native trainers or port the Web implementation of the trainers to the iOS application. Both options would put a halt to the development of new trainers. A task with no immediate value to our learners, but one that would enhance sustainability due to the benefits of web standards.
On the other side, the web implementations of trainers were not completely covering the mobile equivalent features – a state which makes it difficult to predict learning experience too.
Ultimately, with moving to a common code base for trainers we expected to gain benefits by reducing the overhead in trainer maintenance and faster iteration of trainer development.
How
Tech scope
The Babbel web application is using ReactJs with Redux. Except for the b3 legacy, Its codebase is written in ES6. Webpack is configured to use babel loaders and style loaders for building bundles, which are either deployed via Amazon S3 buckets or bundled with the iOS application.
For porting the Lesson Player’s code base to iOS, data providers, authentication, user input and layout demanded refactoring. HTTP based interfaces are bridged via resource handlers on iOS side, covering data and authentication.
Fail early – Evaluating WKWebView
In order to consolidate our strategy and to assess potential risks of this endeavor, a task force was formed which we dubbed “Will it blend?”. They were given two months of time to evaluate in an iterative fashion the following uncertainties:
- regression in user experience
- hardware demands in terms of CPU and memory
- reliable speech recognition
- integration test compatibility / required refactoring
- offline support and file management
- release process
Those evaluations yielded very useful information and gave a good idea on what we would have to focus on:
- Handling user input – especially the impact of the software keyboard being presented/animated required adjustments to the web components.
- Network availability – due to differences in storage size and accessibility, native applications can be expected to allow custom caching mechanisms and preloading, which allows to implement a different application flow as well. For the Lesson Player integration, it was necessary to emphasize these differences in behavior. Instead of writing to the Lesson API after a lesson is completed, those requests are now delegated to the native application.
Lesson Player: web application flow
Lesson Player: ios application flow
Current state
With our recent release to iOS, we reached a big milestone, by replacing the native writing review with one based on web view. Before, web technology was only used for trainers when learning with an iPad. We’re looking forward to complementing our experiences with similarly successful contributions to the Android platform soon.
Trainers
Learning content is provided in lessons that contain several exercises. A Trainer is a module that contains the logic for how a lesson segment is presented and how user input is processed.
Photo by Alexandre Debiève on Unsplash