4 ms·

And we're doing the separate platform teams thing, and have to find, train, pay twice the number of developers that would be needed for a cross-platform solutio

by blub 11y ago

And we're doing the separate platform teams thing, and have to find, train, pay twice the number of developers that would be needed for a cross-platform solution. There is by no means a clear answer on which way is better... We looked at doing cross-platform, but we would have to retrain a lot of iOS-only or Java-only developers so no luck.

Cthulhu_ 11y ago
"Twice" seems exaggerated; cross-platform applications come with their own set of challenges (often about device-specific issues), and you'll still need expertise on all your supported platforms. Saying developing for X native platforms is X times as hard/expensive is naive.
- blub 11y ago
  What's the point of your post? OP provided an anecdote, I provided another. You're criticizing something that was never said.
pjmlp 11y ago
I play with Android and Windows Phone in my free time, but I also have experience with cross platform development. One additional issue is that an abstraction layer also adds up in development time. Someone needs to write the platform specific glue, create abstractions that work across all platforms lifecycles, debug if errors happen in the middleware or device firmware... So it is not always a clear win to not have focused device teams. Each OS is very complex and no developer can know all of it.
mahyarm 11y ago
I wouldn't say 'double' the engineers. In my last company's case, you still need to write the iOS and Android "UI" part, and waiting for the C++ engineers to finally make this relatively simple thing could take longer than it should. Sometimes it was just faster for the two UI engineers to implement it in the UI than it was for the two C++ engineers to make it themselves. Then the UI engineers often had to create wrappers for the C++ objects (in the iOS Objective-C++ case at least), because ObjC objects only take NSString, while the C++ types only give C++ strings and other such glue things. Then lazy engineers / deadlines would move business logic into the UI layer wrappers, because development speed wise it was much easier to work with there than to put inside the C++ layer. Cross platform makes it's own work. But this was with a 'homegrown' C++ solution, so maybe something made by a third party like xamarin might be a very different experience.

by blub 11y ago

Cthulhu_ 11y ago

"Twice" seems exaggerated; cross-platform applications come with their own set of challenges (often about device-specific issues), and you'll still need expertise on all your supported platforms. Saying developing for X native platforms is X times as hard/expensive is naive.

blub 11y ago
What's the point of your post? OP provided an anecdote, I provided another. You're criticizing something that was never said.

pjmlp 11y ago

I play with Android and Windows Phone in my free time, but I also have experience with cross platform development. One additional issue is that an abstraction layer also adds up in development time. Someone needs to write the platform specific glue, create abstractions that work across all platforms lifecycles, debug if errors happen in the middleware or device firmware... So it is not always a clear win to not have focused device teams. Each OS is very complex and no developer can know all of it.

mahyarm 11y ago

I wouldn't say 'double' the engineers. In my last company's case, you still need to write the iOS and Android "UI" part, and waiting for the C++ engineers to finally make this relatively simple thing could take longer than it should. Sometimes it was just faster for the two UI engineers to implement it in the UI than it was for the two C++ engineers to make it themselves. Then the UI engineers often had to create wrappers for the C++ objects (in the iOS Objective-C++ case at least), because ObjC objects only take NSString, while the C++ types only give C++ strings and other such glue things. Then lazy engineers / deadlines would move business logic into the UI layer wrappers, because development speed wise it was much easier to work with there than to put inside the C++ layer. Cross platform makes it's own work. But this was with a 'homegrown' C++ solution, so maybe something made by a third party like xamarin might be a very different experience.