The Shape Of Mobile Development To Come

Mobile is still the exciting Wild West of today's software. There's only been about five years of modern development (not going to count the Java ME dark ages) and its best practices are still being discovered.

I have some "long bets" about mobile development, which will hopefully come to fruition in the next two years. These are how I see (or would like to see) developer tools and processes evolve; maybe I'm totally wrong, but I'd love to hear what you think.

Tools Empowering Designers

Beautiful apps are hard to make. Designers are creating increasingly intricate and pixel-precise UIs, but porting these to actual code is a slow and painstaking process which usually leads to details getting lost in translation. The visuals alone are brilliant, but unfortunately what really matters is how they end up in a working product. For every rock-solid Path there are dozens of apps that have visible errors and discrepancies between what the design team intended and what engineering shipped.

When I talk to mobile-centric startups, I always ask about the workflow between design and implementation. Several companies are trying to enforce rigorous oversight to make sure everything looks and feels correct, and that is definitely one solution to the problem. But the truly frictionless way is to create new tools that empower designers and take engineers out of the equation.

Within the past few months, I feel there's been a collective epiphany about this. PaintCode and Pixate are currently addressing aspects the problem, and I know of several unlaunched efforts in the pipeline. MarkupWand and CSS Hat are really great ways this pain is being attacked on the web, and it would be interesting to see similar "PSD → Code" work done for mobile.

Chopping assets, correcting alignments, and tweaking animations aren't the core-competencies of a mobile engineer. Those tasks require many re-compilations and a continuous back-and-forth, taking up man-hours which could be put towards making the product stable and performant. Why should we keep producing our designs "twice" when converting the original might be within our grasp?

More Languages

"More languages" is generally true for all fields, but it especially proved true for the web. Writing backends gradually shifted from bare-metal compiled to higher-level scripting languages, and I think that trend will continue on mobile.

For most of the past five years, there have basically been two choices: Java and Objective-C. Objective-C in particular has evolved over the past two years to become an "easier" language with the addition of ARC and improved literals, but given the choice I would still prefer something like Ruby for most work.

Ruby turned out to be a winner on the web, so it's not unreasonable to think it might happen again on our smartphones. I've written in the past about RubyMotion, and there's also an Android counterpart Ruboto. But there still more alternatives: Nu and Clojure for Android allow you to write apps in Lisp, and Scala was used in production at Bump.

Will developers stop writing apps in Objective-C and Java? Of course not; companies still write web code in C++ and Java. However, a greater variety of languages will undoubtedly help bridge mobile development to all sorts of new developers. That's what gets me excited.

Better CRUD Frameworks

When it comes down to it, there shouldn't be a whole lot of business logic in most mobile software. All the heavy lifting should be done by servers, and apps act as (very pretty) shells for that data. They should cache and gracefully degrade the experience during offline periods, but internal structure should always mirror and sync with what the server dictates.

If that's true, why aren't there frameworks which make dealing with APIs as seamless as Rails makes interacting with a database? AFIncrementalStore and RESTKit are definitely steps in that direction, but they focus only on the API-Model relationship. Rails has the wonderful ability to generate views and forms based on models, so why don't we do that too?

Code speaks louder than words, so here are some ideas I've been playing around with (in Objective-C, but equally applicable to Java):

@interface User : MagicalFrameworkModel { }

...

[User find:@"1" success:^(User *user) {
    // User w/ ID 1, retrieved via API
    self.user = user;
} failure:^(NSError *error) { }];

...

// Generates a UIViewController populated with correct
// KVO for that class.
FormController *editUser = [FormBuilder controllerFor:[User class]];
[editUser setUser:self.user];
[self.navigationController pushViewController:editUser animated: YES];

...

// Creates a UI element KVO-bound to property of a model
FormTextField *observing = [FormBuilder textFieldFor:user property:@"name"];

I built some of that functionality into RemoteModel, but there's a ton more to be done in the space. If we can make CRUD development on mobile that painless, we could iterate our mobile products much faster and with less underlying knowledge of how each platform works.

Web Apps?

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.

The fact of the matter is there are hard technical limits to how far we can push web apps. Web views on all platforms generally eat memory and that, coupled with the lack of Nitro on iOS, means you have to put a lot of work into making them fast and stable.

I think the "write-once-run-everywhere" benefit of web views is disingenuous; the phrase should really go "write-once-optimize-everywhere". There are specific nativization techniques that work better on each platform, plus some elements like text inputs won't ever feel "right" when done using HTML and should be coded by hand. Heck, Apple's App Store app feels terrible and they make the operating system!

In the end, I don't see web views getting very much closer to native apps than they are today. Facebook, the famous proponent of the whole web-native-hybrid idea, is reportedly shifting back to native. The whole reason most companies use web views is (rightfully) writing two sets of app code is resource intensive. But what if there was another way...

True Write-Once-Run-Everywhere

This is the big bet, and the one I'm most likely to be wrong about. But if you take all of the above bets (more languages, abstractions for API communication, decoupling design from code) you can arrive at an interesting conclusion...

What if you could write true native apps for both iOS and Android with one codebase? All you need is a language that works on both platforms, like Ruby, and a level of abstraction above both MVC frameworks. The models would be easily portable, controllers on both platforms share a similar lifecycle, and with Auto-Layout coming to iOS perhaps there's an easier way to map between iOS and Android views than we previously thought.

Imagine writing code like this and having it build to native apps on both platforms:

class ListController < Magic::MetaController
  def setup_view(view)
    @list_view = ListView.new
    @list_view.fit_to view
  end

  def view_ready
    @row_data = ["Hello", "These", "Are", "Rows"]
    @list_view.rows = @row_data

    @list_view.on_tap do |row_index|
      App.alert(title: "Tapped!", message: @row_data[row_index])
    end
  end
end

The "make a language that works on both platforms" is pretty hand-wavey, but if that can exist then I think we can do really incredible things.

I'd love to hear your feedback about these wild ideas on Twitter and Hacker News!