Basecamp 3 for iOS: Hybrid Architecture

https://m.signalvnoise.com/basecamp-3-for-ios-hybrid-architecture-afc071589c25

by mpweiher • 9 years ago

114 59 9 years ago

m.signalvnoise.com

sgt• 9 years ago

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.

holydude• 9 years ago

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

zimpenfish• 9 years ago

https://signalvnoise.com/posts/3807

Why did we move away from RubyMotion? Quite honestly: we needed to buckle down and learn the platform as a team.

Doesn't sound like there was any real abandonment as much as "We should use the tools the platform supplies".

ngsayjoe• 9 years ago

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)

ryanwaggoner9• 9 years ago

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.

gozzoo• 9 years ago

What about Fluter?

ryanwaggoner9• 9 years ago

Even more skeptical, especially since it hasn't caught on yet.

Now I have to learn Dart, trust that Google doesn't kill Flutter, trust that they'll give it their full support even though they're also supposed to be safeguarding and advancing native Android dev, etc.

Plus, I still have to deal with all the issues that any hybrid or psuedo-native solution adds. Things like feature lag, crappy and non-native UI / UX, more pain during debugging / optimizing, extra layer of bugs to deal with, lower community and support, etc, etc.

Just learn Swift! It's not that hard! :)

htormey4• 9 years ago

What do you dislike about ReactNative?

ryanwaggoner9• 9 years ago

To be fair, I didn't spend a ton of time on it and I'm probably wrong about many of my impressions, but...

My impression is that it's "native" only in the loosest sense of the word. On iOS, it creates a single view controller and then draws everything in there, I guess technically with UIView objects? But there is no use of native controls, so you're at the mercy of whatever crappy controls someone has created. Quality is seriously lacking for most of those. Essentially zero adherence to the greater platform standards or settings. Feels exactly like Java applets or Flash sites from the 90s. Blank canvas, roll your own everything. I guess the drawing of whatever you want is fast, but that doesn't make it "native".

A glance at the dumpster fire that is the "navigation controller" situation is enough to turn me away. There's still not even a standard way to handle multiple views and the transitions between them??

Also, I really dislike Javascript. Why would you prefer to write code in JS instead of Swift? The entire npm / dependency / build situation also felt incredibly brittle. Felt like if I came back to this app in 6 months and touched anything, there was basically 0% chance it'd still work without a ton of fiddling with dependencies, etc.

It just seems terrible.

I basically agree with most of what's written here: https://arielelkin.github.io/articles/why-im-not-a-react-nat...

(this also ignores all the baggage that any non-native platform faces, no matter how good. things like: feature lag, crappy and non-native UI / UX, more pain during debugging / optimizing, extra layer of bugs to deal with, lower community and support, etc, etc.)

cabaalis• 9 years ago

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.

ryanwaggoner9• 9 years ago

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.

jmkni2• 9 years ago

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.

htormey4• 9 years ago

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

I can’t really speak for Cordova but one of the strengths of React Native is that you can drop to native code relatively easily. I’ve done this in the past for projects and it’s not been a problem.

Can you give a specific example of such a compromise?

“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’d say the biggest problem with xamarin, aside from debugging, is that all your developers need to learn c# right?

At least with the other approaches (article, Cordova, react native) mentioned they can use languages used by the target platforms (web, mobile).

WA4• 9 years ago

Can you also share between iOS/Android and Web with Xamarin? Because that's what Basecamp's approach helps with.

yAak2• 9 years ago

Not in terms of UI, no. If you write your non-UI code in shared libraries that are PCL or .NET Standard and have your web-server use them too, Xamarin enables that scenario, but doesn't really bring anything else to the table for a web app.

jbverschoor• 9 years ago

You're comparing cordova with RN, and then you're saying xamarin is totaly different. It's not. RN are native components. In NativeScript it's the same + you get easy access to native apis

rawrmaan• 9 years ago

The abstraction issue you're talking about doesn't exist. You can always drop down to custom native components for anything you need to do. That's one of the best parts.

I spent 5 months rewriting my game Falcross from Obj-C to React Native, and it functions exactly the same (even better in some places because of RN's wonderful Animated API). Try the game and tell me if you "feel the JS": https://www.falcross.com/

As a solo developer, RN allows me to share 95% of code between platforms and still customize that ever so important 5% with native modules. And I'm iterating 2-3x faster than I was with Obj-C.

jmkni2• 9 years ago

That's awesome, I'm a solo dev too and I didn't know that about react native.

Definitely want to try it on a project at some point.

s73ver_4• 9 years ago

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

weaksauce2• 9 years ago

While a fully native solution from two teams would probably be better comparatively, it's also the most expensive. If you have something like react where you can share the common business logic and then drop down into native components when required to use features that haven't been exposed to react it's probably a net win. I haven't done much react native coding but it's certainly an interesting value proposition for smaller shops that can't afford to have two completely separate app development teams.

yAak2• 9 years ago

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.

jtmarmon• 9 years ago

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

jeswin• 9 years ago

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.

vintagedave• 9 years ago

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.

Whoa, no. One of the points of having native is to /have/ standard functionality. Native copy/paste, native sharing, etc. All those things have to be implemented and hooked up to by the browser or JS library, otherwise.

Not to mention native controls, the native UI behaviour, etc which is otherwise mimicked.

kitsunesoba• 9 years ago

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• 9 years ago

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

staunch4• 9 years ago

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.

alexashka2• 9 years ago

There's a thing called battery life and frames-per-second.

iPhone was initially supposed to be web-apps, then reality set in.

You're under the assumption that 'big bad men are keeping us down', whereas in reality, if you don't want your phone to run out of battery, handling website animations and transitions, the best you can hope for is hybrid, as Basecamp has done.

staunch4• 9 years ago

Yes, that was a reasonable and accurate explanation in 2007 or 2009.

It's decade later. I'm using Safari for hours at a time in web apps with video and JavaScript. Performance is excellent. Battery life is sufficient.

Now let me run these same web apps offline with embedded web servers or cached data!

simonh2• 9 years ago

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.

staunch4• 9 years ago

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.

alexashka2• 9 years ago

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.

s73ver_4• 9 years ago

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

dep_b• 9 years ago

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

Basecamp 3 for iOS: Hybrid Architecture

Related Stories