Live data from Hacker News

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

blogs.dropbox.com

171–180 of 335 posts

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

#171
post #88

Earlier quoted context omitted.

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…

Xamarin on paper seems like the holy Grail, but the fact that Microsoft itself chose to use react native instead of its own solution for Skype made it seem like I should not expect long term commitment to xamarin from MS.

I would be careful to attribute framework decision making to careful thought. This is more the regular organizational dysfunctionality. Either:

- The entire organization uses a single framework (and improves on it), which will lead to a bunch of teams grumbling that "We are only using X because of organizational pressure, while Y is much better"

- You leave freedom to the org to pick their technology, and hope/steer people towards certain parts. But you will have to accept some divergence from the norm

I prefer the second org, and luckily I am in such a place where we can use Go while the team next to us is on Scala, and we weigh in-house developed technology against publicly available technology on ROI.

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

#172
post #153

Earlier quoted context omitted.

I'm using Flutter successfully. It has the potential to become a really great platform. Java is a good language, as long as you rarely use implementation inheritance. I would not recommend using React Native or C++ for any project.

Could you tell why you would not recommend react native?

Pretty certain it's the unstability.

In my experience, while Flutter may not be elegant because of Dart, it more or less just works.

Developing in React Native is mostly just debugging the framework itself and browsing through React Native Github issues.

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

#173

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 comme…

Funny, I applied, 20+ years experience in C++, on mobile too, writing a competing product.. odd never got a call back ;p

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

#174
post #88
post #15

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…

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:

- UPS - 1/4 stars - All views of the app are awkward embedded web views. Every page has a full screen modal spinner.

- Outback Steakhouse - 1/4 stars - Not updated for modern iPhones, so the whole app is letterboxed. UI is completely custom, so didn't attempt to feel native. Crashed as soon as it tried to get my location.

- Alaska Airlines - 3/4 stars - Feels native-ish, nice "vanilla" design. Mix of native forms and web views. All UI related to searching flights & buying tickets is a web view. Every tap on the tab bar causes a full screen modal spinner.

- FOX Sports - 4/4 stars - Wow, impressive. Lots of native-feeling views with their own branded styling. The custom widgets feel native.

It was great to find one "hero" app for Xamarin (FOX Sports), but the fact that it's an outlier is a little concerning.

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

#176
post #15

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…

Years ago I wrote a programming language a bit like Haxe, except that it let you 'inject' snippets of your target language wherever you wanted. So you could keep your major architecture in one common language and still implement specific cases on the spot (ie you don't have to go to other files, and the various implementations for different target languages were right next to each other, making it easier to keep them in sync).

I implemented targets for JS, php and C++. It worked okayish but in the end it was more work to maintain the separate language than just write everything 3 times with some help of a simple macro/template language. I still sometimes wonder if the concept would be developed further, with a proper team and good tooling etc, if it would be a practical way of doing large scale cross platform software development.

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

#177
post #144

Earlier quoted context omitted.

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.

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.

Apple ships a C++ compiler but you can't use C++ with Apple's platform SDKs. IF you want to use C++ you need to write Obj-C++ glue code to access most of the system frameworks, including UI code.

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

#178
post #15

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…

> a good requirements spec I think that kills a lot of interesting projects right there. If I could write a solid spec, that would mean I believe I wouldn't learn much from shipping the product. And also that my competitors aren't learning or advancing.

Nobody says you have to write the spec beforehand.

As long as you don’t blurt a lazy “use the source Luke” and take the effort to document and edit the spec during or right after implementing something, it’s ok.

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

#179

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 alter…

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

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

#180

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?

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.

Post reply on HN