23 ms·

The not so hidden cost of sharing code between iOS and Android

• tomovo 7y ago
  Hard to take any of the arguments seriously when looking at the Electron app they just released on desktop.
  • kelnos 7y ago
    I initially had a similar thought, but I don't think that applies here. With Electron, you don't write a cross-platform base and then write all the platform-specific goo on top of it. You just write your app using web technologies, press the build button, and ship it on all the platforms you want to support. Since web technologies are popular, you don't end up with the same issues hiring and training developers like you do when you need to teach a new hire about your bespoke cross-platform mobile solution. With Electron, essentially your users pay for all of this by being forced to adopt a resource-hungry platform, while the development team gets a mostly-free pass.
    • seabrookmx 7y ago
      And while a lot of developer-y types complain, a bit of extra resource usage on a laptop/desktop isn't nearly as big of deal as it is on mobile. Especially if your business (like so many nowadays) has way more users on mobile than it does on the desktop.
• alexashka 7y ago
  Having worked in multiple places that ship iOS and Android, the real thing to focus on is cross-platform requirements, not code. Writing mobile apps is fairly trivial - writing good requirement documents is black magic I have yet to see in the real world. Trying to share code is like trying scratch your left foot when your right foot itches. The issue with two codebases that are supposed to do the same thing is keeping them in sync over time. The only way to do that is by having actual requirement documents.
  • kelnos 7y ago
    This made me think: I've found it hard enough to share code effectively on the backend, even when we're all using the same language and frameworks. And people think it'll be easy to share code when you're targeting two completely different platforms with completely different frameworks in completely different languages?
• draw_down 7y ago
  > Even before the core group moved on, mobile engineers were generally not interested in learning C++, so finding people to train was a big issue Yeah, I probably wouldn't be super interested in mastering the arcane details of one company's bespoke stack; that knowledge would be really difficult to leverage elsewhere. Most places that need mobile engineers won't care about the bespoke C++ stuff, and most places that want people to write C++ wouldn't know what to do with someone who wrote C++ for a mobile app.
• asdfman123 7y ago
  It's funny that they have a hard time hiring experienced senior C++ devs even though the language has been around so long. Presumably it would have been easier to find someone really good at something newer like, say, Vue.
  • hermitdev 7y ago
    Its probably more along the lines of they can't/weren't willing to pay for the experienced senior C++ devs. There are plenty of C++ devs out there (myself among them) that will jump ship for the right offer.
  • jjtheblunt 7y ago
    I wonder if that is a symptom of C++ having many recent revisions, thereby influencing, misleadingly, the definition of "experienced".
    • melling 7y ago
      I tried using C++ and Objective C several years ago. Compilation was incredibly slow. Maybe when C++ modules finally arrive things will improve.
      • saagarjha 7y ago
        I take it you haven't tried Swift ;)
        • rsynnott 7y ago
          Or (shudder) Scala. The only time I ever think “oh, this computer is a bit slow” of modern high end laptops is when it comes to Scala. I like the language, but the compiler is painful.
          • melling 7y ago
            Yep. I’ve got a 9 year old Scala repo on Github: https://github.com/melling/scala https://github.com/melling/scala I actually like the language but stopped using it because it was so slow to compile. I hear that it has gotten better so I’ve been revisiting it. Worksheets seem to help with development.
• dpezely 7y ago
  The overhead of C++ adoption actually prevented us from ever moving fully in this direction. Today, unlike in 2013 when they started, there are other options. For others considering code-sharing, another option not mentioned in their article is Rust for the core with Swift and Kotlin. Between bindgen, futures, serde_json and non-nullable pointers in Rust, those would satisfy their stated subcategories today. Companion templates are explained here: (January 2019) Medium.com/visly/rust-on-ios-39f799b3c1dd Medium.com/visly/rust-on-android-19f34a2fb43 (No affiliation other than starting to proceed down this path myself.) For Common Lisp heads, there's also MOCL, which seemed quite reasonable when I explored it years ago: wukix.com/mocl
  • saagarjha 7y ago
    How does Rust differ significantly from C++, other than the fact that neither platform's toolchain can compile it out of the box?
    • cakoose 7y ago
      I don't know enough details to say for sure, but some possibilities: 1. People may be more willing to learn Rust. I much prefer the language itself, but also it's clearly on the rise, so it may feel like a better learning investment. 2. The standard library is broader and the package ecosystem is easier to work with, so you might be able to have a more standard stack with fewer proprietary bits. 3. One complication with integrating multiple languages is making different memory management strategies coexist. Rust's type system seems to have ways of making that easier, e.g. neon-bindings.com
    • monocasa 7y ago
      Less foot guns. And it's not crazy in either env to have externally built libraries.
    • rapsey 7y ago
      It is really easy to make a blunder in c++ that will require a lot of effort to find. Debugging that on mobile platforms is not fun. Like they mention a deadlocking issue that was difficult to solve. Rust is built for memory and thread safety. Also the much better build system and open source ecosystem.
• CalChris 7y ago
  This reminds me of LLD’s approach of sharing an architecture but having separate ELF, COFF and Mach-O implementations. This made it much faster than gold which wasn’t actually slow. Apparently sharing code isn’t necessarily a great idea.
  • fsfod 7y ago
    They did start out with a shared atom model for all three platforms but switched away from to separate implementations for ELF and COFF http://lists.llvm.org/pipermail/llvm-dev/2015-May/085088.html http://lists.llvm.org/pipermail/llvm-dev/2015-May/085088.htm...
• saagarjha 7y ago
  I'm somewhat disappointed that this didn't work out, as I have usually promoted a C++ core along with a thin native wrapper as the solution for those looking to share code across platforms. At least they moved to native development, though, instead of some poor facsimile that was "easier"…
  • barbs 7y ago
    Curious about how well having that C++ core to share code has worked out for you in the past. Apart from low-level contained code that doesn't require access to too many OS interfaces (user I/O, network, threading, GPS etc) I can't imagine it would be easy or useful to have a C++ core.
    • saagarjha 7y ago
      Usually C++ runs core logic that cannot go on the server (that's things like your own custom client-side crypto, parsing, or other "pure computation") and then you make the user interface in Swift or Java depending on your platform.
      • barbs 7y ago
        That makes sense - basically anything that is self-contained and can run "in a vacuum" so to speak can be C/C++.
• dougk16 7y ago
  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 something. Other than that, it's almost like the collective consciousnesses of Google and Apple conspire to make cost-effective code-sharing of typical CRUD apps almost impossible. Here's a fine alternative to code-sharing: well first and foremost you need to have a good requirements spec. After that, implement it on one platform first in a platform agnostic way. So heavy use of delegates/interfaces/injections to handle platform-specific functionality, even for one-liners like getting current system time. So the code should be pure, boring, plain old Java, Kotlin, Swift, whatever. Minimal use of fancy language features that may not port cleanly. After one platform has the module in place and well-tested, do a copy/paste port to the other platform. You will find that the copy/paste port will actually uncover bugs, optimizations, edge cases, etc., that can then be ported back to the original platform. Things you would not have found if you were only writing the code once. It's like the most intense kind of PR code review you can get. So I've found that copy/paste-port-based code sharing between platforms is not just a lesser evil, but actually a strategy that has its own unique benefits. If you get into a groove you can build up a set of regexes to give you a sloppy transpiler that does most of the tedious porting for you.
  • paulryanrogers 7y ago
    How does that work out when things change over time: requirements and the platforms themselves?
    • Scarbutt 7y ago
      Rinse and repeat.
      • dougk16 7y ago
        Ha beat me to it!
• tyingq 7y ago
  There's quite a few places that are still dealing with 4 codebases with varying degrees of shared code. Desktop, mobile web, native Android, native iOS. A shame, since many of them don't really need more than one responsive web codebase. Native apps do add value for many use cases, but not all.
  • jdnenej 7y ago
    They add value in all cases by not needing 200mb memory to run what would be a 20mb app for native. It's crazy how my phone runs perfectly fine on 2gb ram but my laptop is swapping with 16gb just because slack, vscode and whatever else election app is running.
    • tyingq 7y ago
      I wasn't suggesting electron. Just a responsive website when that's sufficient.
      • tim58 7y ago
        Most websites are resource hogs.
        • tyingq 7y ago
          So, 3 codebases or be careful about your website...for cases where a native app isn't truly needed.
• vpontis 7y ago
  For UI, react-native is really good for sharing code between platforms
  • bfrog 7y ago
    If your a sadist maybe
    • zwetan 7y ago
      /your/you're/ and I think you meant masochist
      • mlvljr 7y ago
        They could be a manager.
• darshan 7y ago
  I just launched (like, an hour ago: https://news.ycombinator.com/item?id=20700196 https://news.ycombinator.com/item?id=20700196) a cross-platform app that is almost all shared code. In my case, the solution is a web app with very lightweight native wrappers, and I'm quite happy with it. Obviously that wouldn't be the perfect fit for all apps, but none of Dropbox's "(not so) hidden costs" are relevant in my case, and I suspect many apps would be a good fit for the architecture I went with.
  • gok 7y ago
    So you didn't launch an app at all; you launched a web page and submitted a single-site web browser to both app stores.
    • darshan 7y ago
      Nope, that's not accurate at all. The native apps support push notifications, in-app payments, native UI elements, proper lifecycle management (storing in-progress doodles across the app being killed in the background, or the device being restarted, for example), and more offline support than would be possible with the website. Among other things. The things that are in the native wrappers are things that would be iOS-specific or Android-specific regardless of zero shared code or maximum shared code. In my case, the bulk of the app is shared -- everything that can be a common code base is a common code base. According to GitHub's rough metrics, that's: Go 44.7% Dart 32.8% Java 7.1% JavaScript 6.9% Swift 6.6%
  • morcutt 7y ago
    Most cross-platform solutions are great in the beginning and then the problems start to come to surface as teams grow, requirements change, bugs are harder to track down, code needs to be updated, the next hot cross-platform framework comes along with new promises, etc.
    • deleted 7y ago
      [deleted]
    • 7y ago
• softfalcon 7y ago
  Recently worked at a company doing similar to this to support Windows and macOS. To add to the difficulty, they used Chromium as a UI front end much like Electron. All built in house though. They hired me as a JS/HTML/CSS dev, but same as the article states, the C++ work was the true bottleneck. They knew I had some C++ chops and set me to work doing C++ with a sprinkle of JS here and there. Due to incompatibilities in the compilers, there was a rats nest of dependencies, thousands of #ifdef’s to cover differing OS implementations, and we had to use some of the oldest versions of C++ to be compatible with both XCode and Visual Studio. As the article states, we had custom background job libraries and debugging them was a nightmare. Also similar to the article, we spent more time than one ever should setting up builds to handle our ludicrously complicated build configurations. And lastly, as the article stated, we had a hard time finding new talent to cover the growing amount of work required to deliver our product. There just aren’t many C++/JS devs out there.
  • shaggyfrog 7y ago
    > And lastly, as the article stated, we had a hard time finding new talent to cover the growing amount of work required to deliver our product. There just aren’t many C++/JS devs out there. Reading the article and now this, I really can't grok this perception. There are plenty of us out here, I think, it's just we're buried in the heap caused by mass resume farming, aka modern recruiting. Recruiters and hiring managers don't think of me as a senior dev with 15 years writing software and delivering value to end-users... I'm just YA candidate who doesn't have any experience in the latest JS framework du jour, so I might as well not exist.
    • softfalcon 7y ago
      Addressing JS, they were using aging jQuery with other vanilla JS. Nothing fancy. As for finding people like yourself, all I kept hearing was that they had trouble finding new people to fit their specific needs. I agree with you though, there is likely a lot of missed opportunities due to the resume farming going on and bad filters.
  • ben-schaaf 7y ago
• dragonsh 7y ago
  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 is not as tedious.
  • cutler 7y ago
    What kind of battle? Can you elaborate?
    • dragonsh 7y ago
      Just one example of an open issue https://github.com/flutter/flutter/issues/22860 https://github.com/flutter/flutter/issues/22860 If I use swift I get all the code examples and tons of documentation from Apple itself. In flutter I need to rely on some package which might not be supported, if my team takes over it's double the job fix the package bugs and also change the resulting changed in code, compile and test individually on iOS and Android. Another one https://pub.dev/packages/sensors#-changelog-tab- https://pub.dev/packages/sensors#-changelog-tab- And there are many such issues.
  • The_rationalist 7y ago
    Could you explain what you think of the pros and cons of flutter VS IONIC? I think flutter and it's astonishing number of issues on github + their lack of manpower + their lack of major features + the presence of major performance and behavior bugs + the extremely small lib ecosystem (dart) is a major, useless risk for a startup for the benefit of tech hype. (just my point of view, don't take it personally)
    • MarkMc 7y ago
      One of the pros of Flutter is that its popularity is growing strongly while Ionic's is basically flat: https://insights.stackoverflow.com/trends?tags=flutter%2Cionic%2Cionic4%2Cionic2%2Cionic3%2Cionic-framework https://insights.stackoverflow.com/trends?tags=flutter%2Cion... I haven't tried Ionic myself, but I have tried both React Native and Flutter for a small project and found Flutter to be more enjoyable and productive.
• zwetan 7y ago
  another code-sharing solution that everyone enjoy to ignore is Adobe AIR in 2013, AIR was v3.6, now in 2019, AIR is v33.0 not only you share code via ActionScript 3 (something like TypeScript just available 10+ years ago) but you can also develop ActionScript Native Extension (ANE) in C, C++, Objective-C, Java, C#, Swift, etc. and it does not only publish to mobile it also publish to desktop but that's OK, keep ignoring it
  • trixie_ 7y ago
    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 with AIR.. I'm amazed they're still updating it.. that's something at least. I guess it lives on here? https://github.com/apache/royale-asjs https://github.com/apache/royale-asjs Still looks active.. Here's a demo https://royale.apache.org/tourdejewel https://royale.apache.org/tourdejewel
    • zwetan 7y ago
      Apache Royale is not the same thing it allows to compile ActionScript to JavaScript and so publish for the web Adobe AIR is a compiler and a runtime for iOS it compile AOT, for other platforms: Android, Windows, macOS, (and Linux) it compile JIT the runtimes share the AVM2 (ActionScript Virtual Machine) and the Flash Platform API, which allow to share a lot between platforms
    • seabrookmx 7y ago
      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.
      • zwetan 7y ago
• s_y_n_t_a_x 7y ago
  It baffles me that people think duplicating application code for every device is the way to go. Cross platform can be done correctly. I'm working on a stack that can natively target Windows, Mac, Linux, Android, iOS, MacOS, and Web. I couldn't imagine duplicating my code for each one of these devices. If something special needs to be done, I write an extension. I have a feeling posts like these get upvoted because developers who make the native apps want to keep their jobs. But those developers will always be needed for the native bridges, just not as many of them.
  • jgust 7y ago
    I took this as an argument for a thin, or at least thinner, client. If something is complicated and costly to maintain - shouldn't it move to the server? What complicated processes are you doing on-device that couldn't be done somewhere else & fronted by an API?
    • T-hawk 7y ago
      Anything you want to run locally without being tethered to always-on connectivity, for one. Or just anything you want to run without network latency.
  • srcmap 7y ago
    Which framework are you using for this?
    • s_y_n_t_a_x 7y ago
      React Native
      • matchbok 7y ago
        Done correctly != react native. I've had to shut down and migrate 3 RN projects because of how much of a mess it is. It's not even 1.0 and is a horrible choice for important apps.
• joeblau 7y ago
  Here is the genesis of this blog post: CppCon 2014: Alex Allain & Andrew Twyman "Practical Cross-Platform Mobile C++ Development[1]. [1] - https://www.youtube.com/watch?v=ZcBtF-JWJhM https://www.youtube.com/watch?v=ZcBtF-JWJhM
• drabinowitz 7y ago
  I've been considering building a pwa and using a webview as a pseudo native app I know iOS support isn't great but it seems to be improving and iOS push notifications could be built separately in the meantime. How's anyone tried this approach?
  • t1amat 7y ago
    While PWA’s largely work, they provide a poor installation experience and little device integration. Most people use Apache Cordova, PhoneGap, or Ionic as wrappers to their mobile web app, providing expected installation experiences through app stores and common device integrations.
  • LeoNatan25 7y ago
    Are you really asking if someone has tried putting their website inside a webview and call it an “app”? Have you heard of Electron, Cordova and tons of other crapware that help produce so much garbage “apps” every year, it would put to shame even the most toxic enterprises in an unregulated Republican dream?
• bstar77 7y ago
  I shudder to think how many people will read this headline and immediately takeaway that React Native/Flutter/Electron are terrible cross platform solutions.
  • chipotle_coyote 7y ago
    I'm hoping more people will read this headline and at least take away that RN/Flutter/Electron should be approached with caution and care rather than "slap it in an Electron shell and it'll run great everywhere and everyone will love it," which is the implicit attitude that makes so many people, uh, not love it.
  • LeoNatan25 7y ago
    That’s a perfectly legitimate conclusion to make, especially with the examples you mentioned.
  • K0nserv 7y ago
    React Native, Flutter, and Electron have a lot of problems in between them. They are fairly good cross platform solutions, whether cross platform UI is actually a good idea is much more dubious, I lean towards no it's not. I'm more excited about leveraging native platform UI with shared code in a common language like Rust. C++ as described in the blog is problematic for this.
• avinium 7y ago
  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 weeks going down a rabbit-hole to get Flutter talking to a .NET assembly by embedding Mono and invoking via JNI/Obj C, so I know the pain of native interop. If you're mostly doing work at the native platform level, then I can imagine why you'd stay away from a cross-platform VM. In my case, I ended up with a brittle project that was clearly going to be a PITA to maintain & automate builds for, so I just rewrote the component in question in Dart.
  • bobthepanda 7y ago
    AirBnB has a series of in depth blog posts about their decision to abandon RN. In particular this quote seemed extremely worrying to me: > While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit when toLocaleString worked on iOS but only worked on Android while debugging. It turns out that the Android JSC doesn’t include it and it was silently failing unless you were debugging in which case it was using V8 which does. Without knowing technical details like this, it can lead to days of painful debugging for product engineers. https://medium.com/airbnb-engineering/react-native-at-airbnb-the-technology-dafd0b43838 https://medium.com/airbnb-engineering/react-native-at-airbnb...
    • abacadaba 7y ago
      Having been bitten by this exact issue one or two times, meh. Par for the course in the life of a Javascript dev, really. RN would definitely still be my go to tool for the majority of green-field mobile apps. If I'd already invested in learning flutter/Dart I'd probably feel the same about that, but certainly feel no urgent need to go out and learn it. As in, I don't think there's a significant difference in what I'd be able to accomplish, and my time is probably better invested elsewhere.
• babesh 7y ago
  Would like to see an analysis of the costs and benefits of two separate codebases after they are done with that and have given it time to prove itself... especially with the more complex code.
• eridius 7y ago
  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++.
  • deleted 7y ago
    [deleted]
  • zZorgz 7y ago
    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.
    • api 7y ago
      Is that still true? If Rust is built on clang it should not be that hard to port. Go also runs on both AFAIK.
      • sally1620 7y ago
        Runs on a platform is very different from "officially supported"
    • eridius 7y ago
      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.
      • zZorgz 7y ago
        Likely too much friction. Native environments benefit from using the expected IDE and tooling integration to build UI apps on respective platform. C or C++ is the best common supported language, and they didn't even like that. 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.
• m3kw9 7y ago
  Code reuse on anything that is too complex will usually give you these issues as reuse doesn’t scale unless is very simple and function is super well defined and focused. Programmers will turn it into a monster as it evolves, usually
• jacobsenscott 7y ago
  Add more fuel to the "write once, run anywhere" dumpster fire. Let's peek in there - I see C, C++, Java, JavaScript, stored procedures, wxWidgets, RubyMotion, GTK, QT, object oriented programming, functional programming, PhoneGap, React Native, Flutter, ... It is getting full in there. What's that about the definition of insanity? Doing the same thing over and over and expecting a different result? Sever side rendered HTML is the closest we've come, but that's not cool anymore.
  • timw4mail 7y ago
    wxWidgets does actually get close to that mark. But regardless of the library/programming environment, there will always be platform-specific code you have to deal with.
    • shaggyfrog 7y ago
      I don't think wxWidgets is a strong example for cross-platform success. While admittedly I haven't touched wxWidgets in years, back when I used it, I marvelled that it worked at all, as the source code was such an utter mess. For example, I found a bug where a class constructor would raise lifecycle change events before the constructor even finished, and the issue was brushed away on the mailing list. Argh.
  • rtpg 7y ago
    Electron. It works pretty well if you're OK with the huge resource usage.
    • JustSomeNobody 7y ago
      > It works pretty well if you're OK with the huge resource usage. Isn't that an oxymoron?
      • NateEag 7y ago
        No. If the user interface is usable and snappy, it is probably fine that it consumes twice as many resources as a similar native app would require for the same result. Example: Slack.app is a huge memory hog (though not as bad as it was before their rewrite), but it fits decently into OS X and does not lag on me. I have lots of RAM, so the extra consumption is fine. Sure, it annoys some programmers that it could be more efficient, but other than them, who cares? Those guys are probably using Emacs or a CLI program as their client anyway. (I must be a rare breed, since I do email, writing, and programming in Emacs, but not chat)
• wildduck 7y ago
  Unless you need something very specific for the display UI. Try cordova (open source version of PhoneGap), and stuff like ionic, framework7.io, mithril.js will mostly get your most apps done needed while still sharing the code via JavaScript, HTML5/CSS. for anything native you can always write your own cordova-plugin if it doesn't already exist.
• mmastrac 7y ago
  We've had a mostly different (positive) experience doing a similar thing at FullStory for mobile instrumentation, though I think I know where some of the key differences are. Our core "business logic" lives in Rust. This is a shared bit of code between Android & iOS that mainly deals with orchestration, serialization, and server communication. We managed to extract ~1/2 of each platform's native code into this shared orchestration. What's left on each platform is more like a platform driver. I fully admit that things are different for us because we're not dealing with a bunch of UI that we manage (instead we're dealing with UI that our customers have written in Java/Swift/Objective-C/etc), but I think that there's a few places where we've made this work in a better way: - We've chosen flatbuffers to serialize most (not all) of the data between the platform drivers and the shared library. - We're using a language that's a little more hip. It's still not very easy to hire Rust developers, but developers interested in Rust are _very_ interested. - We built tooling early on to make this pretty seamless. Our Rust code builds in XCode and gradle, so there's no real friction to a developer getting up and running. Our team is about a year in on this transition to Rust and so far it's helped us move far quicker, especially given the size of our team.
  • debt 7y ago
    “Our core "business logic" lives in Rust.” Uh oh. So immediately you do understand that you have taken on the risk of potentially being unable to find any good(or bad) Rust engineers in the future, correct? Also they won’t be cheap as there won’t be many of them. A smarter, business-friendly, future-proof approach would be to have done that in Java. Future you will want you to have done that in Java, but if you’re trying to retain good engineers maybe I get the Rust thing.
    • ahmedalsudani 7y ago
      I think many of the best programmers would jump at the opportunity to work with Rust. That might change if the language de jour changes but working with rust is a positive for many of the best people right now.
    • mmastrac 7y ago
      I see you got downvoted here, but I think it is worth replying. We evaluated using Java on both iOS + Android (transpiled to iOS in some form), but what tipped the scales towards Rust was the "fearless concurrency" (that turned out to match the marketing) and the risk around the current state of transpilers. I was a fan of Java for a very long time. It was my language of choice from early 2000s to mid 2010s. It does _amazing_ things with keeping memory management out of mind (while still giving you the the "backdoors" to make things work well if you need a non-gc approach), but thread safety continues to be a glaring hole. From a former Java super-fan, I honestly think the future is Go + Rust. FWIW we also evaluated Go as a shared language, but there were risks around integrating our Go shared library with apps that may include some pre-existing Go code.
• JamesSwift 7y ago
  Find and hire candidates with this very specific skillset (we tried to hire for this role for over a year with no success) Really? You weren't able to fill this role? I can almost guarantee that you could throw an extra 25-50k at someone competent to fill it. In the end we no longer share mobile code via C++ (or any other non-standard way) and instead write code in the platform native languages. I've started to comment on this across the interwebs. If you are a cross-platform (native) mobile developer, and haven't taken a look at Xamarin, you _need_ to give it some attention. Xamarin.Native specifically is the best solution I've come across that mostly gets out of your way, and has robust library ecosystems and sane interop.
  • psyclobe 7y ago
    Funny, I applied, 20+ years experience in C++, on mobile too, writing a competing product.. odd never got a call back ;p
• wsc981 7y ago
  Since it's not stated in the article, I am going to assume they haven't tried Xamarin. I've been really pleasantly surprised lately how much code can be effectively shared when using Xamarin Forms. I haven't encountered much problems, except when dealing with tricky stuff like the Android camera API's (which, from what I understand, is problematic in native Android code as well).
  • dmitrybrant 7y ago
    How about running a background service to synchronize a local folder of content with a remote server? Making sure the background service is launched correctly upon startup? Integrating with the OS's native sharing features with other apps? And so on. In my experience, using a "cross-platform" framework means that you'll write the code not once, but three times: once for the cross-platform framework, and once per platform (Android / iOS) given all the quirks and unavoidable customizations that will need to be made to make your app function correctly.
    • wsc981 7y ago
      For platform specific stuff it's easy to write a wrapper. Most of the time Xamarin is very closely up to date with Apple's SDK, due to some automated tooling that generates the C# classes, interfaces and such. So you should be able to either use the C# wrappers for platform specific functionality, or alternatively can quite easily create your own binding using the Sharpie tool [0]. The last 2 apps I've been working on were Xamarin apps and I'd guess the first app probably shares 80% - 85% of the code base and the second app 95%. The first app less, because the client wanted a specialised camera module, which required me to create bindings for the Fotoapparat [1] library on the Android platform. Both apps used Xamarin Forms. The platform specific code, all things considered, is really small. I should note I've also done a lot of Swift & Objective-C development in the past and a little bit of Java. I also tried Xamarin around 2013 and back then the experience wasn't as good as it's right now. My major gripes with Xamarin currently are: - The IDE becomes slow sometimes (fixed with a restart) - The IDE sometimes has issues connecting to the Android emulator for debugging (often restarting the computer fixes this). I should also note that if I were to write an iOS only app, I'd definitely use Swift (I love working in Swift, more than C#, Objective-C, Java, …). But for multi-platform apps, currently my tool of choice is Xamarin. --- [0]: https://docs.microsoft.com/en-us/xamarin/cross-platform/macios/binding/objective-sharpie/ https://docs.microsoft.com/en-us/xamarin/cross-platform/maci... [1]: https://github.com/RedApparat/Fotoapparat https://github.com/RedApparat/Fotoapparat
• deleted 7y ago
  [deleted]
• psyclobe 7y ago
  I was the engineering manager for a time at a company who launched a competing product to dropbox (its dead now). During my time there we deployed a common c++ core that did the business logic, and we wrote the uis in Qt with Qml for the forms. We also used swig to export the c++ objects to java. Our ui forms looked native, and they ran on every mobile os at the time (Windows phone, iphone, android), and we even used some of the Qml forms on our desktop ui. Yes it was kind of a pain in the ass to share code like this, but it worked, and the mobile guys mostly just dealt with the specific problems relative to the mobile domain and not api integration issues with our cloud. That being said, I can tell you for certain our mobile devs (most of them anyway) would've preferred writing their own client api in the native language of the platform. Maybe Dropbox just got tired of dealing with that, they have the money now to hire fleets of engineers to write just about anything on any platform, why would you even bother sharing a client library in that case? But in our case, we were a small team, so we really didn't feel comfortable just letting the next mobile dev who walked in the door come up with another foundation library. Coding is hard, coding with a team is even harder.
• rkagerer 7y ago
  Write once run anywhere seems to be the eternally elusive holy grail of cross platform software development. It's a shame AppForge died right before mobile took off (tongue in cheek).
• jdswain 7y ago
  I've been using C++ to share code between iOS and Android for years and have come to the same conclusion. I developed the C++ code on desktop operating systems which was easier to debug, but once you move it to mobile then the debugging gets a lot harder (on Android at least). The overhead of the JNI interface is quite a lot of work too. Luckily I had a UML model that I generated the interfaces out of, so adding JNI was just a matter of templating this out of the UML, but it was still quite a bit of work. On iOS the situation has gotten worse in that the interface between Swift and C++ has to go through C, so if you are using C++ you need a special interface layer, which is almost like the JNI situation on Android. So you have the trade-off of on one hand having two code bases (Swift, Kotlin) and the associated headache of keeping them in sync, versus the extra work of maintaining the C++ interface layers and testing and debugging on each platform. In the end I now believe that it is better to work with the platform native development tools rather than trying to share C++. As far as finding developers goes, because of the rarity of using C++ on mobile there will not be a lot of developers with this experience. I work remotely and have found that any remote C++ work is very rare, Swift and Kotlin are a lot easier to find work with (it's still more difficult that you would think to get remote work of any type).
  • therockhead 7y ago
    >On iOS the situation has gotten worse in that the interface between Swift and C++ has to go through C, so if you are using C++ you need a special interface layer, which is almost like the JNI situation on Android. I’m curious why you don’t add an Objective c layer for C++ interoperability, I’ve done this in the past and it works a great.
    • jdswain 7y ago
      It's mainly because I'm trying to write everything in Swift now rather than Objective-C. I still think Objective-C is a great language, but Swift is the future of iOS development. It was easier in Objective-C as you could just rename your code file with an extension .mm rather than .m and that made it Objective-C++ and then you could import your C++ headers and use your library as you should. With Swift you don't have that option, and even the interface to C is more difficult. Even with Objective-C there is still some work in converting data formats (NSString to std::string etc.) and you need to be careful of C++ exceptions and NSException.
• ksec 7y ago
  I wish all the articles and blog post are like that. The first sentence sort of gives away what you need to know. Until very recently, Dropbox had a technical strategy on mobile of sharing code between iOS and Android via C++. The idea behind this strategy was simple—write the code once in C++ instead of twice in Java and Objective C. A lot of people will stop reading after this, for those interested they could continue with the details.
• unnouinceput 7y ago
  Due to C++ inherently close connection with the OS I see this as an absolute happening. But they should've go with Objective-C and Java and stay with them, as they were the matured technologies back in 2013 for their target OSes. Instead they chose another young ones. Oh well, not going to cry due to Dropbox making Kotlin and Swift better due to still lack of libraries there for their purposes. The more the merrier, that's my motto. My absolute fear is the manager's dream to only UML be as programming language and they drag'n'drop with no coding behind (the wet dream back in 2005 my manager at Siemens had, and he told me the world is going that way. Ya sure buddy, not if we let it happen and so far instead of unification we have even more diversification)
• irjustin 7y ago
  The common thread that I personally see between dropbox and airbnb, though completely different language sets, is adopting a shared codebase in a "brown field" manner. Airbnb admits if they were able to greenfield React Native then there's a world where it would have worked. Separately, the complexity of Airbnb and Dropbox as apps is very high compared to what I believe are the ideal use cases - simple interface apps that are thin wrappers on top of APIs.
• breatheoften 7y ago
  > Because this issue involved debugging multi-threaded code running back and forth between C++ and Java it took weeks to nail down! I don’t think the issue here is the use of c++ — it sounds to me like it’s the use of c++ on problems that would have been far simpler solve on the native code ... not all problems are that way — but even where it makes sense to solve with c++, you have to be careful about the glue. I developed and maintained cross platform c++ for iOS/Android in a previous role and the platform to native glue is inherently complicated — among the most complicated parts of the program to reason about if you get into the details of it. I solved by making this layer dead simple — you could almost never pass objects in or out — just primitive values. The c++ layer exposed to platform was just static methods — including a bunch of methods for retrieving state and we added more static methods when new kinds of communication were required. Every c++ method grabbed the largest lock it could prior to doing anything natively (and in debug mode related methods associated with some kind of stateful lifecycle would fatalError if they couldn’t get the needed lock — the app code shouldn’t have been calling into native code in a way that violated simple assumptions about how the state was allowed to change). Interestingly — this forced the platform layers above to comply with the assumptions needed to keep the native code simple — and helped those working on the UI immediately find out when they were violating these assumptions — things like click handlers that weren’t debounced or weren’t switching to a disabled mode after being clicked — when those click handlers invoke native code and that native code mutates state — you have a potential nightmare scenario for robustness ... This model actually was quite straightforward to add new functionality to over time and we frequently moved decision authority over complicated logic into the native layer so that we could make it robust and cross platform ...
• dilawar 7y ago
  How's was your experience in writing iOS and Android app in Cordova? I have a small community app written in Cordova+f7+vue2 which works pretty well on Android. I want to port it to iOS now as there is some demand. I also want to add push notifications later. So far there is a inhouse API+server which serves as backend. Not dependant on Google for any services as of now; only if there is a non-firebase solution to push notifications?
• jugg1es 7y ago
  I often struggle trying to explain to more junior developers that there are times when it's OK to write code more than once. There is a mindset that you should only ever write code once. It exists for (very) good reason. But if you follow it dogmatically, you may end up with an unmaintainable tangle of dependencies that can only be resolved with a rewrite. Sometimes, it's OK to write the same thing twice if the alternative is a major refactor - such as inventing your own stack.
  • phaedrus 7y ago
    At the very least you need to repeat yourself in as much as repeating the names you defined for constants, variables, macros, and functions when later invoking them. A program written in the limit of the style of don't repeat yourself either repeats these names many times and/or has too many layers.
    • gnychis 7y ago
      Hi there, sorry to hijack this post. We actually had a brief exchange a few months ago here (https://news.ycombinator.com/item?id=18133835 https://news.ycombinator.com/item?id=18133835). I didn't notice you had responded until now and that is now "locked." Are you still working on RPA? If so can you reach out at george@soroco.com? Thanks a lot!
  • reallydontask 7y ago
    You are fortunate if you only have to explain it to juniors. This seems pretty prevalent among senior developers too, in my experience. The most egregious case was, this guy I worked with, who would just straight up start with abstractions to avoid any duplication and enable other use cases. Now, 9 out 10 times the use cases catered for by the abstraction failed to materialise (bloody customers) but boy did he let you know when he hit the abstraction lottery and what he'd done neatly fitted in with a new use case. I think the term for what he created was ravioli code although maybe some of it was lasagne code
    • taurath 7y ago
• robdachshund 7y ago
  I just turned my web app into a mobile app using cordova and pwabuilder-cli. Was super easy.
• reindeerer 7y ago
  Nah, this is bunk. The cost of code sharing on top of something like Ionic is next to nothing. And for every platform specific feature you can just plumb in whatever plugins you want.
• wpietri 7y ago
  What I don't see them saying was that it was the wrong choice in 2013 for a scrappy team and an evolving product, just that it's not the right choice in 2019 for a company with ~infinite dollars and a stable product. I'm looking at building a mobile product solo right now, and I'm finding Flutter a pretty compelling idea. Building everything twice means being circa twice as slow, meaning I can learn about what the market needs half as fast. I might be wrong, of course, but this isn't the article to persuade me otherwise.
  • h3ctic 7y ago
    I'm in the same boat, but chose React Native instead because learning more React + JS/TS has additional benefits
• shmerl 7y ago
  Apple also still refuse to support Vulkan natively. They are one of the worst lock-in offenders today.
  • pjmlp 7y ago
    Unreal, Unity, Adobe, Disney, OTOY, Fusion, Cinema4D, ... are pretty fine with it.
    • shmerl 7y ago
      What's fine with wasting effort on pointless duplication? You made this false claim many times in the past, but it's as false as it was before. And your support of lock-in practices is strange to begin with.
      • pjmlp 7y ago
        Go learn about the industry business practices to start with, an advice you keep ignoring. Some people never get tired to fight windmills.
        • shmerl 7y ago
          You repeating the same thing won't change the fact that lock-in is a foul practice that simply taxes developers for the benefit of those who want to hamper competition. Only shills support such approaches. You perfectly well know it yourself.
          • pjmlp 7y ago
            Somehow it makes you feel good to call me and others that enjoy the productivity of better tooling shills. Do you think it matters at all to us with actual experience passing by the soap box?
            • shmerl 7y ago
              Enjoying lock-in - that's a new one. Instead, I enjoy breaking it (for example by using dxvk).
• cbsks 7y ago
  It seems like the real issue was that Dropbox lost all of their senior C++ engineers. That’s a real mistake on their part, losing the only people who truly understand your product can be a death sentence for a company. I know my employer is very conscious of who knows what part of our products, and does their best to ensure that we never have any knowledge gaps.
  • chadaustin 7y ago
    You’re definitely warm. I worked at Dropbox around this time and there was very little C++ or systems experience in the building. I think it’s expertise they tried to build but for whatever reason didn’t. I work at Facebook now and the difference is night and day. FB does share a ton of code across platforms, and it doesn’t even feel controversial. I don’t think Dropbox made a mistake in cutting out their shared C++ code, but I would caution against generalizing code sharing as a bad idea.
    • babesh 7y ago
      It was partly organizational imho. Oftentimes non mobile teams would write C++ modules. After writing the module, that team would refocus on server but the module would have remaining hard to find bugs (sometimes due to lack of mobile expertise) or could just use additional love and care. Sometimes these modules needing care and attention were even written by mobile specific teams. These were also due to insufficient organizational attention.
• deleted 7y ago
  [deleted]
• IloveHN84 7y ago
  It looks like that took very poor decisions such as bad frameworks and in-house made libraries vs what was already existing. 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.
• rock_artist 7y ago
  I'm also in that approach for the same reasons. Currently I have an app I'm cross-developing with separate iOS / Android codebase. the only 'shared-code' is Firebase libs for each platform (which seems to be written in itself cpp and bind to Kotlin / Swift). C++ itself is pretty portable. There are actually frameworks (QT / JUCE) that allow true cross-platform builds. They work, but you'll eventually end up having a lot of branches for specific platform. Still if you just need basic algorithms (signal processing or anything expensive CPU based) C++ might be good enough to write simple callbacks with bindings. Evil UX/UI: ----------- Xamarin, Flutter, React Native - It really depends on the app. but if the app needs to be in the "device" UX and the unique APIs provided by the platform. people can glorify the cross-platform all they want but, You'll eventually end up with branches for each platform in the good case and bad performance in the worse case.
• krzat 7y ago
  Current state of sharing code between platforms is quite terrible. Most languages support only C FFI, so if you write shared code in C++, will require bridge from C++ to C and then bridges from C to native platforms. For CRUD core, this kind of overhead makes no sense. I think this situation could be improved with automated generation of bridges. Apple implemented this pretty well for their own purposes, you can call Swift from ObjC and ObjC from Swift quite easily.
• archeantus 7y ago
  Interesting 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?
  • PunksATawnyFill 7y ago
    "but can repurpose our existing Kotlin code and share with iOS" How so?
  • pjmlp 7y ago
    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++. Objective-C++ is part of the SDK and allows for easy interoperability between Objective-C and C++. Swift and clang build on top of C++, thanks to LLVM. Finally, C++ is part of the official language list on both platforms. So contrary to urban myths, C++ has plenty to do with both platforms.
    • archeantus 7y ago
      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.
• emsy 7y ago
  This 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?
  • psyclobe 7y ago
    Games are wholly enclosed binaries that render everything in open gl or whatever, their entire ui is written in the 3d space, so there's less layers I'd imagine.
    • emsy 7y ago
      The Unreal Engine is a complex beast with anything but few layers. Yes the games are just packages, but the engine itself is an multiplatform engineering feat.
  • ardit33 7y ago
    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), to deal with the lower level details and help abstracting out the differences of the platforms. Dropbox is the end product. So, to make the code shareable, they have to build something like the equivalent of a game engine.... which is not a simple task.... I have worked at Spotify, and we had a lower level library to help (built in C++) to help out with some of the common features across platforms. It was ported from the desktop app, to iOS and Android, and it was a separate project. Over time, as features kept piling in, it turned into a giant un-manageable mess. It got so bad at some point, that we had to skip a couple of scheduled releases to clean up/fix some of its issues. The problem became even worse when Spotify tried to build a unified UI on top of it (HTML 5 based), with a bridge layer to the C++. The idea was to write once, and (haha) run it everywhere. It failed, for the reasons many of them failed in other companies as well (facebook was doing HTML5 at the time as well). That got removed, but the problem still remains that "Core" got overly complex as many platforms had their own features, which often were "one off", A/B testing, to see if it works or not. And separate teams (iOS, Android, and Desktop) had their own schedule on this. (It makes perfectly sense to A/B test one feature in Android, and another one in iOS, to see if people even like that feature before making is x-ross platform. Common platform code, massively slowed down A/B testing of new experimental features, and thus it was a huge cost to the company. The only solution to this was to keep the common "Core" (as it was called), to the most minimal features needed, and mostly related to playback (ie. song retrieval, caching, retrieval, decryption, playback, and some account features). Do, the A/B testing on the platform level (iOS, or Android), of it was successful then roll what made sense to the rest (but still trying to keep core as lean as possible). But since I left few years ago, things might have changed again....
• pjmlp 7y ago
  Having done this quite a few times, it looks more like they are having issues to retain C++ developers, are too picky on their hiring process and the original devs have left, than anything else. And given some of the macOS client practices, the engineering quality is also to wonder. For me, C++ with native views, or Xamarin, will keep on being the way to do mobile apps that can't be done as PWAs.
• auggierose 7y ago
  Just look at the code needed to support the file system on iOS 13 to write a file provider. It changed a lot, and non-native code to adopt to that would be a nightmare I imagine.
• PunksATawnyFill 7y ago
  OK, but they didn't attempt to use Qt. I'm currently working on a project where we have indeed decided we needed to go Swift/Kotlin native on each platform, but with the long-term goal of building a cross-platform app with Qt. Qt certainly has its issues, but I respect what its developers have accomplished. And it appears to offer adequate ways to do common things like parse JSON, and it abstracts things like Bluetooth usage and file storage in the apps' sandboxes; so I don't see some of the hurdles cited in this article.
• petters 7y ago
  Hasn't Microsoft successfully written their mobile Office apps in C++ in a single codebase?
  • therockhead 7y ago
    Indeed they have. What’s missing in some of the discussion here is the size of the application. For large applications like Office, a shared code base is often the correct strategy.
    • NickGerleman 7y ago
      I work on Office and am glad someone brought up this point. Writing a C++ business logic layer is probably too much for a simple CRUD style app, but the equation changes once the view/platform layers are a tiny minority of the logic in your app.
  • yannikyeo 7y ago
    Anyone knows how Adobe create their cross platform apps?
• nbevans 7y ago
  When you're at Dropbox's scale it's easy to just hire a load of iOS and Android devs, and some product managers to keep them all in sync. But when you're not at that scale - you can't afford to build the same app twice - you are often left with a choice of either Xamarin or React Native. Both of these are perfectly good frameworks on which to build software; don't let the FUD win.
• taurath 7y ago
  Over time as well, you cannot keep up with features. You will always be lowest common denominator, because if a system handles 6 platforms, and you want the feature of 1 platform on that platform, it will triple or more your amount of effort to implement it.
• aedron 7y ago
  Does anyone have experience trying to do this kind of thing with LibGDX? LibGDX is a layer on top of OpenGL (lwjgl actually), and used a lot for game development. It is based on Java, and is able to package the application for Android, iOS, Windows, Linux, Mac, and even web (targeting WebGL). For iOS it uses RoboVM, and for the web export it uses GWT to compile to JavaScript. Obviously this is best suited for custom UIs (like games), but with some frameworks on top it seems it would be possible to build a decent interface. The framework already has support for most platform specific functionality (like text input). Performance should be great because it runs close to the metal, so to speak. Just curious if anyone has tried this, as I am considering the approach.
  • la_fayette 7y ago
    Actually flutter is based on this approach. The native widgets are completely recreated with this dart based runtime. Performance is indeed great, however it seems like a hell lot of work to create all these widgets...
• shultays 7y ago
  I worked in a company that makes games for both ios and android and it shares majority of the code in between. It was using libgdx which uses Java & opengl and it was working very well for us. I would say things are not so bad when you pick your tools right.
  • manmal 7y ago
    I think the use case Dropbox has is quite different, because they have a lot of native code surface, needing lots of interactions with the shared code base. A game can get by with only a few lines of native code, AFAIK.
• iainmerrick 7y ago
  I think in the specific case of C++, this is mostly an Android problem, not a general cross-platform problem. C++ works just fine on iOS, and interoperates very well with Obj-C (not sure about Swift, though). C++ is a mess on Android. It can certainly be made to work, but the tooling and library support is minimal.
• stephc_int13 7y ago
  This comment will probably be viewed as preposterous or based on ignorance. But from my perspective, you're probably doing it wrong. And based on my experiences with different dropbox clients, I'm not too surprised, those apps all seem to be very badly built. Switching language or framework won't help that much, I'm afraid.
• olalonde 7y ago
  As usual, what is true for a 1000+ people org might not be true for your bootstrapped startup.
• jkereako 7y ago
  This article hits close to home. I've been working with Xamarin for almost two years now. It has done its job and provided a quick avenue to prototype a concept and deliver a product. However, as the article mentions, the maintenance is a bear. Here are some of the issues I face: - The developer experience is awful. Visual Studio for Mac causes so many issues (crashes, mangled project files) it hinders productivity. About once every two weeks I spend half a day wrestling with a VS issue. - As AirBnB's article mentioned, to be effective in cross-platform development, you need to know three platforms well which is a difficult task. - Xamarin's performance on Android has notoriously been poor and only has marginally improved. Try using a Xamarin app on a cheaper Android device or an older version of Android. - No mobile engineers want to work on Xamarin. That said, the good news about working with Xamarin is that it exposed me to C# and the .NET ecosystem. I'm truly impressed with these technologies. EDIT I forgot to mention that I think the complexity of an app ought to determine whether a cross-platform technology is a good idea. Xamarin is a great solution for prototypes and simple apps.
  • king_magic 7y ago
    I’ve come to almost exactly the same conclusions. And it really is sad: Xamarin developer tools used to be decent, almost even good. Today? I’d rather try to build mobile apps in COBOL than Xamarin. The developer tools are so broken, so buggy, and so poorly documented that it’s just not worth it. I thought Microsoft purchasing Xamarin would have made things better at the lowest level of the dev tools stack - hey, finally some investment will go toward shoring up the dev stack! Nope, apparently not. Years later, trying to connect VS for Windows to a Mac build server is still astoundingly, soul-crushingly broken. No way to get support. No straightforward way to file bugs. Just a truly awful developer experience.
• jamil7 7y ago
  The cross platform landscape is pretty daunting for a solo dev. I ended up just writing my app natively, time will tell if that was the right decision or not. Most of my business logic is handled by my backend. I like the performance and being able to implement platform specific features as soon as they're released. I might look into doing some codesharing in Rust if it becomes more straightforward. Sometimes it's OK to write things twice.
• commanderjroc 7y ago
  I 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 C# were our driving factors. It was a trade off most definitely but it was a pragmatic choice as well. If you are capable of hiring more developers who know Java or Obj-C and can allow them to do only mobile development then its worth it to go native. But, if you are a small company and know that Java,C# and Obj-C, C# developers are a little bit hard to find (depending on your developer market) then its probably more cost effective to go Xamarin or any other cross-platform code sharing model. In the end its all about pragmatism.
  • bena 7y ago
    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.
    • commanderjroc 7y ago
      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.
    • amaccuish 7y ago
      iOS requires AOT compilation as interpreted/bytecode languages AFAIK are restricted to the Nitro JS engine. With Android it compiles with a .NET runtime included IIRC.
      • commanderjroc 7y ago
        Yes, it uses Mono under the hood as the .NET runtime.
• eejjjj82 7y ago
  The best way I've seen this work (inside Google Apps) is to write shared business-logic in a common layer (here it (often) gets written in Java, then transpiled to Obj->C and Javascript, other teams go from C++ -> Java & JS, and other other teams embed JS inside of everything.. and other other other teams write everything in a native language (there is no one single way at Google)) then use a data-definition-language (like protobuffers) to define a bridge from inside of transpiled code land to your native layer, and compile native language bindings for your UI to read & write data models. then stack a mechanism like GRPC which takes the DDL to the next level and makes services a declarative, language agnostic definition... and compile your service stubs for each platform. ...then write the UI in a native layer for each platform, using the native service stubs and data models compiled from your DDL. Once you start trying to abstract the UI models between iOS, Android, and web you are stuck with a shitty status quo solution that leads to terrible hacks or boring concessions that ignore platform differences. However abstracting the common (non-ui) mechanisms like asynchronous data structures, sockets, and storage is a relatively solved problem.
  • whalabi 7y ago
    Well that sounds.. intricate. Wouldn't it be dramatically simpler to just build the app twice?
  • leadingthenet 7y ago
    Oooor, you could just use Kotlin and Swift and be done with it.
• Shorel 7y ago
  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.
• lenkite 7y ago
  Using 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++.
• HN-VIC 7y ago
  Web, IOS and Android should be the same code base.
• kdaker 7y ago
  As someone who has built a C++ library to share across iOS and Android I completely agree. The biggest issue for us was finding developers willing to learn and adopt C++. For our use case we weren’t writing UI or user flow logic, it was an ‘engine’ that handled complex business logic. It used JSON as input and output. If I were to do that same project again I would use mostly native code and write our engine in Javascript.