This is more about not finding enough developers for mobile C++, not much because of any sharing of code.
A single platform application with a C++ back-end would have the same issues.
The not so hidden cost of sharing code between iOS and Android
251–260 of 335 posts
Re: The not so hidden cost of sharing code between iOS and Android
#252This is wild. So Unreal/Unity and others somehow get to run their arguably vastly more complex engines on mobile desktop and consoles, but sharing some logic between iOS and Android is too complicated for Dropbox. What are they smoking?
I think it's exactly because they are so complex that those engines can afford to share a lot of code between platforms. For smaller and/or simpler applications, it's probably not worth it to deal with the cross-platform complexities.
Modern video game development is anything but simple.
Re: The not so hidden cost of sharing code between iOS and Android
#253I don't understand why someone at Dropbox's size and scale would go after C++ on mobile and blaze their own trail, when its probably more pragmatic to go native. With that being said, I worked for a firm that extended the life of old ERP systems and we had to do a few mobile apps, we chose Xamarin because we were a shop of 7ish devs that had many projects to maintain and the cost of code sharing and familiarity with…
Isn't Xamarin the IDE and cross-compiler? Last I saw, it took C# and cross-compiled to native Android and iOS apps. Or had a .net runtime that ran on both. Regardless, you need a C# developer if you're choosing Xamarin as your tooling.
We were all C# Developers.
Xamarin is both yes, though it really integrates into Visual Studio so its more of a tool? I am not sure, definitions like that are a bit murky.
Re: The not so hidden cost of sharing code between iOS and Android
#254This is wild. So Unreal/Unity and others somehow get to run their arguably vastly more complex engines on mobile desktop and consoles, but sharing some logic between iOS and Android is too complicated for Dropbox. What are they smoking?
I see you haven't worked on that level (or maybe you are young).... First, unreal/unity work at a different level of the hardware, and they have to deal with different graphic drivers, in the same type of the OS. But keep in mind that they are not the end product! The end product is the game that run on them. So, the cost to building a multiplatform game, is having a whole Game Framework (which are whole companies),…
This got me thinking: may be the right (low resource-high performance) way to do multi-platform software nowadays is to use a game engine instead of Electron.
Re: The not so hidden cost of sharing code between iOS and Android
#255Interesting post. I wonder if the major pain point was the fact that they were doing dev with a language that had nothing to do with either platform. We’re currently investigating Kotlin/native and it looks really promising. We don’t have to write stuff in a foreign language, but can repurpose our existing Kotlin code and share with iOS. This model seems promising. Does anyone have any experience with Kotlin/native?
C++ has lots to do with Android and iOS. On Android side, Vulkan, ML, real time audio are all only available via the NDK. Project Treble allows for Java and C++ drivers, but the large majority of them are actually written in C++. Real time audio framework, Oboe, is written in C++. The Play Games infrastructure is written in C++. On the iOS side, Metal shaders, former driver framework and the new one use C++. Objectiv…
Good points. I guess I didn’t mean that the language wasn’t valid or supported, but rather, that it wasn’t the main first-class language of the platform.
Re: The not so hidden cost of sharing code between iOS and Android
#256Using C++ for libraries was not a bad idea but I think they got the architecture wrong. They should have used a protocol like gRPC streams or flat-buffers to communicate between core libraries and the platform UX libraries. Basically the mobile app is treated as a frontend talking to a backend using a communication protocol. You can design this to be stream-based, event-based, whatever fits the boat best. Depending on the platform, you can choose what should be part of the frontend versus what should go into the backend.
This is the way a lot of the big C++ mobile apps are built. Also there are lesser debugging headaches as each part can developed independently thanks to de-coupling, so you can hire native platform developers to do the job they know best without messing with C++.
Re: The not so hidden cost of sharing code between iOS and Android
#257Earlier quoted context omitted.
I wasn't aware of the fact that react native is fragile - it seems I did the right choice by learning Flutter. I hope it evolves even better, and also the criticism to Dart for me is so far quite irrelevant, as there are already tons of libraries and it's really easy to learn.
May I ask what kind of stuff are you developing with it? I've been working on a WebRTC app myself with it, basically porting my app from RN to Flutter. So far I've encountered no major obstacles, just a little friction which is a part of the learning curve.
It's an ecommerce app that should integrate with Firebase and online shops. :)
Re: The not so hidden cost of sharing code between iOS and Android
#258This is wild. So Unreal/Unity and others somehow get to run their arguably vastly more complex engines on mobile desktop and consoles, but sharing some logic between iOS and Android is too complicated for Dropbox. What are they smoking?
I see you haven't worked on that level (or maybe you are young).... First, unreal/unity work at a different level of the hardware, and they have to deal with different graphic drivers, in the same type of the OS. But keep in mind that they are not the end product! The end product is the game that run on them. So, the cost to building a multiplatform game, is having a whole Game Framework (which are whole companies),…
I appreciate the lengthy answer, but it builds on the premise that I can't possibly know what I'm talking about because otherwise I would've come to the conclusion that code sharing just sucks. My point with engines still stands: they share huge chunks of codes. Even code that has nothing to do with low level abstraction (animation, loading models, mixing audio etc.). And yes, their job is to run on all their target platforms. But if your app targets multiple platforms that's your job as well.
What you described with spotify is that you were essentially building your own phonegap. That might be the right answer if you want to achieve as much code sharing as possible. But just because you can doesn't mean you should. You can't go ahead and make wrong abstractions and assumptions about platforms and then tell me I shouldn't even be trying because you failed at it, when others somehow achieved it. And I know several non-SV companies (a Navigation vendor I worked for for example) that ported their C++ code base to mobile in a matter of days. So it might as well be possible that the engineers in charge at Dropbox, FB etc. were lacking experience.
Re: The not so hidden cost of sharing code between iOS and Android
#259Earlier quoted context omitted.
I took a look at Xamarin recently to see how far it had come, and the tooling is really impressive. They seem to do a great job of keeping up to date with iOS/Android SDK changes, too. But when trying to find an example of a native-feeling Xamarin-based app for iOS, I was really underwhelmed. I tried to find one that was (a) well-known and (b) third-party (not developed by Xamarin or Microsoft). The 4 contenders were…
I believe the Fox Sports app was done by a company called WillowTree. https://willowtreeapps.com/company They specifically mentioned when I was interviewing there that the reason their Xamarin apps are so good is because they already know how to make good native iOS apps. Also, I specifically asked about whether or not they would be using more technologies like Xamarin in the future and they didn't seem too keen on i…
Thats the same experience with us except instead of Xamarin we used more popular cross platform mobile framework Flutter from google. Given most of business logic is maintained in back-end. Fron-end client be it mobile or web based needs UI and state management with some local data for offline storage. We thought it will be easy to share code across platform and we were so wrong.
Given advances in mobile platform and Native SDK a company like Google, Microsoft or Facebook will not be able to keep up with native SDK and will be one or two generations behind. You can see the result in issues on flutter project. Also given Swift has Python like syntax and ease of use with powerful toolchain and Kotlin with nice syntax with functional programming efforts are not that different working with native SDK.
Obviously this cross platform mobile framework are ok for simple crud apps. But when it comes to building a mobile app using modern vision, audio, keyboard, touch and gesture input along with modern sensors in the platform and provide a consistent UX is a big challenge. Also UI and UX have enough subtle differences across iOS and Android the code written to manage them is also substantial. So its nice to go native SDK route for mobile apps.
Re: The not so hidden cost of sharing code between iOS and Android
#260Earlier quoted context omitted.
The Skype engineering team is an acquisition with relative autonomy, and is always making weird choices. Wouldn't take that too seriously.
Microsoft Office has gone all in with React Native as well. Here is a recent comment from Andy Coates talking about MS Office Android performance: https://news.ycombinator.com/item?id=20413046 Other article talking about it: https://blog.appfigures.com/microsoft-goes-all-in-on-react-n...
They have addressed this at BUILD.
Xamarin for .NET devs, React Native for C++ devs (a bit like QML/Qt).
Office naturally fits the C++ devs way.