A little more than a year ago, Rabobank’s Frontend Platform team “Darwin” did a stunning demo of a proof of concept. They showed our existing retail banking application, running our Senses 1.0 platform (based on AngularJS), inside a host application created with Ionic 3, with some functionality re-implemented using Ionic, leveraging Ionic’s built-in transition animations. Technically, we proved that Ionic has many things which would make it a good fit and to form the basis of our new platform: Senses 2.0 (based on Angular). We also showed that it was possible to make the migration happen step by step, because we could run both incompatible versions of the platform side by side in one mobile banking App. The audience was enthusiastic too, developers, product owners, product managers alike: from that moment on there was talk about a possible migration to Ionic.

I’ve been correcting people who asked about the status of the “Migration to Ionic”, saying that we’re building a whole new platform, we’re not “just” migrating to Ionic. The thing is, it needs to fit into a bigger picture. We need a solution that scales with our organisation and that fits existing infrastructure, so we can’t just implement any new framework without further consequences.

In February of this year, I went to ngEurope 2018 in Paris, where I got to spend some time with Adam Bradley and Manu Mtz Almeida -both great guys by the way- from the Ionic team. I got the chance to get into a good discussion on how I saw Ionic fit our architecture, and validated some ideas (and got some new ones too!). When I came back in the office I was ready to fill in the blanks of the new Frontend Architecture. Yes, we would use Ionic, but not like most would use it.

The other day I was asked to speak at an internal meetup that goes by the name Go4IT to explain how we use Ionic at the Rabobank. The speaker before me would introduce all elements of the Ionic ecosystem, so I thought I’d use his outline as a checklist to see what parts we’re actually using. Let’s go through it together…

One of the most eye-catching features of Ionic of course is the UI component Library that comes with it. The components are extremely high quality, they’re small in size (and therefore fast to load), their appearance morphs into the style that the users expect from the device they’re using. In short: they have a great UI Library.

But we don’t use it…

That may be a bummer. Let me explain…

At the Rabobank, we have our own UI Library, called RFS. RFS is a UI Library, along with a Style Guide, that is the materialised version of the Rabobank Design System, RDS for short. All RFS components are well specced, have BDD scenarios that describe the expected behaviour, and they fully comply with RDS. We cannot just take any UI library and use it instead. Besides, we can’t predict the future. If we decide in a couple of years from now that we want to move away from Ionic, we’d be stuck with a combination of for example rfs-output-money together with ion-button.

Instead we’ve decided to continue to use RFS. That’s our UI Library. If and when we want to use certain Ionic UI components, we’d wrap them in a new RFS component, and make it available under our own namespace. That means that our rfs-button could -in time- perhaps be a wrapped ion-button. But if we later decide to replace it with a new and shiny new button from the CoolFramework, it’s still an rfs-button and we’d save us the trouble of going through all our code and replace every ion-button with cool-button (which, I didn’t mention yet, of course has a different API too…)

Another great feature of the Ionic Framework of course are the Ionicons. It’s a free icon set with many different icons for both iOS and Android. However, they’re very generic icons.

If you have a website and/or an App, you’ll want to brand it as your own. That means brand-specific colours, styles, but also imagery, and therefore brand-specific icons.

Part of our RFS library is the RFS Icon Font. We have icons for all our products, services and actions in our App. There is no way we can manage with the Ionicons set of icons, and the styling doesn’t match the Rabobank style.

So: no, we don’t use Ionicons.

Historically, the way to create hybrid native apps, was to use Phonegap/Cordova. Until recently, Ionic integrated with Cordova out of the box as the only option. Recently Max Lynch -again, from the Ionic team- took the initiative to create Capacitor. A newer and better way to achieve the same goal: a native build for your hybrid app. Of course, this is now the preferred way to create a native app from your Ionic project, but you can still also use Cordova.

We at the Rabobank have one thing that is more important than anything else: security. We cannot fail on this point. And we all know people get creative in all possible ways to try and hack our systems. And let’s face it: web code is much, much less secure than compiled Native code. That’s just the starting point: many measures are built into our Native App to improve security. To make sure our customers can be certain the most sensitive parts of the banking application are also the most secure parts, we implemented those in Native technology. To just name the most core and secure functions: logging into the app, and the signing of transactions are Native functions.

Therefore, we have two dedicated Native teams (Cherokee and Navajo) that create and maintain our own iOS and Android apps, which run the Web application as soon as you’re logged in (using Native technology).

We don’t use Cordova. We don’t use Capacitor. Why? Because Security.

The Pro Package is where the people behind Ionic make their money. It’s a set of paid services that add value to the Ionic ecosystem, but are optional to use. Let’s see…

Creator is a drag-and-drop wysiwyg user interface builder. It’s great to quickly whip up a prototype of a new feature you’d want to build. It would be nice if a Product Manager would be able to use it, and hand it over to the team to actually build it. It generates code that you can really continue to work on. Great! However, it assumes the UI components that you choose from are Ionic’s own components. And as you read before: we don’t use Ionic’s UI library, but our own. So, unfortunately, we can’t use the Creator.

Deploy is a cloud-based solution where you can push your updates to Ionic’s private cloud and distribute your new versions without going through the App store. For now, this is not how we distribute our code. In another post I’ll get back to the way we deploy our code. The essence here is that Ionic assumes the web assets are distributed to the device that runs your app. Through Ionic Deploy, you can update these assets on the fly, while keeping the same Native build. Since we distribute our code differently, the Deploy service is not for us.

Package is a way to create your native builds in the cloud. It’s great for those who want to create an iOS build and don’t have a MacBook for example. However, since we don’t use Capacitor or Cordova, this option won’t work for us either. We create our own native builds.

Monitor is Ionic’s service to keep track of the use and runtime errors of our App. I haven’t tried it, but it’s great to have such an integrated service. Within the Rabobank we use Splunk for exactly that. We don’t only use it for keeping track of what happens with our Frontend code, but basically everything we want to monitor, frontend or backend. It makes no sense to use Ionic’s Monitor service, when we already have an integrated solution for this purpose.

To summarise: we don’t use the Ionic Pro package

Ionic of course comes with the Ionic Command Line Interface. It’s a great tool to generate a new template project, to manage the integration with Cordova or Capacitor and to manage the integration with Ionic’s Pro package.

However, as you’ve read above, we don’t use Cordova or Capacitor, nor do we use the Pro package. And as for generating a new template project, we’d rather do it The Angular Way, meaning: use Schematics!

So again: no, we also don’t use the Ionic CLI

You may ask yourself: what is left? Are you actually using Ionic? Well, yes!

We use the Ionic Open Source Framework. Especially its application shell is something that fits our needs very well. In our current platform -Senses 1.0- a sub project is called “Senses Shell”, which for the most part has the same functionality as the core of Ionic.

Another thing is Ionic’s concept of Pages. This may sound silly, or even trivial, but thinking in Pages rather than ‘routeable components’ as Angular does at its core, fits our way of thinking about the application logic much better. Besides, in Senses 1.0, pages are also viewed as a separate entity, and are even managed outside of the Frontend Platform by our Content Management System called Tridion. Tridion won’t be a player in Senses 2.0, but we want to continue to keep thinking in Pages that contain Features.

Besides this, to run our application in both the App as well as in the browser, we need device-specific behaviour and environment abstractions. This is something where Ionic excels out of the box. As platform developers, we still need to write our code and think carefully about what happens on which OS. But we want our feature developers to be as agnostic about the runtime environment as possible.

We are very enthusiastic about the entire set of services of Ionic. If we could, we would probably use more of them. But the relatively small part of the Ionic Framework that we’re using, we’re very happy about!