Most apps are either thin-clients for server APIs (Whatsapp) or fat, stateful, rich clients (Games) that sync state with the server. You can probably break any app down into the following sections:

  1. Network Layer — server API calls over HTTP, TCP, UDP black magic
    • Object mapper to get domain models from JSON
    • May need to support caching
    • Retries with exponential backoffs
    • Detect network connectivity
      • Does device say we have internet? If not, don't even try.
      • Do we really, really have internet? Can we talk to our server?
  2. Data Access Layer (SQLite, SharedPrefs, Core Data, or Realm)
    • ORM support mapping to/from domain models
    • Thread-safe access
  3. Platform Layer — API calls to use device features (network state, sensors, BLE, camera)
    • all your silly "ThisThatOtherManager" classes
    • Manage notifications (GCM, APNS)
    • Background services that record or publish device/sensor state
  4. Here be dragons
    • encapsulates all unholy complexity
    • XML layouts with i18n strings, conditional views and strings
    • the goddamn View-Controllers
      • code trying to make sense of it all (what is the purpose of life?)
      • silly variables tracking user or view or task state, isClickingButtonAfterFeedingCat
      • Lots of if-s, else-s, switch-es
      • Scope for state-machines to track state, but nah
      • over 90% of bugs, debug time, and changes go here

App development really boils down to management of view-state. Everything else falls into place super easily. This is also true for single-page webapps written in [extravagent-framework-here]. IMHO, Angular v1 did an impressive job with this.

There are many opinions on how to structure the 4th layer. The one I find most useful is Dagger2 (DI framework). Dagger2 introduces compile-time DI which addresses many of the performance criticisms of Dagger. DI is an interesting pattern since you can easily swap mocked implementations or dev envs. See this code sample from Google. Layer 4 is also where react-native operates so you may find that route useful if your app has the same look across platforms.

After giving react-native a shot, I'm not convinced it can handle acute UI design changes as effectively as plain old XML layouts. UI performance is perfectly fine, but this may be problematic if your team has been doing native UIs so far (from a code maintenance and release-cycle standpoint). Much like how we'd hit walls in Phonegap apps when certain native bridges and features weren't available yet, with react-native you may end up writing more native code for each platform for those pixel-perfect designs than you can justify. But in the near future, I think react-native has immense potential to be the de-facto way of building mobile apps.

Cross Platform Business Logic with Go (gomobile)

Fair warning before you hate me for this, Arrays (slices in Go) don't work yet.

Check out Nic Jackson's talk and come back to see why it may be useful.

The components that can be productively reused across platforms deal with business logic. Users interact with views and trigger certain states that require an action at the server-side. You have API calls in all your iOS, Android, Desktop apps. All API responses map to some domain models. Those domain models are processed by some business logic and the views show the results. What changes across platforms the most is the View-Presenter.

Here's where Go comes in. Go compiles your business logic to native code and generates bindings for iOS and Android. This is exactly like C/C++ code that you call via JNI in Android or use directly in iOS, but with Go you get a bunch of neat features that includes a simpler concurrency paradigm.

Some ideas that may make this useful for you —

  1. Move all REST API calls, response parsing, and models to Go. JNI/bridge maps models in Go to data models in Android/iOS
  2. Persistence layer — replace CoreData or ContentProvider/SQLite with an embedded database in Go (such as Bolt)
    • Data is somewhat protected compared to trivial SQLite access (but you could use Realm)
  3. You can offload your async computational tasks (RxSwift/GCD, AsyncTask/Bolts) to Go and have cross platform async tasks
    • Performance "isn't terrible"; haven't benchmarked
  4. Compared to writing Java code + proguard, this may give you better code obfuscation
  5. Perhaps most importantly, you can independently develop and test business logic for all platforms

However, all this is not without caveats —

  1. Only simple data types are supported. [See doc]
  2. Large API responses that need to cross language boundaries may be slightly slower to load (large ListViews)
  3. Integration tests become a lot more important (which you should be writing anyway)
  4. Generated library file can be of significant size. For android/arm, .aar file is about 6MB

Do not adopt this approach for any performance benefits. In fact, there may be performance penalties during interop across Java-Go boundaries. Many benchmarks still show Java to be faster than Go because JVM is undeniably state-of-the-art. Dalvik and ART probably also have good design decisions backing them. This approach also disregards many of the scheduling and thread-priority features that higher envs provide (GCD, java.lang.Thread).

The gomobile project is also working on allowing devs to write entire apps in Go. I have only discussed a small subset here (gomobile bind) since much of the rest is far too experimental.

The implementation of this that got me excited uses the following stack —

  1. Server-side exposes APIs with Google's gRPC framework

  2. Client-side uses a realtime HTTP/2 transport that is generated from a protobuf service definition

  3. Tiny client wraps transport details and exposes interface for external calls

See Makefile for build steps.

btw, Google API open-source clients now use autogenerated code created from service definition files. I think that is very neat.

Background

Met up with an old friend last week to catch up on changes in the app development world. Pretty much everything is the same. Unlike the JavaScript ecosystem that churns out a new development paradigm every quarter, app dev hasn't seen sweeping change.

HTML5 webview-based apps still aren't good enough. Despite its promise, Appcelerator still sucks. Xamarin is great but nobody cares (except maybe enterprises). Design language continues to vary across platforms and except for hugely popular apps, everyone is sticking to what the platform prescribes (unless costs or time don't permit).

So our discussion went into how dirty it feels to implement the exact same business logic in Android and copy/pasta it into iOS. Having developed the (as yet unreleased) iOS and Android app for BrowserStack (with a kick-ass team), the discussion went into familiar territory. We did take a few decisions in our app such as using RxAndroid and RxSwift to reduce learning [read: threading surprises] across platforms, but duplication of business-logic at the time seemed unavoidable.

State of Android

Devs working on complex apps are starting to pick up DI (with Dagger2) and RxAndroid or Bolts for async tasks and dataflow. Retrofit is the de-facto REST API client. Robolectric has championed unit-testing, devs use it in conjunction with CIs. Fabric is the preferred crash-reporting platform (over the likes of Crittercism). Leak Canary is a blessing included in all projects from the very beginning.

Java 8 features (lambdas, etc.) still aren't deemed important enough to refactor or include Retrolambda according to my friend. On the product side, there's more demand for supporting tablets and android TV is now also expected to work. Fragments are totally in. Google continues to help out by pushing new view helpers and material design components in the support libraries.

ReactNative

For cross-platform iOS and Android development, react-native is apparently a joy to work with and comes with first-class debugging features, but things often break between versions. OSS contributions are also picking up. Folks who had webview or hybrid deployments and significantly invested in JavaScript-based app dev teams jumped ship quickly to react-native for native UI performance gains. Aside: NativeScript/Angular2 have completely lost dev mind-share, or so it seems. I suspect Angular2 would've done better if they had released under a different name. It's sad to see all the undue hate being thrown at it.

Native devs are still hesitant to pick up react-native. While designers and UX folks continue to push for a consistent experience across platforms, they also see value in UX design languages like Material Design and native experience (animations, transitions) — which means teams would likely end up with significantly different codebases for iOS and Android views. react-native may be the most promising solution to view-state management and cross-platform development thus far, but it's not there yet. react-native + an embedded database like Realm could allow a lot more code sharing across mobile platforms. If you do go for it, you may have better luck allocating webdevs to react-native projects than coaxing Java and Objective-C devs to code in JavaScript/ES6.