
Basecamp 3 for iOS: Hybrid Architecture - mpweiher
https://m.signalvnoise.com/basecamp-3-for-ios-hybrid-architecture-afc071589c25
======
ryanwaggoner
I really admire Basecamp's culture of being thoughtful and forward-thinking,
without crossing the line into fad-chasing and reinventing the wheel for no
reason.

I'm a native iOS developer who is horrified by 95% of the "hybrid" or cross-
platform approaches to mobile development out there today. They all seem to
primarily be driven by a desire to use Javascript, or some manager naively
thinking they can cut their mobile dev budget in half, rather than any concern
for what's best for the user. I thought React Native might finally be a
sensible approach, but there's a long list of things I really dislike about
it.

However, Basecamp's mix of native and webview here is thoughtful and
appropriate. Rendering those web-based views with 100% native views would be a
huge pain for very little gain, and this approach allows them to retain much
of the advantages of an overall native architecture.

~~~
cabaalis
Your experience differs from mine. Having deployed around 15 production apps
for various clients and my own companies, there's just one thing you're
leaving out: Apple is not the only maker of smartphones that exists. The
choices for Hybrid were made for this reason, and very few ill side effects
have been encountered.

~~~
ryanwaggoner
I'm aware. You can build two native apps, you know. And it's very wrong to say
that there are very few ill side effects to hybrid. Both have their pros and
cons. I just think that native wins for all but the simplest or lowest budget
apps.

~~~
WA
I think hybrid wins for all but the most widespread or highest budget apps.

Most apps have only few users. Most apps don't have a million dollar budget.
Most users don't care or notice whether an app is native or not. They use it
to get a job done and don't care if that button is slightly less responsive
than another.

~~~
ryanwaggoner
Maybe most apps being a steaming pile of shit is part of why they only have a
few users.

Million dollar budget is a strawman. I've built dozens of complex apps for
five figure budgets. Very few ran into six figures, and they'd have been a
train wreck on hybrid.

Most things don't need to be an app at all. Those that do need an app should
at least consider making a reasonable investment.

Besides, it's not like hybrid is some magical unicorn technology that enables
creating a great app at a tiny fraction of the budget of a native one. You
save like 30-50% in the best case, and get what you pay for.

~~~
WA
You're right with everything you say – from a developer perspective. I agree,
most apps are indeed shit and that's why they have few users. I agree, you
certainly can build beautiful apps with a smaller budget. I agree, most things
don't need an app.

But, and this is a big BUT and the reason why hybrid is a good solution: Users
_demand_ apps. Your average user rather downloads an app for the local bus
service or a museum than going to a mobile website, because experience taught
them that mobile websites are shitty and some apps work offline, at least.
Yes, both of us rather use a good mobile website, but average Joe doesn't.

The app experience might not be better, it might even be worse, but users are
looking in the Stores for apps like that. The reality of the App Store is that
there are a handful of "good" apps everybody uses, and then there are the 95%
that are garbage anyways, but are still preferred over mobile websites.

I'm not saying that you can build the perfect app with hybrid, but solutions
that are _good enough_ for most people, because they want to catch the next
bus and give zero fucks about a _native_ experience. And then, saving 30-50%
or maintaining an app for Android AND iOS as a solo developer suddenly becomes
quite a strong point in favor of hybrid.

~~~
ryanwaggoner
_from a developer perspective_

I think you have it backwards. I think you're still hung up on the developer
experience, not the user experience. My observation is that users clearly
prefer native apps to hybrid apps. And yes, you can throw together a hybrid
app a bit faster, but you're just going to lose out to someone who did a
better job (probably with native). So you might have saved a few bucks, but
it's all going to be wasted.

Just my observation, YMMV, etc, etc.

------
jmkni
Good article.

I definitely think that for a cross platform app, going all out with something
like Cordova or React Native isn't particularly smart.

Sooner or later, you are going to reach a point where you need to use a
feature of the underlying OS which your abstraction layer doesn't support well
(or at all) and will end up having to make a horrible compromise.

Also, apps build with these frameworks usually don't look or feel native, I
can generally tell that I'm using something built with Javascript (not always,
sometimes the developers nail it, but a lot of the time).

However I feel that developing completely separate native versions of the same
app with zero overlap in code isn't smart either.

It's definitely good to find a middle ground.

I personally like Xamarin. Xamarin.Android and Xamarin.iOS get you as close to
native as you can get, while still allowing you to share a fair amount of code
between the platforms.

I'm using this approach on a project at the moment and it's working well.

I would love to try Basecamps approach here on a project, it seems very smart.

~~~
s73ver_
"However I feel that developing completely separate native versions of the
same app with zero overlap in code isn't smart either."

I don't see why. They're different platforms; you're going to want people who
are experts on the platform working on it, not someone who is only doing the
other platform because the boss said they need it.

I would take native teams for both platforms over one team doing a hybrid
thing any day.

~~~
yAak
Well, sharing business logic can reduce # of bugs and keep behavior consistent
between platforms.

That being said, actually shipping the same code on both platforms has its own
costs and considerations.

~~~
s73ver_
Most of that logic is usually on a web server somewhere, so it's already being
shared.

------
staunch
We already have a native and universal computing platform, the web, and yet
we're stuck in 2007 writing code for Apple and Google!

Is there any real movement on iPhone or Android moving to replace native apps
with offline web apps? Any competitor on the horizon?

Apple and Google are being very Microsoftesque in dragging their feet towards
the inevitable.

~~~
simonh
Except that the web was never designed to be a universal computing platform.
It's a hypertext document navigation system with a hacky, horrible, opaque and
insecure scripting language bolted on to the side. An actual distributed cross
platform application development and distribution system wouldn't look
anything like the web we have today. At least I seriously hope it wouldn't.

~~~
staunch
There aren't many grand designs in computing systems in general. Most evolve
from humble beginnings. The web has been evolving since the 90s, and it can
keep going.

~~~
simonh
Yes, absolutely, but it's still nowhere near being the one true answer to all
the world's software development and deployment woes.

This article on who they developed the Basecamp app is excellent. I'm toying
with a similar approach in a little interactive adventure app I'm writing in
Pythonista. Except of course that Pythonista isn't really native at all, but
still I'm using a webview to display location descriptions and various choices
as links, but native controls for things like inventory management and
displaying various stats.

~~~
oblio
> Yes, absolutely, but it's still nowhere near being the one true answer to
> all the world's software development and deployment woes.

One could argue that besides its original flaws, the web platform has been
hobbled and maybe downright sabotaged by the platform owners (Microsoft,
Apple, to an extent even Google). Javascript could have been cleaned up 10
years ago, same for many other web concepts still in use.

------
jeswin
For most apps (and especially for apps which have a lot of text like Slack),
Native is overkill and suboptimal though some people claim otherwise. You lose
standard functionality like Copy, Partial Text Selection, Web Search
(Selection), Share (text selection) with Whatsapp, Messenger, Copy Link etc.
All of which come free with a Browser view.

Even in a shopping app (where Native isn't so disadvantaged), a Browser View
lets you do a quick google search on the product or company. Once browsers
become faster, I'm hoping native will get relegated to games. If OS vendors
are listening, a way to install web apps beyond (a) "Click the three dots and
Add to Homescreen" or (b) the PWA thing.

Maybe just let web apps into the app store. It's not like the Appstore has a
high bar on quality these days, anyway.

~~~
kitsunesoba
>For most apps (and especially for apps which have a lot of text like Slack),
Native is overkill and suboptimal though some people claim otherwise. You lose
standard functionality like Copy, Partial Text Selection, Web Search
(Selection), Share (text selection) with Whatsapp, Messenger, Copy Link etc.
All of which come free with a Browser view.

I can't speak for Android, but under iOS you get all of that for free if
you're using UITextViews that have selection enabled (as opposed to UILabels).
It'll also give you Wikipedia/Dictionary/Thesaurus lookup popover, data
detectors (auto-linking dates, etc) and more.

There is functionality somewhat unique to browsers, sure, but it's a smaller
set than you may think and in many cases, dropping in a resource intensive
WebView for a couple of little perks is what's overkill.

Personally, my feelings are that if your app is mostly a webview, just stick
with a web page. There's little benefit adding a wrapper, and it strips
control away from me as a user (no blockers, etc).

~~~
icelancer
>>Personally, my feelings are that if your app is mostly a webview, just stick
with a web page.

I agree, but it is clear that those who grew up with phones do not. Apps
dominate the marketplace and use space for millenials.

------
alexashka
This is a nice write-up.

The summary here would be: we have a native app that provides the most used
screens, while the smaller text-heavy pages are rendered as a webview.

The webview hide elements that would normally display on desktop, that don't
make sense for mobile, via javascript.

Turbolinks is used to route links.

Overall, I think Basecamp makes very smart hires, with people who care about
technology and have a good head on their shoulders - making these types of
apps and write-ups possible.

Your average mobile dev(sweat)-shop would never be able to pull this off
because this involves good decision making and a stable team that communicates
well and is up to date on the latest tech.

------
sgt
It seems like a sensible architecture, and the app looks really good. I
appreciated the paragraph on hybrid apps, as many people think hybrid ==
cordova, which is not always the case.

------
dep_b
I've done a ton of apps for iOS and I'm really sure I'm never going to do
another implementation of vanilla segue unwind UIViewController routing ever
again, unless it's something totally stupid like an on boarding sequence.

For more complex applications that also need to open from push notifications
or respond to events and have several ways to end up in some sort of screen
(like going to a chat view controller discussing a certain document from a
push notification) it's just not doable to do all these tight couplings
between screens.

I create a router that has an enum per screen which can accept another
parameter if there can be a certain mode or certain data is required. The
router figures everything out and the enums force you to provide the right
associated data. Just call something like this from any place in the code you
want to segue and it's done:

    
    
        Router.segue(to: .profile(of: .followedUser(selectedUser)))

------
holydude
I would be interested in hearing about what made them to abandon RubyMotion.

~~~
ngsayjoe
I used to use RubyMotion, then i encountered crashes in my app that weren't
there previously (no code changes). It tried debugging for long time in vain,
then converted to Swift. With Swift, the language is fine but the way needed
to design the app really turned me down (Xcode, UIBuilder, Autolayout, etc.).

Then I discovered React Native, not only it is cross-platform (Android,
Windows) but it is also a joy to work with (the last time i felt this was with
Rails). My apps are now completely on 1 single code base, very maintainable,
as native as I want, and hardly crash. Besides, the binaries are so small (4MB
iOS & 8MB Android).

(PS: My android app
[https://play.google.com/store/apps/details?id=plus.land](https://play.google.com/store/apps/details?id=plus.land))

------
s73ver_
I would have liked to hear more from them on how the hybrid approach helped
them with sharing stuff with Android.

------
jtmarmon
Does anyone know of any other apps/companies going with this hybrid approach
using turbolinks?

