71–80 of 123 posts
Earlier quoted context omitted.
C is also very simple to add security exploits to your app. I would never advise C unless the platform is lacking of a C++ compiler. Just use extern "C" at the boundaries.
What vulnerabilities does C introduce that C++ doesn't?
Since no one else has said it, I'll be the voice of reason. Share your design specs only, and let each platform team write the implementation in the language that they think best. Yes, you'll have two teams spending time on doing the same thing. However, you'll get important benefits. Each team will be able to implement appropriately for their platform. While iPhones and Android phones are rather similar in terms of…
There are lots of internals that could/should be shared between apps. Recently relevant examples: a customized WebRTC stack, a websocket client with extra authentication and delivery rules.
FWIW, my take on this has been to embrace Conway's law: if you have enough shared work to form a team around it, then break off a c++/whatever library and a team to maintain it. But if the hope is just to save 200LOC here and there, just bite the bullet and write it twice.
Big thanks to whoever pointed out Kotlin Native: seems interesting enough to poke around with.
Earlier quoted context omitted.
How do you propose that an security vulnerability in an iOS app that doesn’t result in a jailbreak will allow someone to copy the app from an iOS device on to another device? Also, are you claiming that using C == “not striving for quality” or that it is not “best practice” to use C? And on a side note, most corporations don’t care about “quality” or “best practice”, they care about shipping and selling software. Two…
Industry is young, but thankfully returning goods on app stores and suing companies for delivering bad software is starting to happen. I am claiming both when using a language whose security reports from Google, Apple, Microsoft, ARM, Linux kernel just increase in size every year with the amount of memory corruption and UB induced security exploits. Like those reports advise, usage of C should be constrained to envir…
What “safer” alternatives are better that give the performance needed, with tooling available and the cross platform requirements that the poster needs?
Also, you haven’t explained how a security vulnerability from a third party app can be “used for piracy”.
Where are all of the corporations that are being sued because of software quality and not using “best practices? I would say just the opposite, companies are being sued if anything for not meeting delivery dates.
The definition of enterprise software is basically poor quality software where the user is not the buyer and they have to work around bugs.
Consumer software is no better.
https://hacks.mozilla.org/2019/04/crossing-the-rust-ffi-fron...
This won't suit your needs for processing-heavy apps (though can WebWorkers help), but will work well for many apps (https://csform.com/top-10-apps-built-with-ionic-framework/ for a "top 10" list for examples).
I noticed after submitting that you mentioned machine-learning. Any reason you can't offload that to a web API and take the load off the client?
Earlier quoted context omitted.
What vulnerabilities does C introduce that C++ doesn't?
For example it is easier to avoid buffer overflows with std::string than with C-style strings.
We're using kotlin native, after considering rust for a bit. It's been working great, we've had it in production for about six months. Main advantages are * kotlin is a nice language with good type support * has good swift bindings out of the box * also compiles to js and cpp so we can use it in our Web product as well
C++. It is part of both SDKs, you have direct support for mixed mode debugging on the IDEs. No need of extra tooling. On Android JNI is always going to be a pain, but at least with C++ Studio gives you an hand on accessing JNI APIs.
Using Dropbox Djinni (https://github.com/dropbox/djinni) also helped with the horrible pain of JNI... although it's unmaintained these days. I guess people use SWiG now.
C++. It is part of both SDKs, you have direct support for mixed mode debugging on the IDEs. No need of extra tooling. On Android JNI is always going to be a pain, but at least with C++ Studio gives you an hand on accessing JNI APIs.
I would say use C. Interfacing C with Java is simple JNI. Interfacing C with Swift is very simple, too.
I don't think it's worth staying there - especially since C++ is a first party supported language on pretty much all platforms.