4 ms·
Depends on what kind of mobile apps you are writing. Most of the apps I've worked on written tend to deal with video/ pixel level image conversions. In these ca
by jaegerpicker 14y ago
Depends on what kind of mobile apps you are writing. Most of the apps I've worked on written tend to deal with video/ pixel level image conversions. In these cases it's really common to say convert an rgb pixel array to yuv or simliar and a linq expression on one of those arrays would quite simply kill the app. Which I think is the best counter argument to the op. C# might be fine until you decide to do something beyond the normal performance wise. Then you are back to square one learning the native supported tools, IMO you are much better off learning the native environments from the ground up.
- corresation 14y agoThis is really the crux of it. The counterargument essentially seems to be that such broad abstractions are fine in the small or when you have enough hardware, however that in no way carries over to smartphones where you want to do the most with the least, and even where you have a kick-ass processor and multi-GB RAM, you still want to reserve battery. The primary reason Android seems to need so much more hardware than iOS can be attributed to this. Even when you have powerful hardware, this can kill you in the large (which was the original failure of Windows Vista -- people forget that Microsoft did a complete revert after thousands of man years of work)