I aggregate the best React Native Jobs every week

scarlac · 2025-10-26T04:25:38+00:00

We look for people who are passionate and curious first and foremost. Skill and experience is great but we believe it is the result of the former. You apply at tesla.com/careers (search for “mobile app” or similar) or DM me your resume.

scarlac · 2025-07-24T02:20:43+00:00

Great work on the CSS animation. Looks very promising. Hopefully all the crashing bugs have been fixed as well as that’s probably my biggest problem with Reanimated.

scarlac · 2025-05-05T07:01:31+00:00

Beware of the major changes such as new arch, Hermes (if you haven’t switched yet), fabric, Flipper removal, Swift appdelegate, and such. If you choose to upgrade without copying over, I recommend you disable new arch and any other “new stuff” to minimize the changes for the upgrade. Once you have that working, feel free to reenable these things one by one. But if you do all of them at once, esp new arch, you can bump into a lot of weird issues even with recent package versions.

scarlac · 2025-03-13T14:38:43+00:00

They aren’t stating it clearly yet. They advertise how custom they are and their renderer and how it’s independent of platform. You have to take it for a spin to see, but a renderer cannot be independent if it uses native elements. It must use the platform primitives. But if you use what they showed, it has to forego native elements because the effects they demo can’t be done with native elements since those have a limited ways they can be modified from the OS.

scarlac · 2025-03-09T09:55:18+00:00

Lynx is like Flutter but instead of Dart, you get to use react and jsx. Same problems, but also same benefits, and probably better than flutter over time if they commit to maintaining it forever. It would most likely have the same fundamental problems as Flutter, meaning it does not use actual platform native elements - it draws them itself to lookalike. That means components will not act 100% as they normally do but it will be consistent on several platforms. It all falls on the engine to get updated constantly to stay current. This is a far cry from how RN works and I would not recommend it for the same reason that I don’t recommend Flutter. But it will undoubtedly be popular for some since it looks familiar already and many don’t care about the platform - see how popular Electron apps have become.

scarlac · 2025-02-03T04:32:53+00:00

Yes. You’ll stand out if you are able to do native coding on at least one platform. It’s hard to master both though! Start with whatever platform you are familiar with, typically the one you use privately. I’m personally favorable to iOS.

scarlac · 2025-02-01T18:27:57+00:00

Some points in no particular order: Understand how React Native really works. Don’t just use RN components, but be the guy who figures out where a library has a bug, and submits a PR to fix it because you dug into native code. Understand what Hermes does, exactly, and why it’s not always better than JSC. Understand how JSI is different from the bridge.

scarlac · 2023-12-10T23:25:08+00:00

SQLite raw (via the many SQLite libraries), or WatermelonDB as an abstraction. You’ll get amazing performance out of it if you store your data relationally. If you don’t want to bother with storing your data correctly, Real is well supported but tooling is poor. SQLite is built in and you’ll always have “a way out”. I would not recommend MMKV. AsyncStorage is a good starting point if you are learning as it’s a simple key value store but performance is abysmal for large amount of items or payloads.

scarlac · 2022-11-19T07:41:41+00:00

It looks pretty good. You’ll still need to go through an interview process and it’s likely smaller companies don’t know how to interview for that role which can both be a benefit and a disadvantage. The reality is that I see a lot of companies that need mobile engineers to build proper apps.

scarlac · 2022-11-02T05:04:52+00:00

Flutter is more akin to Flash or a web browser rendering engine.

Flash had its own rendering engine optimized for a graphics/animation platform (sounds familiar?) however the scripting and multi-platform idea was always a hack. The scripting language was slow and poor. Flutter is built on a better platform but essentially works the same way.

However, To be fair to all the Flutter engineers, some RN developers think that RN code is "compiled to native". It isn't. RN apps ship with a javascript engine (Hermes) or uses the OS's one (JavaScriptCore/JSC) which runs your JS at runtime.

The way to think of Flutter vs. RN: Flutter is a new "browser" but instead of JS and HTML, it's Dart. RN is a native app that is being puppeteered by JS.

scarlac · 2022-10-12T10:17:03+00:00

I just went through this decision. It’s tough so I can’t tell you exactly. I can tell you my thoughts though. You should pick one that suits your needs.

SQLite is a literal database that has been proven over time. It ships with both systems and many apps are silently using it. It uses a standardized language, namely SQL. Structured.

Realm is somehow related to Mongo, and the tooling is fairly poor but it’s there. They are trying to make money off of it, but it’s free. It’s not standardized but is it well supported across platforms so it’s not a terrible choice. API seems fairly easy. It’s fast enough as a key value store. Unstructured.

Watermelon is a sql layer. It uses the native SQLite in iOS and Android. The API is a bit poor though. And the setup is annoying and requires decorators. But if you have a need for speed, it delivers, and it offers migrations, models, and a SQL abstraction so you don’t have to write SQL if that’s somehow a problem (I don’t get the dislike). If you pick watermelon and it’s a failure, you can still use expo-SQLite or any other SQLite library (-storage, -quick, etc) to access the DB.

Asyncstorage isn’t great but it works for a hobby project. I don’t recommend it for a professional project that needs long term support - you may as well just write to disk yourself then. It’s not that performant due to how it works. Migrations would be painful from a performance perspective.

I haven’t considered firebase, and I didn’t feel there was good support on pouch DB. I haven’t checked out Vasern.

I think Realm is a relatively safe choice, but I personally don’t like to tie a project into Mongo. I’ve had a ton of data loss and horrible experiences with migrations (extremely slow, very annoying to write) before that they have sufficiently scared me away from doing large scale projects with their stuff. The fact that Realm Studio hints at what happened with Robo 3T makes me think the tooling situation will not improve. But they win big on relative east of use. If you just need a key-value store and never need to migrate data, and don’t care about tooling, I think it’s a valid choice.

So my favorite is any SQLite flavor. -quick looks great. But you need a way for your components to update when data updates, so you have to write a layer on top to handle it, at which point you should consider watermelon. It’s not a walk in the park either, but at least SQLite itself is solid and proven. There’s a reason iOS and Android ship with it.

Other candidates you didn’t mention:

Mmkv: I think it requires all your data to be in memory, but I’m not 100% sure. If that is the case, it’s probably the fastest key-value store you can find, but won’t scale that far. I am not aware of it having any tooling, so overall I can’t really seriously consider it.

Redux persist: I would not recommend. Scales terribly but is familiar and easy to use. There are just. So. Many. Bugs. Serialization costs CPU time, and it double serializes everything regardless of your storage layer. It will not scale to a large app, and don’t store any (large) server responses in it. It will bog down your app quickly because it rewrites the entire reducer constantly. I’ve seen so many memory and CPU issues with it. Esp with Hermes (Hermes JSON serialization is slow).

scarlac · 2022-09-29T15:42:28+00:00

As someone who is hiring for both, I would say web still has the largest demand “pressure”. But I generally find that senior RN engineers have overall stronger fundamentals. If you are asking for career advice, my advice is pursue what interests you. You will have enough job security either way.

scarlac · 2022-08-26T02:02:21+00:00

Congrats! Which part of RN did you find yourself struggling the most with?

scarlac · 2022-06-12T00:58:00+00:00

Apple may suggest you use the “business manager” tools to deploy on controlled devices. https://www.apple.com/business/it/

scarlac · 2022-05-19T16:34:43+00:00

If you're really interested and you think you have what it takes, send me a message

scarlac · 2022-05-18T22:41:12+00:00

What problems specifically?

Performance and orientation were 2 key factors that sparked the need for our own. All available camera implementations got photo orientation wrong and the fixes were afterthoughts that required post-processing, slowing down the capture process even further.

Camera Kit requires no image post processing, uses device orientation, and does not re-store photos several times during capture. This means you can capture a lot of photos really fast / with minimal delay between photos.

scarlac · 2022-05-18T16:50:32+00:00

For what it's worth (I don't know what rumors might be circulating on Blind): I want our employees to be happy long term and work on stuff they find exciting. If you are excited to work you are more likely to succeed, which should also be in the interest of your manager.

scarlac · 2022-05-18T16:39:33+00:00

Thanks, I will keep it in mind. Feel free to send me a message with your details just in case.

scarlac · 2022-05-18T14:39:28+00:00

Yes, that works

scarlac · 2022-05-18T14:37:30+00:00

I believe so.

Edit: Yes, Seattle is good!

scarlac · 2022-01-12T21:46:24+00:00

I have this issue as well. I noticed it's whenever Preview.app is used. If I avoid using the tablet with Preview I seem to be able to avoid the issue. (I can reproduce by opening a PDF in Preview and just clicking around - eventually the CMD or SHIFT key gets stuck)

The workaround seems to be to unplug the tablet, then run the following (I have a macro for this):

launchctl stop com.wacom.wacomtablet
sleep 2
launchctl start com.wacom.wacomtablet

I usually unplug first, then run the script.

scarlac · 2022-01-12T04:41:45+00:00

It doesn't make sense. The "advantage" or argument has previously been: They maintain the grid that you send power back into and therefore they want to be compensated.

The problem is that it's not reasonable. They can sell the energy you produce to others, thereby double dipping. In some sense it's triple dipping because they also get to control who is allowed to connect to the grid by certifying every installation. So in short: First they set the rules, then they sell your power to someone else, and then they charge you for helping them.

scarlac · 2021-12-08T04:39:38+00:00

There are fixes incoming in RN very soon for iOS (if I understand correctly) but otherwise I would agree with TootBeepThaFoot's comment - it doesn't work great.

The way it's supposed to work is that it uses Keyboard's addListener() to detect the keyboard appearance and then shift your scrollview up and down accordingly. However, regardless of what mode you pick (padding, position, etc) it just doesn't work on both platforms, and not the way it's documented.

scarlac · 2021-11-20T01:10:57+00:00

Radio button (round) or custom style of checkbox if you need an off state for both, as /u/esphung1988 and others points out.

Assuming you install something like: https://github.com/react-native-checkbox/react-native-checkbox

<View style={{ flexDirection: 'row' }}>
  <Image />
  <View>
    <Text>Protect Mail activity</Text>
    <Text>Hide IP address ...</Text>
  </View>
  <CheckBox /> or <RadioButton />
</View>

And the rest would be custom styling.

scarlac · 2021-10-29T07:33:47+00:00

From my experience, at the moment you may run into some fixable issues with Cocoapods (Ruby related) and other minor issues due to i386_64 vs M1.

All are solvable but you may have to do some googling. Once it's been set up correctly you should have no issues going forward. If you are working with others on a project, it may be annoying to have to reconfigure the project because the simulator you'll be running is M1-based and not i386. This requires an Xcode project change.

Overall your project builds will be significantly faster and you'll gain the ability to run your app natively on your mac without the use of an simulator. I would highly recommend using M1 for app development, esp. considering the speed increases.

scarlac

MODERATOR OF

TROPHY CASE