43 ms·
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
by grey-area 13y ago
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.
- chrisdevereux 13y ago> 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?
- grey-area 13y agoIt'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.
- chrisdevereux 13y ago> 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.