This is not the first time I've upgraded any react-native projects.

I've done it a few times over the years and will be sharing out what I've learnt so far.

To give you some context regarding the topic, the very same project was upgraded to `0.59.10` since the creation with `react-native init`,
to comply with the Google Play store regulation for having 64 bit version of the app.

Everything works out fine with `0.59.10`, for the next couple of months.

Especially one that need to deal with linking of native libraries, most of the packages have no issue with the good old `react-native link` command.

With that said, I can focus on building features and be very productive with my hours spent working on projects (personal or client projects).

Which makes me fully occupied with work, and thus not having time for writing/bloging.

Now, let's get back to the topic.

 

#### 1. Before the upgrade

Before any major upgrade (i.e: `0.5x.x` to `0.60.0`), you need to know things are going to be broken, libraries will have issues,
deprecated API(s) will affects your app (rather than just deprecation warning), module dependencies and UI look or behaviour will have impacts.

There are a lot of stuffs that can possibly went wrong. So keep in mind that, upgrading is one part, regression test for your upgraded app is another part.

For any version upgrades you are going to perform, it is a good practice to have an overview of your `dependencies`, spot for native linked libraries and do a quick check on the potential issues after upgrade.

For non native linked library, there might be issue is there is a major changes in `react` version itself, but most of the time this will no less of a issue.


In my case, there are 116 packages(dev packages excluded) installed at the point during my upgrades, and 38 of them are natively linked.

So I am sure it's going to take time for the upgrade to complete. Plus after some searching the internet, I am very sure that the upgrade cannot be completed in
just few hours of time (in my case).

 

#### 2. Reasons for upgrade

So now you are aware that what a major upgrade will be like, and the time that it will take.

If there are no major blocker that are holding you back with the current version, I would suggest delaying the upgrade for a few reasons:

- Buffer time for libraries maintainers to support the latest feature/changes with `react-native`
- Don't fix what isn't broken (with trying to upgrade)

Do it when you are in better position (let say you are ahead with your timeline), or when you have absolute no better choice than to upgrade (i.e: to upgrade to 64 bit support.)

If you are in the midst of some feature, and that feature requires for a `react-native` version upgrade before continuing, I actually suggest going with alternatives if you can. Or do the upgrade separately, and do enough testing after the upgrade, otherwise you will find yourselves in a rabbit hole trying to fix some errors of another issue in order to make some other issues resolved. You don't want that.

For example, App Store stops accepting app with WebView since April. You need to use `react-native-webview` (from a specific version onwards), and have your `react-native` project to be at minimum xxx version.

You thought upgrading is the only option. Well if you are in good hand, for example your project is new and have less dependencies. Upgrading seems like a good choice if that is the case.

Otherwise you want just settled with the alternative, for example, removing the RCTWebView with a script that run on a `postinstall` or `after_install` Podfile, and you are good to god.

Chances are if you proceed with the upgrade, your `react-navigation` verison will not compatible with the new version, and you need to upgrade `react-navigation` as well. Say, from `v3` to `v4` with some changes in behaviour. (More on this later)

 

#### 3. Which version to upgrade to

If you are like me, who delaying the upgrade until you have no other choices. Chances are, you have a few major versions to choose from, since the release schedule of React Native now follows a monthly release train.
So the question for us is which version to use?

Well, if you have a major upgrade, normally I take the latest version within the major upgrade.
Depending on the major version of your choice, for my case from `0.59.10`, I can upgrade to `0.60.x`, `0.61.x` or `0.62.x`. (`0.63.x` release candidate are not into consideration)

To have an overview of the available version, use this command.

`npm show react-native versions`

My choice of upgrade is to get the latest stable version for this project. Cause if I don't do that, I will need to upgrade again sooner, and I am having huge backlogs in the pipeline after the upgrade. So I want to maximize the window before the next upgrade.

Bear in mind that the latest stable version might not always be the best choice to upgrade to. Sometimes you want to upgrade to a version lower that that.

Reason for that is the latest stable version might have breaking chances that no open source libraries has adapted yet.

How to know which to choose from?

1. Inspect your `package.json` file and have a look at the `dependencies` to get an idea. You are the developer of your project and should know more about which libraries will more likely to break after the upgrade.
2. Have a look at [release changelogs](https://github.com/facebook/react-native/releases)

 

#### 4. How to upgrade

 

##### 4.1 Clone the project folder

I used to do it in a separate branch, but for this particular upgrade, I am doing it in a cloned folder.

Note: Not cloning from remote and reinstalling everything, I copy/pasted the entire folder to a different directory and start working on the upgrade.

Reason?

1. I don't want to re-installing the `node_modules` and `Pods` when I already have it.
2. The cloned project will build and run without issue.
3. I don't want to switch branch and then my existing branch is messed up with my upgraded libraries (`node_modules` and so on).
Upgrade is going on, same goes for bug fixing and feature development. I am still actively developing on the non-upgraded branch.
4. If the upgrade gone haywire, I can discard the changes in clones folder and not affecting my development flow. And start over again from the cloned folder.

You want your app to still working if you decided to abort the upgrade half way, or start over again. (Yeah, sometimes, you just have to start over again.)

While juggling betweeen bug fixing, new features development, some optimizations, maintaining the code and version upgrade, I want to avoid the upgrade to potentially stop me from my regular work flow.
If the upgrade went wrong, I can still fix bug and ship new features of my app to App/Play stores on the main project.

##### 4.2 Use React Native upgrade helper

[React Native upgrade helper](https://react-native-community.github.io/upgrade-helper/)

Check for code changes before applying it in the project.

Optionally, you can upgrade with `npx react-native upgrade`.

However, from the memory of the time I last used it, I don't have a good experience using that.
I have to resolved conflicts and the worst part was changes on iOS `project.pbxproj` files which is a pain.

Ever since then I use upgrade helper and hand-picked the code and manually apply it to my existing project.
I am happy with that and is aware and consious of what I've changes, so I know where to look for if anything went wrong.

If my case, upgrading to `0.62.2` only need to change 15 files, which is faster to do hand-picked. (Imagine the time spent on fixing conflicts could be more than that)

Plus, I can exclude the implementation of `flipper` which is a debugging tool included in future versions of `react-native`.

Hand picking the lines makes me aware of the additional stuffs that are added (in this case, `flipper`), and I am not including it this time.

Reason for doing so is to not have some extra dependencies or code to fix.

I just want to focus on the upgrade and I can live without the debug tool for now.

Since coming from `0.59.10`, I am using my other debugging tool, might as well not introduce uncertainties that will break the product.

I will give `flipper` a try afterwards, but for now, the upgrade is in highest priority.

After applying the code changes (or if your are using the upgrade command). Run `yarn install` (or `npm install` depending on your setup.)

##### 4.3 Get your project up and running

After installing the versions, if there are no errors. You are good to go to start build and run the project.

Assuming the new packages have no issues, you need to fix the build issues with you app and get it up and running like before.

The following are the issues that I've encountered and the solution to it.
I always start debugging with iOS build with xcode. (Just a preference)

1. Run `pod install` and bump into `- ERROR | attributes: Missing required attribute `homepage`.`

Since `0.60.0`, native libraries are now auto linked. That means you don't have to specify the pod in your `Podfile` anymore and React Native will pick that up. (some changes to `Podfile` requires)
And for this reason, native libraries are required to have a `.podspec` file for that to work.
If the `homepage` are set to empty string `s.homepage = ''` you will get this issue.

I am getting this issue for this package `https://github.com/Aminoid/react-native-activity-recognition`

The fix: Fork the repository and add a homepage to it. (There are another issue with this library's podspec, so forking the library is a better choice, more about this later)

2. `CocoaPods could not find compatible versions for pod "React/Core":`

This is a issue with `react-native-image-crop-picker` library. Upgrading the library will fix it.
Since the dependency is now `React-Core`.

3. `YOUR_PROJECT_PATH/node_modules/react-native/React/Modules/RCTEventEmitter.h:8:9: 'React/RCTBridge.h' file not found`

Got this issue for `react-native-audio-recorder-player`. As you can tell, upgrading the library will fix it.

4. `'React/RCTDefines.h' file not found`

This one has to do with `AppCenter` packages.

And the fix for this is well documented [here](https://docs.microsoft.com/en-us/appcenter/sdk/troubleshooting/react-native).

5. `<React/RCTBridgeModule.h> file not found`

Now this is the real tricky part.

At this point, the header file is missing, and we are not sure, whether it is an error that only happens to this library only or all other libraries.
For this, there is a way to inspect the issue.

This is very well written in this Github comment, so I am not going to elaborate futher.

https://github.com/facebook/react-native/issues/26665#issuecomment-571082076

In short, I have to remove the `target.remove_from_project` from `Podfile` `post_install`

then

```
pod deintegrate
pod cache clean
pod install
```

(not enough with just removing the `Pods` directory)

and add the missing react back to scheme > build (for all the targets!)

6. Remove from `Libraries` folder in xcode, all the `.xcodeproj` and all the `xxx.a` from `Build Phases > Link Binary with Libraries` from native libraries if you haven't.

Or use `react-native unlink` (but again, I do it manually from xcode, because I don't want to unlink for android yet, as it turns out, android works without unlinking, but is is now redundant.)

Otherwise app will have duplicated headers from Pods and the Libraries projects.

7. `MKTouchableManager.m:11:9: error: 'UIView+React.h' file not found with <angled> include; use "quotes" instead`

Then I am having this issue with `react-native-material-kit`. I use this for ranged slider with two thumbs. Looking for alternatives, but I am fixing this one first.

Turns out upgrading the project to the latest version fixed the issue.

8. `No known class method for selector 'configure'`

Then this issue, from firebase, basically I need to use firebase v6 instead of v5. Well, another breaking changes.
Since local push notification are no longer usable in v6. I need to find solution for that. So in this case, upgrade to v6,
and comment out implementation for local push notification and come back to this later.
(Remember, we want to build and run the app and not spending too much time replacing the implementation and then we don't know why it is not working. Do one thing at a time. Complete the upgrade first.)

Upgrading to v6 has no much issues, also because the only thing that was in used with firebase is the local push notification. (but there are plans to use the Crashlytics, part of the reason why the upgrade is done)
And of course, the documentation on the website is great. I am using `react-native-firebase`. (Sometimes the documentation update is so frequent that old documentation is not there anymore, so just keep up to date with the latest version as best as you can.)

---

At this point, the app can be built and run on simulator already.

---

9. `Invariant Violation: Native module cannot be null.` and `'React/RCTEventEmitter.h' file not found`

This is from the `react-native-activity-recognition` library I am using. Second issue from the same library.
And it has to do with a incorrect path in `podspec` being used. Before this I fixed it with importing the project to library and manually link the library code.
But now I need to use Podfile and this has to be fixed with updating the `podspec` of the library.

Solution: Fork the repository, update the `podspec` and install it in your app.

10. `null is not an object (evaluating '_ReanimatedModule.default.createNode')`

This has to do with `react-native-tab-view`. Upgrade the `react-native-tab-view` and `react-native-reanimated` to the latest version.
Run `pod install` for `react-native-reanimated` to be updated.

11. `Undefined is not an object (evaluating 'navigator.geolocation.getCurrentPosition')`

`navigator` is no longer available from the global object.
Install and use the it from `https://github.com/react-native-community/react-native-geolocation` instead.

12. Also deprecated APIs are: `ViewPager` and `ListView`

If you are using libraries that depends on these APIs, you will need to upgrade the library as well. Or replace/remove the APIs in your app.

13. `Cannot read property measureInWindow of undefined`

Issue with `react-navigation` v3. You will need to use v4 or v5.

From v3 to v4 has some minor changes. From v3 or v4 to v5 will have API changes. So upgrade with care.

For me, I opt to upgrade to v4 and still have some unexpected changes in behaviour. And need to fix it.

As you know, the local push notification is now broken, so I want to just stay with v4 to have less code that broken.

And when the app are back up to where, then I will consider upgrading to v5.

14. `TypeError: Cannot call a class a function`

This is a changes in the code that I wrote, it is now illegal to do that, I haven't investigated further whether the changes is from `react-navigation` or `react` library.
But I managed to figured out the issue.

Code with issue: (works with `0.59.10`)

```
headerLeft: NavHeader.Back,
```

Code changes after the upgrade:

```
headerLeft: props => <NavHeader.Back {...props} />
```

You should be able to tell what's wrong from the error description. (`NavHeader` is a class component)

15. Issue with PagerPan from `react-native-tab-view`

Code with issue:

```
import { TabView, SceneMap, PagerPan } from 'react-native-tab-view';
```

Code changes:

```
import { TabView, SceneMap, ScrollPager as PagerPan } from 'react-native-tab-view';
```

However, even after the fix, the behaviour is not the same, therefore more work has to be done to disable animation and swipe on the tab.


16. `AirGoogleMaps` dir must be added to your xCode project to support GoogleMaps on iOS.

Upgrade the library and make sure to run `pod install`

##### End

Hopefully my writing can help you with the upgrade. Happy coding.

I will be writing up with the upgraded project next.

Upgrading a 16 months old react-native project

One of the many things that bother me after my React Native app went public is the app size.

Big app size is not a show stopper to continue adding new features to my app, nor it causes anything bad.

So, it has always been the least priority to work on that.

Some say it costs a bit of performance, if the app size is too big.

However, it isn't really critical for any newly launched app for a premature optimization, on the app size.

I've always wanted to fix it (when I have the time), and I think now is the best time, because I can do it for

multiple projects that I am juggling, with the same optimization trick.

And, it's really simple.

NOTE: This is an Android only optimization.

###### Before

![before](before.png)

 

###### After

![after](after.png)

 

You can do it with any *ONE* of two ways below:

#### 1. Android app bundle

Simply change your build process from

`./gradlew assembleRelease`

to

`./gradlew bundleRelease`

The output will be `.aab` file instead of `.apk` file.

Note that the `.aab` file will not have any significant file size changes compared to the `.apk` file.

The reduction in size will only be visible after uploaded the `.aab` file to Play Store.

 

#### 2. Separate Build by CPU Architecture

In your project's `android/app/build.gradle` file.

Update the following setting.

`def enableSeparateBuildPerCPUArchitecture = true`

```
splits {
 abi {
 ...
 enable enableSeparateBuildPerCPUArchitecture // be sure to enable here as well
 ...
 }
}
```

Continue to build the apk as usual.

The output will be multiple `.apk` files (usually 4).

Each of the `.apk` file will have significant reduction in app size.

Upload all of them to the Play Store for submission.

Worth to note that, the universal '.apk' file will not be built.

(The one that support all architecture, thus the heavy size.)

If you want it to be in the output apk, along with the others, change the following setting.

```
splits {
 abi {
 ...
 enable enableSeparateBuildPerCPUArchitecture
 universalApk true // If true, also generate a universal APK
 ...
 }
}
```

Then you will have 5 `.apk` files in the output folder.

Read about why enabling the `universalApk` below.

 

---

 

#### Which one to use

For most of us, switching to use Android App Bundle (aab) is painless.

Thus, recommended to use it.

However, here's are some of the things to consider.

 

##### 1. Firebase App Distribution does not support (.aab) at the moment.

If you use Firebase for internal distribution, you might want to use `Separate Build by CPU Architecture` approach, together with `universalApk` enabled.

What you can do is, use universal apk file for distribution, and the separated `.apk` files for Play Store submission.

So, what about if you are using `.aab` file? How can you distribute the app for internal testing?

Well, if there are no existing tools that are already integrated into the app, and need to cater for it,
then you might want to consider using Play Store's distribution track.

You can setup automated process to upload the `.aab` file after building it to the Play Store track.

This require owner access though.

 

##### 2. The reduction in size for both approaches are almost identical.

From what I can tell, after experimenting with both approaches, and using both ways for different apps, in production.

The size reduction benefit is almost identical. In both cases, I got more than 50% in size reduction.

So the size reduction is not much of a deciding factor. Which makes us move to the next point.

 

##### 3. Concern on Android App Bundle's capabilities.

For most of the app out there, App Bundle offer hassle-free switch.

While some of the use cases, it might be more complicated to maintain.

If you are not sure, refer to official documentation of Android development.

If you are not convinced, your app doesn't have defined scope and complexity, or your app might
grow to eventually having very complicated/advanced use cases, you can stick to separated '.apk' approach.

Otherwise, using `.aab` is recommended.

Well this post is not going to elaborate the differences of '.apk' and '.aab', but it is worth doing your research about the topic.

 

---

 

#### Conclusion

With that said, you will have your Android app with very much reduced size by now!

For my apps, over 50% in reduction.

Cheers!

and

Happy coding!

Reduce your react-native android app size


You take a picture from your app, and get back an uri in return.

Then you proceed to upload the photo to server. End of story.

As a developer, you know that's not always the case, sometimes it's a bit more complicated, you take a snapshot from within the app,
and realized that it returns black image.

So you want to debug, and without uploading to server, you can't access to the file,
to take a look at the state of the image, whether your code changes has fixed the issue or not.

Or you want to manipulate the image before uploading.

For whatever reason, you want to access to the file in cache.

After few failed attempts to get it via tools like `Android File Transfer` and others
that can access to the Android file system.

I found the solution with `adb` cli, and here is how to do it, from your Android device.


```
adb shell "run-as com.yourapp.bundle cat '/data/user/0/com.yourapp.bundle/cache/ReactNative-image1215816883788.jpg' > '/sdcard/DCIM/ReactNative-image1215816883788.jpg'"

adb pull "/sdcard/DCIM/ReactNative-image1215816883788.jpg"

```

That's it!

Now, check your current directory for the file `ReactNative-image1215816883788.jpg`


Access to android files in cache directory

Using `Animated` to animate components in `react-native` has been the my go to way of doing things for the past few years.

Until recently when I discovered that `LayoutAnimation` can achieve similar result in animating component without the hassle of managing the states of the animation.

In this case, I am trying to animate the `TextInput` of a chat screen, to expand and collapse accordingly when the input starts receiving text, or when it's been cleared.





All I did was adding this magical line before setting the `props/state` that responsible for expanding or collapsing the view.

```
LayoutAnimation.configureNext(LayoutAnimation.Presets.easeInEaseOut);
```

This also works great with views with accordions and toggles.

It is possible to get it work with `Animated` but now that this is way much simpler, I think its worth sharing.

For more of the detail of using it, check out the official documentation for `LayoutAnimation`.

LayoutAnimation in a nutshell

After trying out different solutions attempted to listen to different port other than 8081 for react-native metro bundler.
Finally I have managed to achieve this **WITHOUT** the hassle of editing files such as:

```
RCTBridgeDelegate.h
RTCDefines.h
RCTInspectorDevServerHelper.m
RCTDevMenu.m
```

While this approach works, the issue with it is the changes get reset after running `pod install`.

So after reading alot materials, with some improvisation, I came up with the solution using `Podfile`.

 

#### Podfile

```
post_install do |installer|
 react_native_post_install(installer)
 __apply_Xcode_12_5_M1_post_install_workaround(installer)

 installer.pods_project.targets.each do |target|
 if target.name == 'React-Core'
 target.build_configurations.each do |config|
 if config.name == 'Debug'
 config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)']
 config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] + ['RCT_METRO_PORT=8089']
 end
 end
 end
 end
end
```

 

#### Metro server

`npx react-native start --port=8089`

 

That's it! Now, run `pod install` and run the app and it will be listening to port `8089`.

For Android, change the dev server setting from your device and it is reload the app. This part will not be covered in this article because there are alot of online resources that works perfectly.

Hope it helps.

Cheers.

React Native Listen to Port Other Than 8081

In this blog post, I will share the code for a simple RCTBridgeModule that can write/read key-value from React Native.

The use case for this is to access the data in iOS Share Extension using value set from React Native.

So that the Share Extension can perform API call with sufficient data that was set in React Native, and thus giving user a much better experience similar to other natively built apps. This is a much more complicated implementation and there are much simpler ways to get it done without writing too many native code and that will be for another blog post.

Let's get back and focus on this topic, get and set value in `UserDefaults` that are accesible in Share Extension.
In order to achieve that, we need to use `UserDefaults` with `suiteName` that starts with `group.`.

Before you proceed, please make sure that you have already created Share Extension and updated `App Groups` in the `Signing & Capabilities`.
This is not covered in this post and there are alot of online resources for this topic.

<hr />

 

##### 1. First, create a header file in xcode.

I'll name it `SharedUserDefaults.h`

```
#ifndef SharedUserDefaults_h
#define SharedUserDefaults_h
#endif

#import <Foundation/Foundation.h>

#if __has_include(<React/RCTAssert.h>)
#import <React/RCTBridgeModule.h>
#else
#import "RCTBridgeModule.h"
#endif

@interface SharedUserDefaults : NSObject <RCTBridgeModule>
@end
```

 

##### 2. Then, create the implementation file.

`SharedUserDefaults.m`

```
#import <Foundation/Foundation.h>
#import "SharedUserDefaults.h"

@implementation SharedUserDefaults

RCT_EXPORT_MODULE()

+ (BOOL)requiresMainQueueSetup
{
 return YES;
}

RCT_EXPORT_METHOD(set:(NSString *)suiteName
 key:(NSString *)keyName
 value:(NSString *)value)
{
 NSUserDefaults *shareExtensionDefaults = [[NSUserDefaults alloc] initWithSuiteName: suiteName];
 [shareExtensionDefaults setObject:value forKey:keyName];
 NSLog(@"val written %@", value);
}

RCT_EXPORT_METHOD(get:(NSString *)suiteName
 key:(NSString *)keyName
 resolver: (RCTPromiseResolveBlock)resolve
 rejecter:(RCTPromiseRejectBlock)reject)
{
 NSUserDefaults *shareExtensionDefaults = [[NSUserDefaults alloc] initWithSuiteName: suiteName];
 NSString *val = [shareExtensionDefaults stringForKey:keyName];
 if (val == nil) {
 NSError *error = [NSError errorWithDomain:@"org.reactjs.native.example.Bill" code:0 userInfo:@{ @"message": @"Empty" }];
 reject(@"error", @"error description", error);
 } else {
 resolve(val);
 }
}

@end
```

 

##### 3. Next, build and run your app.

And you can use the methods from the native module you've just written.

In your React Native project, you can now get and set key-value pair to UserDefaults via the native module.

```
import { NativeModules } from 'react-native';

const SharedUserDefaults = NativeModules.SharedUserDefaults;

// Usage

// Set
SharedUserDefaults.set("group.org.reactjs.native.example.YourProject", "yourKey", "some string to be stored");

// Get
let val = await SharedUserDefaults.get("group.org.reactjs.native.example.YourProject", "yourKey");
```

In iOS, the value can be retrieved in `ShareViewController.swift` or `AppDelegate.m`.

`Swift`

```
var userDefaults = UserDefaults(suiteName: "group.org.reactjs.native.example.YourProject")

// Get value stored earlier
let storedValue = userDefaults?.object(forKey: "yourKey") as? String

 // Set new value
userDefaults?.set("some string to be stored", forKey: "yourKey")
```

`Obj-C`

```
 NSUserDefaults *userDefaults = [[NSUserDefaults alloc] initWithSuiteName: @"group.org.reactjs.native.example.YourProject"];

 // Get value stored earlier
 NSString *val = [userDefaults stringForKey:@"yourKey"];

 // Set new value
 [userDefaults setObject:@"some string to be stored" forKey:@"yourKey"];
```

 

#### End

You are now all set!

Now you can set value from React Native and retrieve it in your `ShareViewController.swift`.

That's it! Hope it helps.

Cheers.

iOS Shared UserDefaults for App Extensions With RCTBridgeModule


Today, I revisited the react-native project that was developed and published by me earlier and the first thing I did was to run tests because I intended to add more Typescript support to the project, wanted to know the current state of test suites of the project.

It wasn't the best FIRST task as a start, but in my opinion, adding more Typescript will be benefiting over the long run.

I've identified removing unused imports to be the low hanging fruit to fix the `tsc` errors.

I started with [https://www.npmjs.com/package/eslint-plugin-unused-imports](https://www.npmjs.com/package/eslint-plugin-unused-imports) but turned out it also removes custom Types import that was used in my files.

Then I found out that VS Code can achieve that with organize import feature.

```
"editor.formatOnSave": true,
"[typescript]": {
    "editor.codeActionsOnSave": {
        "source.organizeImports": true
    }
}
```

That works also with `Shift` + `Option` + `o` shortcut. However, that will also reorder the imports alphabetically.
It seems like there is no way to only remove unused imports without reorder them with `organizeImports`, that being one issue.
The second issue is that I need to also press the shortcut keys for every files. Which is very repetitive work, because there are 1105 files in my `/src` directory.

```
$ find src -type f | wc -l
  1105
```

The second issue was resolved with a VS Code extension to run `organizeImports` in a folder.

[https://marketplace.visualstudio.com/items?itemName=bierner.folder-source-actions](https://marketplace.visualstudio.com/items?itemName=bierner.folder-source-actions)

Then to reorder the imports to my desired orders, I found this great article [https://dev.to/otamnitram/sorting-your-imports-correctly-in-react-213m](https://dev.to/otamnitram/sorting-your-imports-correctly-in-react-213m) that does that.

This is my config

```
"import/order": [
  "error",
  {
    "groups": [ "builtin", "external", "internal", ["parent", "sibling"] ],
    "pathGroups": [
      {
        "pattern": "react+(|-*)",
        "group": "external",
        "position": "before"
      },
      {
        "pattern": "@**+(/**)",
        "group": "internal",
        "position": "before"
      }
    ],
    "pathGroupsExcludedImportTypes": ["react"],
    "newlines-between": "always",
    "alphabetize": {
      "order": "asc",
      "caseInsensitive": true
    }
  }
],
```

Just a TIL from me. That's it! Hope it helps.

Cheers.


Remove unused and reorder imports

While the latest released version for `react-native` is `0.67.2`, I upgraded the project that I am working on to `0.66.4` instead.

This is mainly due to some issues that I ran into that I decided not to spend too much time fixing it since `0.66.4` is sufficient for my use case.

In this blog, I will be sharing some of the issues that I ran into and the solutions for them. Hopefully someone might find it useful, and I can also refer to this blog in the near future if I need to upgrade other projects.

 

#### The issues

1. folly

```

duplicate symbol 'folly::detail::str_to_bool(folly::Range<char const*>*)' in:
...
...
```

In my case, I need to do

```
pod update
pod install
```

Normally you need to run `pod update` after update `react-native` version

or in some cases

```
rm -rf Podfile.lock Pods/
pod install
```

if you thing you have messed up the `Pods` after upgrading to different `react-native` versions back and forth.

2. `#<WeakSet> could not be cloned`

Then you might get this issue for any library.

```
error node_modules/react-native-vector-icons/lib/create-icon-set.js: #<WeakSet> could not be cloned.

error: node_modules/react-native-branch/src/branchUniversalObject.js: function (path) {
 return fn.call(state, path, state);
 } could not be cloned.
 BUNDLE ./index.js
 ```

This has to do with `babel`, so you need to upgrade them as well.

```
yarn upgrade --dev @babel/core
yarn upgrade --dev @babel/runtime
```

3. Android project could not resolve dependencies

Error:

```

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':app:lintVitalBetaRelease'.
> Could not resolve all artifacts for configuration ':app:betaDebugRuntimeClasspath'.
 > Could not resolve me.relex:photodraweeview:1.1.3.
 Required by:
 project :app > project :react-native-photo-view-ex
 > Skipped due to earlier error
 > Could not resolve org.webrtc:google-webrtc:1.0.+.
 Required by:
 project :app > project :react-native-twilio-video-webrtc
 > Skipped due to earlier error
 > Could not resolve com.yqritc:android-scalablevideoview:1.0.4.
 Required by:
 project :app > project :react-native-video
 > Skipped due to earlier error
 > Could not resolve com.getkeepsafe.relinker:relinker:1.3.1.
 Required by:
 project :app > project :react-native-twilio-video-webrtc > com.twilio:video-android:5.10.0
 > Skipped due to earlier error
```

Another error:
```
Could not determine the dependencies of task ':app:lintVitalRelease'.
> Could not resolve all artifacts for configuration ':app:debugRuntimeClasspath'.
 > Could not find com.yqritc:android-scalablevideoview:1.0.4.
 Searched in the following locations:
 - https://repo.maven.apache.org/maven2/com/yqritc/android-scalablevideoview/1.0.4/android-scalablevideoview-1.0.4.pom

```

This is due to removal of the line `jcenter()` in `android/build.gradle`. Moving forward, JCenter will not be maintained.

So it is recommended to remove the depencencies to the repository.

[Read more about the announcement here.](https://reactnative.dev/blog/2021/08/17/version-065#notable-dependency-version-updates-and-gotchas)

At the meantime, we have libraries that depends on JCenter and it's going to take time for maintainers to update the libraries.

So we can do this for now for the dependencies we need.

```
 jcenter() {
 content {
 includeModule("me.relex", "photodraweeview") // Could not resolve me.relex:photodraweeview:1.1.3.
 includeModule("org.webrtc", "google-webrtc") // Could not resolve org.webrtc:google-webrtc:1.0.+.
 includeModule("com.yqritc", "android-scalablevideoview") // Could not resolve com.yqritc:android-scalablevideoview:1.0.4.
 includeModule("com.getkeepsafe.relinker", "relinker") // Could not resolve com.getkeepsafe.relinker:relinker:1.3.1.
 }
 }
```

So now you get the idea of using `includeModule`.

That's all for the issues.

Hope that saves your precious time!

Cheers.

Another react-native project upgrade

I upgraded react-native for an app I'm working on to `0.70.6`.

New architecture was being introduced however I am turning that off for now until I figured out the benefits of it.

With that said, it is still exciting to build mobile apps with React Native, and even so with the new architecture.

Most of the issues that I am facing when upgrading the app were able to be fixed with just simply upgrading the corresponding packages/dependencies to the latest version.

While some other have alternatives like using temporary packages to fix the error. For example, using `deprecated-react-native-prop-types` to replace legacy code `ViewPropTypes` and `Text.PropTypes` in the project.

 

For android, a lot of issues thrown out when building the app (as usual), but are able to be solved after spending some time. For example, in the following error, use `allowInsecureProtocol = true` for one of the repository (though it will be better to inspect the usage of this package in the near future, and revisit this workaround).

```
* What went wrong:
Could not determine the dependencies of task ':app:lintVitalReportBetaRelease'.
> Could not resolve all dependencies for configuration ':app:betaReleaseRuntimeClasspath'.
 > Using insecure protocols with repositories, without explicit opt-in, is unsupported. Switch Maven repository 'maven6(http://dl.bintray.com/lukaville/maven)' to redirect to a secure protocol (like HTTPS) or allow insecure protocols. See https://docs.gradle.org/7.5.1/dsl/org.gradle.api.artifacts.repositories.UrlArtifactRepository.html#org.gradle.api.artifacts.repositories.UrlArtifactRepository:allowInsecureProtocol for more details.

```

 

Solutions for other issues are not available, therefore I change the code in the packages and use `patch-package` for that. Not that I am satisfied with it, but it is the way to go for now.

That's all. Cheers.

react-native project upgrade


Adding `redux-toolkit` to my code has reduced the amount of code that needs to be handwritten in my apps.

Not too long ago, I am building a web app for a mobile-first application that I am working on. I realized that I needed a more efficient way to manage my redux code.
Initially it started with `react-native-web` and it worked out okay that I could port my `react-native` code to my web app, written using `Next.js` and `react.js`.
Writing a web app with `react-native` components API was certainly not the end goal of the web app, but just a transition to get the momentum going.
Transitioning to using standard web HTML and React components requires some effort, but it turns out to be more productive in building web app, even more when I used `tailwindcss` to style the components.

Now, when it comes to the state management with redux, I have found a better way to structure the directories (compared to existing ones in my project), using `redux-toolkit`, and `"Redux ducks" pattern`.
Previously, what needs to be done in 3 files for an action and side effects (1 file for action types, another for reducers, and another for redux-saga side effects) can now be done in 1 file. That significantly reduced the amount of boilerplate code, and fewer mistakes when
writing those files.

Just be aware of the potential downside of using the ducks pattern, which is potential circular dependencies in the code, which may lead to undefined imports.
The solution highlighted in [this blog post](https://medium.com/visual-development/how-to-fix-nasty-circular-dependency-issues-once-and-for-all-in-javascript-typescript-a04c987cf0de) is elegant and makes sense.

In the future, I hope there is enough time to put the web and mobile apps codebase under a monorepo.

That's all. Cheers.


"Redux Ducks" pattern, redux-toolkit, redux-saga and circular dependencies


Today I learned (the hard way), that calling `DeviceEventEmitter.removeAllListeners()` will remove `BackHandler`'s `hardwareBackPress` event as well.

The recommended way of removing listeners are removing the specific event listener only.

For example:

```
  React.useEffect(() => {
    const subscription = DeviceEventEmitter.addListener(eventName, handler);

    return () => subscription.remove();
  }, []);
```

Thanks for reading. Happy coding!


About DeviceEventEmitter.removeAllListeners()


Today I learned how to resolve dependency version with `yarn`.

Imagine you have `react-native-permissions` in your `package.json`.

At the same time, you also have let's say `react-native-qrcode-scanner` with dependencies on `react-native-permissions`.

Now, an issue arose when both the `react-native-permissions` require different versions, with one of them introduces breaking changes.


This is the kind of scenario where we can use [selective dependency resolutions](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/).

Usage example, in `package.json`:

```
  "resolutions": {
    "react-native-permissions": "^3.8.4"
  }
```

This will then override the version of `react-native-permissions` in `react-native-qrcode-scanner` therefore resolve the issue.


Thanks for reading. Always keep learning!


Override version for package dependency

[Jump to solution to see the improvement](#solution)

About 3 months ago, I am looking to build an app to explore different type of application that can be built with React Native.

After a quick round of idea selection, I decided to build a [file transfer app](https://play.google.com/store/apps/details?id=app.mvphub.filelinkup). Part of the consideration being it scratches my own itch as I regularly transfer files between my Android and iOS devices.

#### 1. Introduction

App should works

- Offline
- Send original file without compression / loss of quality

#### 2. Development Journey

Initial attempt was to use bluetooth to achieve that. Since wearables and devices connect and sync data from each other as I experienced it.
Plus back in the days before cloud solutions, bluetooth file sharing was working okay.

Bluetooth technology quickly confuses me it's variation like bluetooth vs. bluetooth low energy (BLE), scanning and connecting devices are a big hurdle before getting into transmitting data between devices.

Then, I am looking for feasible alternative and arrived at a WiFi network approach with TCP socket.
I am familiar with the paradigm with my experiences working with chat and video streaming applications.

A quick test of the setup with TCP server and client proofs that connecting devices are easier, and sending text data was achieved shortly after.

---

The first challenge surfaced and it was me asking myself "How to send image using text string?".

Shortly afterward, I integrated an image picker library into the app and utilized the `base64` encoding to convert the image into a text string, which will be used to send over the connection.

While sending the image with `base64` from one side to the other has no issue, another challenge quickly arise.

"How to know if the file content has finished sending?" This is so that I can call the `save` function on the receiver, to save the file content.

Browsing through the internet, I understand that socket will continuously listening to data. It is up to me to either close the socket, and the last bit of data will be flushed out of the buffer and I can save the file when the event `onClose` is triggered.

That works if I am sending a single file, but what if I am sending multiple files (let's say 100) in one go?

Now the alternative is to send a special string as a delimiter to indicate the termination of the file content.

With `base64` encoding, `@` is surely not part of the character that will exists, therefore it is a good candidate for this use case.

---

To think about data in socket connection is to imagine it as a continous string of data that keeps notify you when something new arrived.

Now that I know what to look for to split the data with a delimiter (let's call it `@END@`), here comes the other challenge: knowing where does the file content starts.

There is a need to transmit information other than the file content. For example, information that informs sender to update the UI when the client successfully saved the file, or data that used for chat messages.

With the same approach used to determine the `@END@` of a content, now I need to have it for the beginning of a content, (let's call it `@HEAD@`).

Now we are able to separate a whole chunk of content from start to end by identifying `@HEAD@` and `@END@`, regardless whether the content is a file content, or a stringified string.

---

When we are sending something in socket, it will not always send it out immediately. There is a concept known as `buffer` that keeps collecting the data and send it out in one go, and we have no control over when it will send out or wait.

We can imagine it as a waiting area for data to pile up and send out when it is ready.

This behaviour is important to understand because we need to design our system to be able to process the transmitted data that are not guaranteed to be in it's own chunk from the sender's intention.

For instance, before sending any content, I will send the header information to the client. From the client's perspective, the first batch of data received, may comprise of header only data or header and content data.

So the client will need to handle that accordingly.

---

When everything is finally in place, I am able to send content between iOS and android devices. With different type of content such as stringified JSON for UI updates or text messages and Base64 string for file content that could be any file.

A huge milestone achieved! 🎉

Finally a working file transfer app, from initial ideation which I have no clue how exactly it can be done.

---

Then comes the next challenge. Transfer speed is slow. Significantly slow with large file, and this is not even multiple files.

At this point, initially I am about to move on to other features that are more interesting to me, like scan for network for available devices to connect. This will greatly reduce the effort to initiate a transfer of file and have better user experience.

However, I chose to work on improving the transfer speed instead. I simply couldn't bear with the slow transfer speed. Despite this means that I probably need to work on native code, which has high degree of uncertainties but I am determined it can be done.

---

First step of transfer speed optimization begins with revisiting the existing algorithm that process the incoming data from socket connection.

With careful refactoring and simplifying logic in loops, I managed to improve the transfer speed from ~100Kbps to ~300Kbps.

That's 3 times of improvement and have obvious reduction in transfer time. However, the goal is to reach above 1000Kbps because that's what the active incumbents on the market are offering, and I am convinced it can be done, with React Native.

Also because that's what the whole point of starting this project, to explore and push the limit of app built with React Native.

The next junction of optimization leads to which path to take to achieve the goal of 1000Kbps transfer speed.

I could either:

- Optimize Javascript code in hope for the next 3x improvement
- Opt for React Native's new architecture
- Work with native platform code

What I have done was all 3 of them, in the order of the list above.

Well, fast forward today and looking back to the decision, I would still make the same decision if I were to choose again.

---

There isn't anymore room for optimization working on Javascript code and logic. The bottleneck is the `bridge` that is used for communication between native and JS code.

I came to this realization after spending more time looking for a simple tweak but unfortunately, no easy fix using this approach.

The next step was to try out the new architecture and hopefully transfer speed will just be faster.

Lots of experimentation: enabling new architecture, learn `Codegen`, `Turbo modules`, working with custom JSI binding to send data between native and JS without the bridge, configuring `CMakeLists.txt` for `C++` build, benchmark the performance and so on.

After spending 2 weeks learning the rope, the result is not up to expectation. Enabling the new architecture is not a silver bullet for the problem. No significant improve in speed.

---

Despite heading into the wrong direction and invested time without fruitful outcome, finally it is now clear to me, with more learning from the internet about the problem, that I can do it with native module, without new architecture.

The next steps is to read and browse through the source code of existing native module and figure out a solution.

<a name="solution">So here is the solution:</a>

![diagram](flow.png)

The transfer speed improve tremendously, exceeded my initial goal way beyond my expectation. It's mind blowing that it reaches 12,000Kbps in good network condition. 🤯 40x improvement from 300Kbps to 12,000Kbps.

Transferring videos and huge files are way much faster now, and multiple files transfer has no issue as well with fast transfer speed.

I am glad it worked out that way but I am far from done with the application. There are just so many exciting features I wanted to implement. It's time to take a break from this development and it's a joy to use to use this app on a weekly basis to transfer files.

Check out the app and let me know what you think!

[iOS](https://apps.apple.com/us/app/file-link-up/id6464361724)

[Android](https://play.google.com/store/apps/details?id=app.mvphub.filelinkup)

Thanks for reading, cheers!

Socket programming for file transfer application


#### 1. Introduction

There are several use cases of resolving promise in Javascript.

1. Resolve value once (commonly used)
2. Multiple resolve at the same time, **order** of resolve **does not matter** (i.e. upload multiple images)
3. Multiple resolve one at a time, **order** of resolve is **important** (i.e. call an API function or task sequentially after the previous call completed)

#### 2. How it's done

```
  const sequentialFn = async () => {
    for (const item of list) {
      await task(item);
    }
  }
```

It may seem to be the same as other iterable function method but there is a significant difference in behaviour and this will get the job done.

Thanks for reading, cheers!


Resolve array of promises in sequence


#### 1. The problem

Using Firebase to build mobile apps can significantly speed up development. However, there are times when you need access to the refresh token for customized behaviour in authentication.

For example, imagine a feature that allows users to switch to a different account within the app without re-logging in. In this case, you need to store the `refreshToken` securely in the app and use it to exchange for a new access token.

The issue I encountered was that the `refreshToken` exists on the iOS platform but not on Android when using `@react-native-firebase/auth` version `18.8.0` as of this writing.


#### 2. The solution

To solve this problem, you can follow these steps:

1. Get `idToken` from mobile app
2. Exchange for `customToken` from your backend server
3. Use `signInWithCustomToken` with Google's API
4. Read `refreshToken` from JSON

Here's a sample code snippet to illustrate this process:

```
  let refreshToken = null;

  const response = await fetch(
    `https://identitytoolkit.googleapis.com/v1/accounts:signInWithCustomToken?key=${FIREBASE_API_KEY}`,
    {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        token: data.customToken,
        returnSecureToken: true,
      }),
    },
  );
  const json = await response.json();
  refreshToken = json?.refreshToken;
```

Now you have the `refreshToken` that you can use for your app's custom authentication flow.

Thank you for reading! Cheers!


Retrieve refreshToken in Firebase with customToken


#### 1. The problem

Debugging push notification issues requires skill and effort. It's very helpful to be able to send targeted push notification to designated device for testing purposes.

In this blog, I will document how to achieve it.

A heads-up, the main hurdle lies in retrieveing an access token for authentication. Compared to the legacy API that used a server key, the new one requires a bit of extra work to get the API to function properly (for good reason).


#### 2. The solution

Endpoint:

POST `https://fcm.googleapis.com/v1/projects/{YOUR-PROJECT-ID}/messages:send`

Get `{YOUR-PROJECT-ID}` from Firebase console, `Project Settings > General`

Body:

```
{
   "message":{
      "token": "FCM token on device",
      "notification":{
        "body":"This is an FCM notification message!",
        "title":"FCM Message"
      }
   }
}
```

Headers:

`Content-Type: application/json`

`Authorization: Bearer {accessToken}`

To retrieve `accessToken`, you need:

1. gcloud CLI

2. Private key file in JSON format (From `Project Settings > Service Accounts`.)

Using `GOOGLE_APPLICATION_CREDENTIALS` environment variable:

```
GOOGLE_APPLICATION_CREDENTIALS=/path/to/your/secret.json /path/to/your/google-cloud-sdk/bin/gcloud auth application-default print-access-token
```

An access token will be printed to the terminal. Use it for the `Authorization` header.

Thank you for reading! Cheers!


Send Firebase push notification using REST API

#### 1. The problem

When building a component for animated progress bar, we might bump into this issue.

`style property 'width' is not supported by native animated module`

That's happening as a result of animating `width` with `useNativeDriver: true`

In this blog, I will document how to keep `useNativeDriver: true` without using `width` property.


#### 2. The solution

From:

```javascript
<Animated.View
 style={[
 styles.activeProgressBar,
 {
 width: progressBarAnimationRef.current.interpolate({
 inputRange: [0, 1],
 outputRange: ['0%', '100%'],
 }),
 },
 ]}
/>
```

To:

```javascript
<Animated.View
 style={[
 styles.activeProgressBar,
 {
 transform: [
 {
 translateX:
 progressBarAnimationRef.current.interpolate({
 inputRange: [0, 1],
 outputRange: [-singleBarWidth, 0],
 }),
 },
 ],
 },
 ]}
/>
```

Using `translateX` instead of `width`, with negative bar width as the start of the output range, and `overflow: 'hidden'` on the parent container.

Thanks for reading! Cheers!

useNativeDriver for animated progress bar


## A Change of Mind (After Many Years)

Back in 2018, I wrote a post comparing **CRNA, Expo, and `react-native init`**, and at the time my conclusion leaned heavily toward **React Native CLI**.

Fast forward to today — **I’ve changed my mind**.

Expo has quietly solved most of the problems that originally pushed developers away from it.

For most projects now, **Expo is not just beginner-friendly — it’s the most productive and scalable choice**.

This post explains **why I now default to Expo**, and when I still reach for React Native CLI.

---

## Why Use Expo Today

### 1. Expo Dev Client (This Is a Game Changer)

The Expo Dev Client completely changed my workflow.

- Run the app **directly on a real device**
- Resume the app **instantly** without rebuilding
- No cable juggling
- Easy Port Switching (and therefore can run multiple projects side-by-side)

Once installed, development feels closer to web-level iteration speed.

---

### 2. CNG (Continuous Native Generation) Is Awesome

Expo’s **CNG** means:

- Native code is generated **from config**
- You don’t manually maintain Android/iOS files unless you want to
- Native changes are reproducible and deterministic

Instead of:
> “Don’t touch this file or things will break”

You get:
> “Change config → regenerate native code → done”

This is exactly how modern tooling *should* work.

---

### 3. Expo’s Library Ecosystem Is Mature

Expo libraries are no longer “nice to have”.
They are **well-maintained, production-ready, and deeply integrated**.

Some benefits:
- Consistent APIs
- Sensible defaults
- Actively updated with React Native releases
- Fewer breaking surprises

Things that used to take hours of native setup are now:

```ts
npx expo install expo-camera
```

And it just works — including correct native versions.

---

## 4. Expo Prebuild = Best of Both Worlds

This is where old arguments against Expo no longer hold.

With **Expo Prebuild**:

- You get full `ios/` and `android/` folders
- You can write custom native modules
- You can open Xcode or Android Studio anytime
- You are not locked in

Expo no longer says:

> “You can’t do that”

Instead, it says:

> “Start simple, go native when needed”

This is the exact flexibility React Native CLI users wanted.

---

## So… Is React Native CLI Dead?

No.

But it’s **no longer the default choice**.

Use **React Native CLI** only if:

- You fully understand native build systems
- You need complete manual control from day one
- You are building highly custom native integrations
- Your team is already deeply invested in RN CLI workflows

In short:

> **CLI only if you know exactly what you are doing.**

For everyone else — including experienced developers — Expo now offers **faster iteration, safer defaults, and less maintenance burden**.

---

## My Current Recommendation

- **New project? → Expo**
- **Prototype or MVP? → Expo**
- **Production app? → Expo (with Prebuild)**
- **Heavy custom native from day one? → RN CLI**

Expo is no longer “the easy option”.

It is **the practical option**.

You have nothing to lose, and everything to gain.

---

## Final Thoughts

I used to believe that choosing Expo meant giving something up.

Expo has grown up.

And so has my opinion.

If you’re still thinking of Expo as “just for beginners”, it might be time to take another look.

You may change your mind too.


react-native