The Shape of Mobile Development To Come

I disagree with the conclusion, but whole-heartedly agree with this quote:<p><i>I think there's far more low-hanging fruit in making native development easier than in making web/hybrid apps feel "right". I've seen two just good hybrid implementations (Quora and Pocket), and yet I still run into defects using both.</i><p><i>I think the "write-once-run-everywhere" benefit of web views is disingenuous; the phrase should really go "write-once-optimize-everywhere".</i>

The problem with write once run anywhere is that it's not desirable to device manufacturers apart from those on the bottom rungs who don't have a big enough developer community to carry the devices on their own. If MS and Apple threw JVMs onto their devices then we would be 90% of the way there already.<p>If any write-once-run-anywhere solution becomes to popular then the likes of MS or Apple will try their best to kill it. See: Embrace, extend , extinguish by MS on Java and to an extent the web itself and Apple's ban on language runtimes/interpreters on the app store.<p>If every device allows for the same functionality as other devices due to identical software then manufacturers will only be able to compete on price.

<i>Imagine writing code like this and having it build to native apps on both platforms:</i><p>I think Xamarin are going to be a really interesting company to watch for this stuff. Right now they have MonoTouch and MonoDroid as entirely separate products, allowing you to make apps using C#. But you can already reference libraries across both, and just do the UI plumbing separately, and if they're smart they will work very hard on what the author is describing.

I agree with your true write-once-run-everywhere dream, but I disagree with the conclusion that we build an abstraction over existing frameworks. This is essentially what wxWidgets or QT is for desktop.<p>While these things were great, in the end what most of us wanted was actually HTML/CSS/JS and the freedom to create beautiful things that it gives us. I would argue that default looking iOS apps are already stale and we want more control (which CSS is great at giving). I am banking my business on the same thing happening long term in mobile.<p>I agree that webview apps can't compete with native in certain situations, but devices are becoming more powerful every day and web technologies have already proven themselves with a large developer audience.<p>Also, I think there <i>is</i> low-hanging fruit just in the mobile web space: making more websites work well on mobile devices.

Until mobile phones become a lot faster and carry more storage and bandwidth becomes a lot cheaper and more ubiquitous, I believe the most successful approaches simply adapts the underlying framework for use with other languages (and abstraction levels), while simultaneously minimizing the excess baggage/payload required to get a small application up and running. Clojure for Android for instance suffers from this problem (1.7 MB payload), while Scala, Mirah (Ruby-like) and Kawa (Lisp/Scheme) seems to do a decent job on providing thinner wrappers on the host platform. I see the same thing on the web as well, with a multitude of languages targeting javascript as the platform. I did a small writeup on "Android development without Java" on <a href="http://kjeldahl.net/d7/node/32" rel="nofollow">http://kjeldahl.net/d7/node/32</a> if you want more details than I wrote here.

The idea that we'll be able to write apps in an interpereted language is probably a long ways off, but the second idea about more portable object models is spot on.<p>I would argue that such a model would need to include the ability to easily manage per record image assets. (think about how often we have images in a table view cell)<p>To that end, I've created an iOS library to deal with downloading these tables and images in a reasonable way. If you're interested: <a href="https://github.com/Smartovation/STRemoteResources" rel="nofollow">https://github.com/Smartovation/STRemoteResources</a>

The article's mention of beautifully designed mobile apps sparked a few thoughts for me. One property of mobile devices and especially smaller devices like phones is people use them frequently throughout the day in short bursts. Small wait times associated with bouncing, translating animations etc are magnified and the UIs start to feel laggy. Yesterday I purchased my first Android device and the snappy UI has been quite a nice change. This is a relatively low-end Android device. And I've been using an iPhone 4S for the past few months.<p>So I think the design of mobile apps will be simplified going forward. I could see moving towards simpler UIs like Craigslist. This is a major win in a variety of ways: faster UIs implies better user-experience, less computationally intensive UIs implies less drain on limited resources, and simpler UIs implies less design and development time. I love the idea of never stressing out about rounded corners, little shadow and shine marks etc. They're nice to have initially but just get old as one uses the same device/OS/apps for months on end.

QuickDialog (<a href="http://escoz.com/open-source/quickdialog" rel="nofollow">http://escoz.com/open-source/quickdialog</a>).<p>Showing a dialog:<p><pre><code> NSDictionary *dataDict = @{'title':'example', 'other':'other text'}; QRootElement *root = [[QRootElement alloc] initWithJSONFile:@"file" andData:dataDict]; QuickDialogController *myDialogController = [QuickDialogController controllerForRoot:root]; [self presentModalViewController:navigation animated:YES]; </code></pre> example json form definition file to match:<p><pre><code> { "grouped": true, "title": "Example QuickDialog Form", "controllerName": "QuickDialogController", "sections": [ { "elements": [ { "type": "QEntryElement", "title": "Title", "placeholder": "item title", "bind": "textValue:title" }, { "type": "QMultilineElement", "title": "Other info", "bind": "textValue:other" } ] } ] } </code></pre> data from dataDict is merged into the fields defined in the json definition file, using the bindings specified in the 'bind' property.<p>It's really awesome, and makes all kinds of dynamic views possible. I was skeptical at first (as I am about most cocoa libraries) but I'm pretty sold on it since I gave it a fair shot.

I haven't seen any mention of Phone Gap (<a href="http://phonegap.com/" rel="nofollow">http://phonegap.com/</a>) or Titanium (<a href="http://www.appcelerator.com/" rel="nofollow">http://www.appcelerator.com/</a>). Whats the consensus of how close either of these projects get us to a "one code base" solution to multiple platforms?

Liked your idea and will follow your developments on GitHub with an eye towards how you're going to integrate a CoreData client-side library. Besides the front-end issues you highlight, a key challenge will be synchronization: unless you don't plan to allow your users to work offline?<p>I agree with your hope that Rails could somehow be extended to cover this mobile use case, wish I had the chops to create a Devise+MobileAPI generator with a iOS native MongoDB-sychro engine. (Can Rails generators synthesize ObjectiveC source code?)<p>By the way, every time I think about doing something about this I keep an eye on the folks at Parse.com: seems like every week they're solving more and more of the backend part of this problem. And they're working on front-end libraries as well...

He lost me with his "Objective-C ...has evolved over the past two years to become an "easier" language ... "<p>I would argue that it has less to do with the ease of the language and instead the market effects of iOS.

I agree with most of the point, these advance certainly benefits for the product quality. But the conclusion and the hope of "Write once run everywhere" is probably not a good bet.<p>It is not about problem of programming language or tools, but Java already told us the "lowest common denominator" issue you have to face when implementing abstract over different platform. When people working on abstraction, it mean they will spend less time on real devices and fine details, and this is exactly what makes or breaks user experience.

I did some research into the currently-available toolkits that let you write one code base to create mobile apps for iOS, Android, and (maybe) other mobile operating systems. I was astounded by how many options are currently available: more than 50! I made a website to summarize my findings; see <a href="http://www.mobilechameleon.com/" rel="nofollow">http://www.mobilechameleon.com/</a>

The notion that business logic doesn't belong in the client is wrong because you need it when working offline. And sharing UI code is a pipe dream if you want native look and feel. (If you have a custom UI anyway like in a game, it's more feasible.) A more realistic goal is port the business logic, networking code, storage, and so on, and rewrite the UI code for each platform.

The author mentions Quora and Pocket as the only examples of hybrid apps he knows of. What about the LinkedIn app? I always thought that was a good example of a well-done hybrid app.

<a href="http://kivy.org" rel="nofollow">http://kivy.org</a> does Ali of what you talk about using python<p>Edit:fix link

I hope this is titled in reference to the album "the shape of punk to come" :-)

One thing all those "let's build our app on top of 1000 layers so we can use our $favourite language"-people tend to forget is that mobile software runs on mobile devices. Which have one remarkable property: they are energy constrained. So you better write some fast, native code or your users will have trouble keeping their devices alive for one day.