Upgrading from Capacitor 2 in 2024 - Part 1
Published: 2024-04-17 09:05:50

---
title: Upgrading from Capacitor 2 in 2024 - Part 1
published: true
description: Start of the migration from Capacitor 2 to 5
tags: 
cover_image: https://s3.eu-central-1.amazonaws.com/reconcept-dev.to-assets/capacitor/Part+1.png
# Use a ratio of 100:42 for best results.
# published_at: 2024-03-27 14:59 +0000
---

The first step was trying to estimate the amount of work that needed to be done. This resulted in the following plan:

### #1
Lay the ground work
- update Capacitor to v4, fix plugins that are not compatible
- update Capacitor to v5 (latest), fix plugins that are not compatible.

### #2
Then update rest of plugins:
- FilePicker
- FileOpener
- Photoviewer
- Camera
- App Review
- Biometrics
- Notifications

We weren’t sure if we could even build the app while upgrading to test the individual parts, so even the first step could become a huge hurdle before we even got to see the results. For this reason we estimated this could take over 1 sprint to do, but if we don’t start now it won’t become any easier either.

So we just started and would see what happens. We have the daily standup for check-ins, to see how it’s going and if we need to change our approach or maybe get some extra help.

## Migration to Capacitor 4.

The Capacitor CLI provides a migration tool that can be run to easily update the Android & iOS specific files, so we don’t have to manually go through the platform specific configuration files. We followed the instructions in the [Updating to 4.0](https://Capacitorjs.com/docs/updating/4-0) guide, the files were updated and the only thing left to do was try to start up the app and see what needed to be fixed.

The next step was upgrading the local Java version from 8 to 11, which was required for Android. 
Then we needed to migrate from `@Capacitor/storage` to the new `@Capacitor/preferences` and thought, this is where the ‘fun’ begins.

But luckily the API of the new `Preferences` and `Storage` were basically the same, and we were happily surprised that the app immediately started and we were able to use the outdated Cordova plugins with the new version
This means we can easily migrate each plugin and test it without having to change the entire application.

Hopefully the migration to the next version is just as easy…

## Migration to Capacitor 5: A New Hope

For the migration to the next major version, we followed the next migration guide [Updating to 5.0](https://Capacitorjs.com/docs/updating/5-0). However, we also noticed a page [Updating plugins to 5.0](https://Capacitorjs.com/docs/updating/plugins/5-0). This page described the things the plugin developers needed to do to upgrade to the latest Capacitor version.

Surely this would mean our smooth sailing would be over?

We started the migration using the `migrate` command from the CLI, updated Java to version 17 and started the application.

Again, the build succeeded and the application started. At first a sigh of relief, but when we tried to login to the application we were met with an ‘invalid credentials’ error.
After some digging, we found that the `ionic-native/http` plugin we use for logging in, could not handle the secure cookies. This was due to a change in the android manifest file by the migration:
from: 
```<data android:scheme="nl.reconcept.portfolio.universal"/>```
to
```<data android:host="reconcept.app" android:scheme="https"/>```

To fix this, we used the Capacitor provided plugin `CapacitorHttp`, which has built-in cookie handling. Luckily, changing the code to use the new plugin did not have any big complications and when it was done we were able to login again.
Our expected struggles did not happen, which allowed us to update the features one by one. This was very good news and gave us hope that the rest of the project would be a lot less work.

But, when we started work on upgrading the Cordova plugins to their Capacitor counterparts, we were met with some tricky differences.