Notice how everything he writes about mobile development is wrong?
>First of all, you have to do your mobile development twice
Nope, there are plenty of frameworks with large user bases, both OSS and with corporate backend to do it once. From Xamarin to PhoneGap. Especially 2D game developers are spoiled for choice.
>The devices are memory-starved, CPU-starved, and battery-starved.
The devices have never been better (obviously), and currently pack a 2005 era laptop power in the size of pack of cards and 1GB or more of memory. And the battery lasts the whole day, at least with the devices I'm familiar with.
>You don’t get a choice of languages; if you hate both Java and ObjC, get another job.
Really? Because there are iOS bindings for all popular languages (and I've used several) and I'd guess there are Android bindings too. Now, one can say that to be a great developer you also have to know Obj-C (which I'm familiar with), but that's in no way a prerequisite, just a nice-to-have. Plenty of people have built amazing things without learning Obj-C.
>Unit testing is a bitch.
Haven't found it such. Except if he means with all the Android flavors? That's orthogonal and inherent to mobile.
>Fortunately for your users but unfortunately for you, the UX-quality bar on mobile is high and there is no fast or cheap way through; it requires inspiration and iteration.
And that belongs in a list of reasons "mobile suchs" (sic), why?
>You can’t make money. Seriously, Apple is always talking about the billions and billions they pay out of the app store, so why is it that I don’t know anyone who’s making serious money on mobile apps?
Perhaps you don't have a lot of friends? Or friends in the right circles? Because for a market that "can't make money", they just paid $10 billion to developers.
I want to see some good Xamarin & PhoneGap apps, honestly the ones I've seen don't come close to natively built ones. Also if you are developing a game, you'd better stay far away from UIKit and do everything in OpenGL if you hope to get the same type of performance on Android using a translation tool.
The article is pretty much spot on. For most people who want to write great software, the client side is currently a mess.
Xamarin and Phonegap are completely different beasts. You are thinking about Phonegap now. Xamarin ones are natively built ones; you use Apple classes to build everything but just in C# instead of Objective-C. So you have to rebuild the frontend twice indeed for Android and iOS but it does look and function 'native' as if you did it with Xcode.
Phonegap => not so much; most just works like shit, but you only have to build once for a lot of platforms. It's a big reason for the proliferation of extremely bad apps in the Play store though; just wrapping of a website or form and putting it in as app.
Sorry, I got Xamarin confused with Titanium, which was a pretty bad experience for me for the week that I tried it. If I tried to do anything fancy, it was completely useless.
Also any time you are using 3rd party tools like Titanium / Xamarin to develop these apps it comes with gotchas / limitations that may not even be worth it in the end (it seems like Xamarin has less gotchas). The main issue is that you still have to do UI twice in the end (iOS & Android), and one more time for web.
Sure, but there aren't really any alternatives. When you build advanced apps HTML5 is depressing for apps at the moment. It will happen, but not this year.
>I want to see some good Xamarin & PhoneGap apps, honestly the ones I've seen don't come close to natively built ones.
I don't know, what's bad about these http://xamarin.com/apps , e.g. Rdio which I've used and is fine?
Xamarin is a binding to Cocoa and other libs, it doesn't recreate any UI itself. So the "don't come close to natively built ones" doesn't even make sense from a technical standpoint. Not to mention that C# is compiled AOT.
>The article is pretty much spot on. For most people who want to write great software, the client side is currently a mess.
The article isn't even about those people in the first place. He even laments that "UX-quality bar on mobile is high" as a reason why mobile sucks.
Which Xamarin apps that you've seen don't look native?
As others have pointed out, Xamarin provides C# bindings for the native APIs. It is fundamentally different to Phonegap, which takes a lowest-common-denominator Java/Swing approach.
> Nope, there are plenty of frameworks with large user bases, both OSS and with corporate backend to do it once. From Xamarin to PhoneGap. Especially 2D game developers are spoiled for choice.
With Xamarin you need to build the GUI twice as you are using the native classes per platform to build them, hence the excellent results.
2D games is a whole different ballgame; there are indeed 100s of platforms for devving 2d games on anything. But I think we are talking about apps; games is a solved problem already with Unity2D/3D, Corona, Haxe and many others.
The best phone I ever owned was a Nokia 6310i, and I had to charge it only once, occasionally twice a week. Now with all the advances in battery technology, phones barely last a day and there's a thriving market in external batteries and portable chargers. If I am not using any of the "smart" features on my smartphone, just calls and texts, I would expect it to last longer than that old Nokia, but I might get at best 2 days. Modern phone designs are horribly inefficient, and the consumer has just been forced to get used to it.
the consumer has just been forced to get used to it.
Have they? Why? Nokia still sells feature phones with good battery life. Hell, the new 105 lasts a month(!) on a single charge and you can get it on ebay for $30+shipping.
Nobody is forcing anything, people just like smartphones.
Which is nice and everything, but for me nowadays the phone part of a mobile device tends to be among the least used of its core features. For every call I make, I'm probably sending dozens of long text messages, taking dozens of high resolution photographs, reading dozens of web pages, listening to dozens of songs, investigating maps, writing notes and playing games.
We're no longer even talking about the same product segment. A modern smartphone is more of an iPod than a phone. More of a Palm Pilot than a phone. More of a GameBoy than a phone. More of a handheld GPS than a phone. More of a laptop than a phone. More of a camera than a phone.
These aren't inefficient phones, they're not phones.
When I turn off data on my Android phone to use it as a backup phone with my home SIM in, it does indeed last for weeks. Modern phone designs are a marvel of efficiency for what they're expected to do.
>The update cycles are slow. Days in the case of iOS ...
Last time I tried it was hours, although not instant as you might hope.
>What’s worse is that you can’t even count on people accepting the mobile-app updates you send them.
IOS7 tries to help this with automatic updating. Users still have the choice of updating but if you state in the release notes that it's a fix for "data-losing account-compromising privacy-infringing bug" they just might update.
Haven't found it such. Except if he means with all the Android flavors? That's orthogonal and inherent to mobile.
I assume he means that the tooling isn't as mature as that available for non-mobile, which I think is a fair comment. Running tests in the device or emulator is more involved, as is mocking apis for things like geolocation or the camera.
First of all, you have to do your mobile development twice
This is not wrong, in fact with Windows Phone and Firefox OS it'll soon become 3 x or 4 x, and more importantly compared to the web you have to make that choice of which to target, test and support - with web software it doesn't come up. The landscape for x-platform software is pretty limited, and having to use a framework like phonegap is far from ideal and leaves you beholden to that framework author for updates, performance, updating for new UIs like iOS 7, fixing bugs etc. That's not an enviable situation to be in and you shouldn't just dismiss it with a wave of the hand. Consumers are often hostile to apps made with html frameworks across platforms as well, because the performance isn't always good, and the platform makers are hostile to them because they break their ecosystem monopoly.
You don’t get a choice of languages; if you hate both Java and ObjC, get another job.
I do think it's a shame that the providers of these platforms lock them down to APIs in their chosen languages/frameworks - Apple have been getting better on this, but really there is no good reason to ban alternative browsing engines, and on all these platforms the platform vendors' aim is to lock you into their development tools, process and API, ideally to the exclusion of all others. Apple could have given webkit/x-platform development equal footing with native, but instead they have hindered it with substandard performance compared to the built-in browser.
Because for a market that "can't make money", they just paid $10 billion to developers.
I'd be very interested to see the breakdown on which developers have made all that money; I suspect it would be heavily skewed towards shady purveyors of skinner-box games like Zynga and big name game studios with lots of marketing behind them. It is possible for an indy to make money, but it's far harder than you might think depending on the segment you're in. I agree 'You can't make money' is patently false though, you can make money on mobile apps. In my experience though there's far more certain money in making them than in selling them.
My biggest complaints about mobile development are the capricious and arbitrary rules and judgements on whether apps get onto the device or not. That serves no-one but Apple/Google, and in the long term I suspect will doom their platform compared to more open alternatives like the web. Apple and Google want to control their consumers absolutely and take a cut on transactions, and use their tight grip on the app stores to make this a reality.
I don't see mobile overtaking the web though, quite the reverse in the long term. Coming from server-side development mobile app development can be frustrating because of the power the platform vendors exert over every stage of the process. That's not something to celebrate or paper over, it's a serious problem.
Just to take one example - Apple has banned developers from exploring any other payment system than their own for selling digital goods. That's a serious crimp on innovation, costs the customers and developers, and guarantees that Apple has a stranglehold on a huge emerging market and collects a vig on every transaction, to the detriment of competitors of theirs like Amazon and customers who just want to buy a book in their kindle app. Why should a single corporation control which books I read just because of the device I bought?
At least he points out that the situation on the browser side technically is equally broken and in need of improvement, with only one language available for client-side development.
> I do think it's a shame that the providers of these platforms lock them down to APIs in their chosen languages/frameworks
I never understand this point. All APIs are exposed via some protocol. Whether it's javascript, C, Objective-C or HTTP.
High-level APIs like HTML5 or Cocoa need to be exposed in a high-level language. The restrictions imposed by js or obj-c are an inescapable part of what make these environments better than what we used before.
Does anyone really want to go back to using thin wrappers around C APIs?
It's an interesting debate, and in particular UI bindings often need higher level access. I'm not convinced that the trade off of being locked into whatever Apple decides is the one true language and API is worth the gains though.
I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser. That has been a limiting, but at the same time truly revolutionary, feature of web software which freed it from domination by large software vendors and restrictive practices like those we've seen on iOS or (to a lesser extent) Android.
If all the platform vendors had standardised on an API in say c as web browsers or unix have, we'd have a much more convincing case for mobile taking over the world and competing with the web - given the current situation of competing ecosystems with draconian restrictions I suspect they will all be subsumed by the web at some point.
> I'd be much happier with mobile dev if the situation was more like that of developing for the web - use any language you want as long as it can output HTML to be presented in the browser
On the server, that's definitely true. On the client, it's basically the same situation w/r/t languages. But this is a client/server distinction, not a native/web distinction.
Clients are just inherently coupled to the APIs that they use. Servers aren't so much. The coupling in languages reflects this.
> If all the platform vendors had standardised on an API in say c as web browsers or unix have, we'd have a much more convincing case for mobile taking over the world and competing with the web
That's an interesting point (although we'll then be totally locked to a particular platform/language on the client) and I think the web will eventually win. But not for a while.
At some point, the rate of progress on native will decrease and the advantages of standardization (cost, mostly) will overcome the disadvantages (lack of progress). It'll be interesting to see how the manafacturers adapt to that. I suspect that Google will do better than Apple.
They are indeed for desktop. As Objective-C becomes better (and it does it pretty fast, it has covered two decades of language development from 1970s to 1990s in just 7 years), most of the amateur iOS languages bindings become stale.
There are currently no high-quality, production-ready, native 3rd party language bindings for iOS that I know of, except for Xamarin mentioned above and Unity family.
In iOS 7 though, there's some activity in JavaScriptCore.framework on providing seamless integration between JavaScript and Objective-C.
Delphi lets you do single codebase iOS, android, windows and mac native apps that render their ui to opengl and are therefore really fast.
Ofcourse, you have to write objectpascal, which is not a popular language, but once you get over the weirdness it is more productive than C++ while still giving you pure native software. It even has closures these days :)
I second that request. Could you please include the links to mature production-ready bindings for some of the top programming languages from the TIOBE index?
In my pocket, maybe. I get to practically watch my battery indicator drain before my eyes trying to do any sort intensive activity, or (god forbid) watch video.
>First of all, you have to do your mobile development twice
Nope, there are plenty of frameworks with large user bases, both OSS and with corporate backend to do it once. From Xamarin to PhoneGap. Especially 2D game developers are spoiled for choice.
>The devices are memory-starved, CPU-starved, and battery-starved.
The devices have never been better (obviously), and currently pack a 2005 era laptop power in the size of pack of cards and 1GB or more of memory. And the battery lasts the whole day, at least with the devices I'm familiar with.
>You don’t get a choice of languages; if you hate both Java and ObjC, get another job.
Really? Because there are iOS bindings for all popular languages (and I've used several) and I'd guess there are Android bindings too. Now, one can say that to be a great developer you also have to know Obj-C (which I'm familiar with), but that's in no way a prerequisite, just a nice-to-have. Plenty of people have built amazing things without learning Obj-C.
>Unit testing is a bitch.
Haven't found it such. Except if he means with all the Android flavors? That's orthogonal and inherent to mobile.
>Fortunately for your users but unfortunately for you, the UX-quality bar on mobile is high and there is no fast or cheap way through; it requires inspiration and iteration.
And that belongs in a list of reasons "mobile suchs" (sic), why?
>You can’t make money. Seriously, Apple is always talking about the billions and billions they pay out of the app store, so why is it that I don’t know anyone who’s making serious money on mobile apps?
Perhaps you don't have a lot of friends? Or friends in the right circles? Because for a market that "can't make money", they just paid $10 billion to developers.