141–150 of 335 posts
Earlier quoted context omitted.
Their hinted opinion on that: > That being said, C/C++ are the only languages with a compiler supported by both Google and Apple, so using a different language would have created a whole host of other problems to deal with.
Is that still true? If Rust is built on clang it should not be that hard to port. Go also runs on both AFAIK.
1.5 years ago Dropbox was looking into rewriting their shared mobile codebase in Rust. It's a shame this blog post doesn't touch upon that at all, instead focusing on C++.
Their hinted opinion on that: > That being said, C/C++ are the only languages with a compiler supported by both Google and Apple, so using a different language would have created a whole host of other problems to deal with.
Earlier quoted context omitted.
Their hinted opinion on that: > That being said, C/C++ are the only languages with a compiler supported by both Google and Apple, so using a different language would have created a whole host of other problems to deal with.
I'm not sure why "supported by both Google and Apple" is supposed to matter. Apple doesn't need to ship a Rust compiler for me to use Rust.
Also the UI frameworks are being written in said preferred language these days, eg SwiftUI, and adding one additional language could be perceived as a pain.
TLDR - it's too hard to find senior C++ mobile devs. I'm more intrigued by AirBNB moving away from React Native - the linked article says "RN was too small a component to bother supporting, and the developer experience wasn't up to par", but I'd like more detail than that. I've been working with Flutter for the past 6 months, and it would definitely be my "go-to" for any mobile application. To be fair, I did spend 2…
Is flutter actually a good choice for a production app right now? I've heard really bad things about its bugs, but I admit it does look great to use and develop with.
It's a different story if you want to use native features. Plugins provided by community offer only basic functionality, and are often very buggy: you will encounter iOS bugs, Android bugs, Flutter bugs and plugin bugs, all in one package. Anyway, it sort of works if you plugins provide stuff that you need. If they don't, you are forced to fork the plugin and add ad those features, learning Android or iOS during the process, and writing a lot of boilerplate for communication.
This is precisely the experience of my startup trying to rely on flutter. It's a constant battle. Moreover Android and iOS are different implementation with different capability with constantly evolving API. It's hard to keep cross platform code in sync many #ifdef with edge cases. Moreover with REST API architecture majority of the common code is in back-end. So building in Swift and kotlin for respective platform i…
I've been building a Flutter app and it has been fantastic. I'm using one shared library flutter_barcode and while it isn't perfect, but it shows how easy it is to create native solutions for both platforms and marry them within Dart/Flutter itself. I can't see how duplicating code in Swift/Kotlin would be any better than just writing it once in Dart. Dart is also quite a nice language to work in. Easy to get up to s…
I like dart lang and done some small apps in it. It's Javaesque with similar style and learning curve. But still prefer Swift which is closer to python (we use python for back-end development) and Kotlin which has some nice functional programming primitives.
Also UX and guidelines are not uniform across mobile platforms. Android and iOS works in their own way to integrate different input like voice, visual and keyboard. Also mobile platforms on Android and iPhone are constantly evolving with new sensors, capabilities. Keeping native SDK itself is a gigantic task not sure how to manage cross platform SDK's. I am sure cross platform SDK can work for some use cases, but I feel it will still be way behind native SDK.
If back-end can take care of all the business logic and front-end manages UI and states with small necessary local data for offline, the efforts spend to develop cross platform app using flutter or natively in Swift and Kotlin won't be very different.
I still prefer REST over GraphQL because I like predictable performance in query and standard interface. Zen of Python PEP-20, explicit is better than implicit.
GraphQL is a solution to a problem of trying to manage business logic on client side so that it can manage ad-hoc query and get ad-hoc results from back-end. It was designed for a problem faced by Facebook. I have seen enough GraphQL code and still stay with REST Architecture, sometimes use protocol buffers for performance intensive parts.
Earlier quoted context omitted.
Their hinted opinion on that: > That being said, C/C++ are the only languages with a compiler supported by both Google and Apple, so using a different language would have created a whole host of other problems to deal with.
I'm not sure why "supported by both Google and Apple" is supposed to matter. Apple doesn't need to ship a Rust compiler for me to use Rust.
I have come to this same conclusion after many years. It's not cost-effective to have any bespoke business logic (models, controllers, etc.) shared between the two mobile platforms (don't get me started on sharing UI code). If you have some incredibly tricky low-level algorithm/library and/or need for speed, think database, crypto, intense graphics, etc., then fine, you may be able to swing a shared module in C++ or…
The article says it all - they chose the wrong language with no community support for the trail they were blazing and that technical debt destroyed their productivity. I achieved 90+% code share in Xamarin including UI across windows - ios - andriod. 100% buisness logic shared. You can write cross-platform UIs, and swap out to native code on a widget by widget basis. Threading is seemless. Sure it has its own set of…
And the same problem with using C++, you have to build the app around it, rather than using the best arch for android and ios.
First, it's not true that there's no C++ mobile community. There are plenty of forums, blog posts, projects, using C++ in mobile field. Xamarin and Qt are helping C++ Devs go mobile since years.
Second, it depends on which standard they've used. It looks like they choose a pre-C++11 standard, making things more complicated (in 2013 there were already full C++11 compliant compilers, even for mobile), especially threads. They probably forgot that Boost itself has modules for JSON, checks for non null objects and so on.
Third, they probably kicked off the project with some average C++ developers and they left. They haven't found cheap experts (compared to Kotlin/Swift, which are really cheaper) and didn't want to pay high salaries. The story that those Kotlin/Swift developers didn't want to learn C++ says a lot of the quality of those developers as well. Sure, it's matter of interest, but it was also a great opportunity to earn much more money as well.
As for build systems, it's true that it's an unsolved issue, but CMake is pretty much a standard and it can handle dependencies, if someone knows how it works. Sorry, but this is a story of poor choices and unskilled people for this huge job.
Earlier quoted context omitted.
You are right. I've done a lot of development in AIR myself and it is super impressive. Easy TypeScript like language. The Flex SDK is mature with all the standard stylable controls you need. Dedicated IDE that just works great. Easy deployment. I was able to build a cross platform (iOS/Android/Web/Desktop) video chat application with it and it looked and worked great everywhere. Someone dropped the ball somewhere wi…
I think it was sullied by the poor reputation of the Flash Player browser plugin. I agree that ActionScript was a pretty decent language to work in. I investigated Haxe briefly but found the community wasn't very big and the community that did exist was really fragmented.
imagine if you could write command-line tools and server-side apps with it, that would be the dream