Hasn't Microsoft successfully written their mobile Office apps in C++ in a single codebase?
Anyone knows how Adobe create their cross platform apps?
The not so hidden cost of sharing code between iOS and Android
261–270 of 335 posts
Re: The not so hidden cost of sharing code between iOS and Android
#262Earlier quoted context omitted.
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.
Metal and driver SDKs require C++.
Re: The not so hidden cost of sharing code between iOS and Android
#263Earlier 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…
Many businesses go with Xamarin because some guy in a management mandates it because he feels it will be a silver bullet that will let them get around having to hire skilled native mobile developers.
The reality is that to do Xamarin well you’ll have to wander outside out Xamarin Forms, and to do that well not only do you need native mobile developers but you need far higher caliber native mobile devs who are able to mentally translate swift/objc and android calls into their C# equivalent, and who have an idea of what’s going on the os when there’s a crash at a level lower than the .NET runtime caused by a native part that’s not apparent in the crappy Xamarin stack trace.
Xamarin really only makes sense if your company has a mountain of existing complicated .NET code with priceless business logic that you absolutely have to reuse.
Re: The not so hidden cost of sharing code between iOS and Android
#264This 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 was on that core team and that's not quite what I recall regarding the core library.
We had some hard requirements on that library because of protocols used by the backend and other reasons. And when you mention features "mostly related to playback", well, it was 95% of the library from its conception (the rest being login and communication with backend). Most of it is quite complex code and not anything you want to rewrite for each platform (mainly offline storage, remote control, playback).
The issues we had were caused by growing pain from having the library initially mixed in the desktop code (back when mobile wasn't a thing). It needed to be extracted, productified and a whole lot of tooling and testing written for it. Once we got there, the quality of the code was much nicer and the integration in the various clients easy and automated (which it couldn't be at first). It certainly took sometime, but it wasn't a problem caused by it being cross platform, only that we needed a better infra. We were there when I left the company about the same time as you for quite a while already.
The integration with various clients got later easier once we removed the need to reach into that library for just fetching simple server side data. But that wasn't a cross-platform library issue, it was mainly a backend issue.
Re: The not so hidden cost of sharing code between iOS and Android
#265Earlier quoted context omitted.
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 o…
I wonder how well Xamarin will work with Swift-only frameworks, like the upcoming SwiftUI and Combine frameworks. They make heavy use of Swift generics. It’s been a long time since I’ve touched Xamarin so it’s a genuine curiosity.
I've used Sharpie Bind with a private (internal use) Swift Framework and it worked fine for me. But the Swift stuff is currently not officially supported. I've used these instructions: https://medium.com/@Flash3001/binding-swift-libraries-xamari...
I did have to make some adjustments to the library, so I guess it could be tricky to use Sharpie Bind with Swift frameworks, if you're not in control of the Framework yourself.
Re: The not so hidden cost of sharing code between iOS and Android
#266Earlier quoted context omitted.
> 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.
Whatever you first create has some kind of vision behind it. Even if that vision is a rough spec, it might be precisely the little bit of spec that’s necessary to get things started. A good requirements spec doesn’t mean it has to be heavyweight with all the corners and edges figured out. Instead, it can be just lightweight enough to get things moving in the proper direction... but some little direction is certainly…
No, I've built entire products without a spec: http://williampietri.com/writing/2015/the-big-board/
It's fine.
Re: The not so hidden cost of sharing code between iOS and Android
#267Earlier quoted context omitted.
> 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.
Well, I think the comment I'm responding to expects the spec first. And almost anything that encourages writing a spec says to do it first.
What's the point of writing the spec after? At best, it's duplicative. At worst, it diverges, making it incorrect.
Re: The not so hidden cost of sharing code between iOS and Android
#268Earlier quoted context omitted.
How does that work out when things change over time: requirements and the platforms themselves?
Basically the same process as when you first started. Implement the changes on Platform A, get it stable, port it over to Platform B, get it stable, port back any refinements to platform A. Platform changes themselves should ideally be quarantined behind said abstractions/injections, so your actual ported code is very simple and "timeless": no fancy language features, no preprocessor magic, no annotations, no excessi…
Approaches like this could increase the second-class-platform effect. Where, for example, Android gets updates long after IOS. (Unless both releases are synchronized.)
In theory the shared code approach means platforms could be tested in parallel.
Re: The not so hidden cost of sharing code between iOS and Android
#269Earlier quoted context omitted.
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.
The nice thing about React Native compared to Flutter is that RN uses native UI widgets whereas Flutter implements its own rendering system. Flutter engineers basically reinvent a large portion of the work already done by Apple and Google in their UI kits and ultimately you have to rely on them to keep doing that work whenever changes are introduced to iOS and Android UI kits. Since RN uses native widgets they get those updates "for free". There is also the Flutter "uncanny valley" where very subtle but still perceptible differences between the Flutter engine and the native UI kit cause Flutter apps to sometimes feel slightly off. I have especially noticed this on lower end phones where the FPS in Flutter apps sometimes drops and causes the whole UI to feel sluggish in a way that native UI widgets do not.
Re: The not so hidden cost of sharing code between iOS and Android
#270We'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…
That’s super interesting. I really like Rust, definitely my favourite language recently. I’ve been thinking a lot about the pattern you are using with Rust for the shared layer. Have you got an engineering blog or something with more details?
There is a FullStory engineering blog, but as we've been pretty much heads down for a while on our product we've been unable to write up some of our internal discoveries. I'm hoping that we can open-source some of the mobileRust glue (iOS + Android), and write up what we believe is effective sharing of business logic between platforms.