Dropbox, iOS and Android Code Costs

IceDigger

Quasi-regular
Joined
May 11, 2019
Messages
284
Points
43
Who’s a lazy coder? Pretty much everybody…

An interesting read on Dropbox’s coding thoughts for both iOS and Android. Why they do what they do to save time/money. Why writing the code twice is the best way for them.

“By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults. This overhead ended up being more expensive than just writing the code twice.”
“Last, but definitely not least, is the cost of training and/or hiring developers to work on our very custom stack. When Dropbox started with this mobile strategy, we had a core group of experienced C++ developers. This group started the C++ project and trained other mobile developers at Dropbox on how to contribute to the codebase.”
Dropbox Team

Full Story
 
Last edited:
It's amazing, it's like using default compilers with default API's is less secure then writing code specifically designed for the target platform.

If you are surprised by this, I would like to discuss a very lucrative land deal. I've managed to come into possession of some ocean side property in North Dakota. I can get you in on a real sweetheart of a deal. Please reply to this message with your serious interest only. I don't have time for people looking to just play at buying some valuable land in limited quantities.
 
I wonder if this holds true for the games industry as well.

Would it be cheaper to write a game twice (obviously reusing the same artistic models, textures, audio files, etc) than it is to follow the current model of codevelopment and/or ports.
 
I wonder if this holds true for the games industry as well.

Would it be cheaper to write a game twice (obviously reusing the same artistic models, textures, audio files, etc) than it is to follow the current model of codevelopment and/or ports.

A lot of the new games are HUGE file size nowadays. Its kinda sad. No more optimizations. Just get it out quickly then make the next one.
 
A lot of the new games are HUGE file size nowadays. Its kinda sad. No more optimizations. Just get it out quickly then make the next one.
I tend to agree. I have no idea what happened to efficient coders any more. Now it's efficient compilers that are not.
 
Well, for games at least, the majority of the file size are assets - FMV, audio, and art: textures, meshes, etc. That stuff isn't going to change no matter what platform your on.

There will be a decent amount of linked libraries (DLLs, etc). Those are per-platform, but usually come pre-compiled for you, you just reference them and hook in.

The actual "code" code itself isn't nearly as big as the total install size lets on. The game code itself, at a high level, isn't going to change much - you will have different libraries and OS APIs to deal with (DX vs OGL, for example), but the basic corewill remain the same. The devil in gaming is in optimization... very much so optimization. Robust gaming engines will help considerably with this, but aren't entire replacements for it.

A program like Dropbox, which has some fairly deep hooks into the OS, needs to be platform dependant. I don't know why they were trying to use the "One Ring to Rule them All" method when every platform is going to have a different API for file storage, for integrating with the UI, for file patching, background program access, permissions, etc... Dropbox doesn't have a huge optimization problem, but it does have a big "native" problem; in that it needs to integrate in such a way as to feel native on each platform.

Could it be done in a "One Ring to Rule them All" method? Sure. But not well. You will run into copyright issues. You will be forced to recreate wheels left and right. I'm not surprised at the outcome of the Dropbox story in the least, other than the fact that they tried it in the first place.
 
Become a Patron!
Back
Top