react-native-new-architecture VS Apktool

TurboModules: TurboModules are a new way of implementing native modules that use JSI instead of the bridge. TurboModules can reduce the overhead and latency of the native module calls, as well as provide a more consistent and type-safe interface for the JavaScript code. It is important to note that TurboModules are still experimental and not fully supported by all platforms and libraries

Finally, still about 0.72 RC1: Samuel Susla just made a post on performance benchmarking with some sweet new architecture 📈 measured on this RC. Check it out here 👉 https://github.com/reactwg/react-native-new-architecture/discussions/123

Also I can see on the GitHub a list of libraries that are migrated/migrating/plan to migrate here, https://github.com/reactwg/react-native-new-architecture/discussions/6. Is this really all the libraries that are compatible at this moment in time?

Detailed info - https://github.com/reactwg/react-native-new-architecture/discussions/105

[The discussion in the working group about libraries adopting the new architecture](https://github.com/reactwg/react-native-new-architecture/discussions/6) implies an urgency that not updated libraries will block the migration to the new architecture but I was wondering in what way exactly.

App tampering and repackaging can be performed by using reverse engineering or tampering tools, such as Apktool, dex2jar, etc.

Apktool made by iBotPeaches, this uses v2.9.1

Can someone clarify what "PP tools" are, and provide a link to them? I came across this link (https://apktool.org/) but I'm not sure if it's the right tool.

Apktool is all you need most of the time.

But it'll still be editable and we can make something good out of it. One of the famous ones, that I'm planning to use is ApkTool(https://ibotpeaches.github.io/Apktool/).

I did a dissection of twitter apk (got from apk pure) with apktool, and I found permission :

Not sure. I started reverse engineering Java apps very early in my life — initially it was J2ME games. Decompilers of the time sucked but that didn't stop me from modding Gravity Defied :P

I honestly don't know what's a good way of getting started on reverse engineering. There's a bunch of everything about Windows executables in particular, including "crackmes", but native machine code is a level up from JVM bytecode. Java classes and Android dex files can be decompiled back to sensible source with a good chance that you get something that can be compiled again. No such luck for native code — C/C++ compilation is a lossy process by its nature, especially the optimizations. Ghidra does a decent job but still requires a non-zero amount of manual assistance. Flash games also were good to hone one's reverse engineering skills since ActionScript decompilers did a pretty darn good job.

Anyway. To decompile dex to Java source, there's jadx: https://github.com/skylot/jadx

Since decompilation is sometimes lossy, there's apktool for when you want to put the app back together after tinkering with it: https://github.com/iBotPeaches/Apktool

It goes without saying that you also need a JDK and the Android SDK. In particular, you need apksigner form the SDK to sign the unsigned apks generated by apktool. You can also automate things a bit and use adb to deploy them to your device.

What I usually do is get a high-level overview of the app in jadx, and then modify the smali (dalvik bytecode in text form, very assembly-like) files generated by apktool.

I am not game or android app dev, but you might first need to de-compile apk using tools like https://ibotpeaches.github.io/Apktool/