

The Shape of Mobile Development To Come - 10char
http://clayallsopp.com/posts/the-shape-of-mobile-development-to-come/

======
zachwill
I disagree with the conclusion, but whole-heartedly agree with this quote:

 _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 think the "write-once-run-everywhere" benefit of web views is
disingenuous; the phrase should really go "write-once-optimize-everywhere"._

------
jiggy2011
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.

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.

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.

~~~
stcredzero
_> If MS and Apple threw JVMs onto their devices then we would be 90% of the
way there already._

As a one-time proponent of write-once-run-anywhere solutions, I would have to
say this would probably result in a reduction of UX quality.

~~~
cageface
I think the MonoTouch guys are handling this in the only sensible way. Non-UI
code is shared across platforms but UI code is written per-platform using the
native toolkit. I think this is about as close as you're going to get without
compromising user experience.

~~~
stcredzero
That is indeed the only sensible way.

------
untog
_Imagine writing code like this and having it build to native apps on both
platforms:_

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.

~~~
cageface
I agree. Xamarin is closer than anybody else to a viable cross platform
solution. They're in just the right place now to start eliminating some of the
worst pain points in mobile.

~~~
untog
Appcelerator ought to be as well (with the added bonus of using JS, far better
known than C#), but their platform isn't on the same level. Yet?

~~~
cageface
Haven't tried it myself but the reviews on the web seem to be almost
universally bad whereas most Monotouch users seem to be pretty happy. I think
for larger code bases C# has some important advantages over JS.

~~~
untog
Absolutely. I used Appcelerator a long time ago and it was awful- they've
actually made a ton of progress since then, but they don't make fully native
apps- there's a JS engine in the middle that parses the code. So it's always
going to be a little slower than native- but probably acceptable for a ton of
apps.

------
yesimahuman
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.

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.

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.

Also, I think there _is_ low-hanging fruit just in the mobile web space:
making more websites work well on mobile devices.

------
Kjeldahl
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
<http://kjeldahl.net/d7/node/32> if you want more details than I wrote here.

~~~
cpeterso
Are there any languages that directly target Dalvik/dex without compiling
through Java bytecode?

------
tomwhipple
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.

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)

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:
<https://github.com/Smartovation/STRemoteResources>

------
spaghetti
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.

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.

~~~
weixiyen
I disagree about the prediction for simplified Craigslist-style UIs. I don't
think it will ever happen on Mobile.

Animations play a very important role in communicating to the user how to
interact with the interface. Animations also give the illusion of a responsive
app.

The best apps are likely built by great designers who know how to use
animations effectively to communicate with the user.

Everyone else will simply try to copy the best apps along with their
animations... thus, it's hard to see animations going away any time soon.

On another note, I find it surprising that yours was the only comment even
mentioning design. For me, that was the most important part of the article
with by far the biggest implications.

The author predicts that designers will be able to take on a portion of the
client-side engineering role in the near future. If this happens, it will
completely change how apps are made. It will change the workflow between
designers and engineers.

The traditional model of mocking up a PSD and passing it off to an engineer
will no longer be viable. Designers will just build clients and interact with
APIs. This means that more and more designers will probably have to learn
programming, which is a good thing for the future of mobile apps.

~~~
spaghetti
I think you're right about animation not going away. Especially animations
that help the user understand the app. However I think there's still some
animations and especially some shadow, gradients and other small design
touches that are overkill and can be removed w/o negatively impacting the
user-experience.

------
kennywinker
QuickDialog (<http://escoz.com/open-source/quickdialog>).

Showing a dialog:

    
    
        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];
    

example json form definition file to match:

    
    
        {
            "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" }
                    ]
                }
            ]
        }
    

data from dataDict is merged into the fields defined in the json definition
file, using the bindings specified in the 'bind' property.

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.

~~~
10char
Ha, I actually wrote something really similar (without knowing about QD) for
RubyMotion: <https://github.com/clayallsopp/formotion>

Ruby is better suited to this IMO (no clunky file loading), but I agree they
both prove dynamic native views need more exploration

~~~
kennywinker
That looks remarkably similar. Were you also influenced by MonoTouch.Dialog,
as was QuickDialog's developer?

~~~
10char
Nope, developed it totally independently according to my needs.

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

~~~
cbrauchli
Neither does a very good job if a good UX is a concern. I haven't encountered
any PhoneGap apps that feel native.

------
fieldforceapp
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?

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?)

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...

------
ecspike
He lost me with his "Objective-C ...has evolved over the past two years to
become an "easier" language ... "

I would argue that it has less to do with the ease of the language and instead
the market effects of iOS.

~~~
10char
I think you might've misinterpreted what I meant? I didn't mean to imply
anything about the growth of iOS or that ObjC being just perceived as an
easier language because of the growth. I trying to say that Objective-C was
really criticized for its verbosity and forcing manual memory management, and
Apple has made changes in direct response to those with ARC and more concise
literals, which IMO makes it "easier" (espc. wrt ARC)

~~~
rimantas
Also @property — first you had to declare variables and use @synthesize, then
you could omit the declaration part, and no you can omit the declaration and
@synthesize, @property alone is enough.

------
siuying
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.

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.

------
troymc
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
<http://www.mobilechameleon.com/>

------
skybrian
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.

------
cbrauchli
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.

------
tehansen
<http://kivy.org> does Ali of what you talk about using python

Edit:fix link

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

------
franzus
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.

~~~
rmason
I remember well the assembly language crowd making the same argument back in
the eighties. Processors got faster and machines shipped with more RAM. The
tipping point was reached and all of a sudden no one was writing entire
programs that way.

~~~
sandofsky
While you wait for the tipping point, I'll be over here shipping.

~~~
modarts
Shipping slow, bloated software using a framework that is a second class
citizen on any platform you decide to compile to.

~~~
untog
That doesn't matter. What matters is whether your users care or not. We're all
app perfections here, as well we should be, but plenty of people are happy
with "good enough".

