Sort of. It kind of depends on what you mean by the “native code.” Technically speaking, their native code is as follows:
Android Native Code:
- Java: The traditional language for Android development.
- Kotlin: A modern, more concise alternative to Java, officially supported by Google.
- Android SDK: The Software Development Kit that provides the tools and libraries necessary to develop Android apps.
iOS Native Code:
- Swift: The preferred language for iOS development, known for its performance and safety features.
- Objective-C: An older language still used in some legacy iOS applications.
- iOS SDK: The Software Development Kit that provides the tools and libraries necessary to develop iOS apps.
However, you CAN do app programming in a number of programming languages and not have a problem:
Cross-Platform:
- React Native (JavaScript): Allows you to build apps for both iOS and Android using a single codebase.
- Flutter (Dart): Another cross-platform framework that enables you to create natively compiled applications for mobile from a single codebase.
- Xamarin (C#): Uses .NET and C# to build apps for both iOS and Android.
Other Options:
- Python: Can be used with frameworks like Kivy for mobile app development.
- C++: Sometimes used for performance-critical parts of mobile apps.
The problem with Darkmode isn’t actually related to the KIND of code or programming language they use(d) being the same as Android or iOS. It is more about the way the app was organized (the framework) from the start that isn’t conducive to modern things like app-wide styles and themes. The app was structured to be segmented into different “plugins” per device and screen, etc (basically each part acts like it’s a separate app within an app). So we can’t just simply change the color scheme on one thing and have it update for the whole app.
They’re trying to retrofit that, but it’s complicated. The Wyze app appears to have originally hardcoded colors and styles for each individual object in the app instead of setting up the structure and framing for Dynamic Theming. If that is what you meant by code, then that is correct. That is problem. The organization and framework has to be redone and reoganized into groups and subgroups that can then be told to get their coloring and styling and such from a single-source that has that coloring information for each different object group. Right now, each object has it’s own manually hardcoded coloring. It’s extremely time consuming to retrofit code like that. I know because I actually did some of this when I was working through getting a certification for Java years ago. It sucks. It can be hard to find, decipher, change and reorganize/restructure into a new framework, test it out. It’s a bigger pain than I think people realize to retrofit old code to an entirely new framework, especially when the old code was done by a different programmer.
Don’t get me wrong, they definitely need to get through it, and I personally think they should’ve prioritized Dark Mode before starting a NEW project. But, I kind of wonder if whoever they assigned this task to, just told them; “Look, it’s going to take me just as long to manually go through all the code on this annoying plugin section as it would take me to just rebuild this Home screen segment. Why not let me make other updates to this section while I’m having to break down all this code anyway. It probably won’t even add a whole lot more time.” I wouldn’t be shocked to hear that this is exactly what happened and they’ll now move on to the next subsection in their list to update more of the app to the new theming framework.
Ultimately the main issue is the segmentation and hardcoding from the beginning of the app until now. It wasn’t designed with a framework that would support theming, etc. and now they’re trying to retrofit it to support that. It’s a pain, but it’s been one of the highest demand changes we users have been begging for, so they finally gave in. 
Hopefully they’ll get back to converting more of it to dark theme.