The official Basecamp iPhone app | Hacker News Reader

The official Basecamp iPhone app

37signals.com

57 pointsilldave51 comments

"Eventually we came to the conclusion that we should stick with what we’re good at: web apps. We know the technologies well, we have a great development environment and workflow, we can control the release cycle, and everyone at 37signals can do the work. It’s what we already do, just on a smaller screen. We all loved our smaller screens so we were eager to dive in. Plus, since WebKit-based browsers were making their way to the webOS and Blackberry platforms too, our single web-app would eventually run on just about every popular smartphone platform.", Jason Fried, http://37signals.com/svn/posts/2761-launch-basecamp-mobile

So, should we expect 37signals to ditch "bootstrapping" over VC-funded startups soon?

Let me be clear, I'm not out to troll 37signals. But here's the thing, if you claim a superior ideology, sell that ideology on paperback and then go against your own methodology, you're going to get some feedback. You can't claim that everyone is a troll, or a "cesspool" whenever people confront these ideas - especially when you're selling them for $.

You couldn't possibly have read the article. They took a hybrid approach, which means that the vast majority of the app is still written in html/css/javascript. "The page stacking behavior and navigation menus are native while the rest of the screens are web views." - straight from the article.

So a more apt analogy than yours might be "we should expect 37signals to continue bootstrapping but also take a small loan from a bank to cover short term expenses".

I did read the article. Both of them, actually. It was clear that most of the app is HTML5, CSS, JS. As originally stated in their previous post, they aren't keen on developing for multiple platforms natively. What they have released goes against the "write once, run anywhere" message that they've been selling for years. I'm quiet familiar with the tech stack they are developing on and so I know that while most is HTML5, there is definitely a development cost if they choose to go cross-platform. It's not as simple as you're alluding.

You can make an argument that 37 Signals is still keeping with their web app philosophy. For their new iPhone app, it's a web app with an advanced native wrapper & navigation functions.

Even with straight web browsers it's never 100% "write once, run anywhere" as any good web developer will know. You will always need to account for the idiosyncrasies of every browser, screen size, and system, and in the case of 37 Signals' new basecamp app, I see it as being no different. They most likely needed to gain access to some native apis and take advantage of a more reliable method of animating the page swipes.

And re-read your first post. You are suggesting that 37 Signals has done a 180 degree about-face, which is really unfair especially since you do actually understand the tech.

I'm not suggesting a 180 degree about-face. And if we were talking about a company that didn't sell philosophy in the form of books and blogs, my point would have much less relevance.

> as any good web developer will know.

Am I missing something here? Pretty sure I haven't written 2 books, decrying overhead and the ills of appeasement. 37signals have 2 books (which I've read) that clearly illustrate why you should avoid scope/feature-creep – especially for the cost of satisfying a few people. The avoidance of a native app followed this lineage.

I've watched the slow, articulated steps from "bootstrapping", Jeff Bezos, "this is different because X", etc. It's all very well and good, but you've charged people $. Like any customer, expectations are there.

So I am to ignore hundreds of pages of text because we all don't have the books in front of us right now for reference?

My overarching point is, if you're going to sell me an ideology - stay with it.

"So, should we expect 37signals to ditch "bootstrapping" over VC-funded startups soon?"

I don't know how anybody could interpret this as anything but a complete about-face. Ditch being the key word. For your analogy to make sense, 37 Signals would have had to ditch html/css/javascript as their main stack for the mobile app, which they clearly did not.

Sorry, this bit about ditching is tongue-in-cheek. I don't actually expect them to do so, although I do feel that eventually this will happen and we'll all be back here discussing why it's different because of X. I'm also confused why the overwhelming majority of HN readers manage to claim that a HTML5/PhoneGap app is inferior to a native one, but then somehow bob and weave when 37signals does the same thing. Confusing!

I have a problem with people speaking from authority, claiming their philosophy works well (which I agree with) and then slowly proposing the opposite. Again, as a frequent reader of their posts and philosophy, I'm confused as to why providing reference to this philosophy is considered blasphemy.

I'm also confused by the very vocal and opinionated damning of security in other platforms by DHH while Rails suffers security issue after security issue. Suddenly, DHH isn't all that opinionated on security. And I'm the jerk for pointing this out, right?

I know every person who disagrees with DHH or JF is automatically a troll without examination, but I'm a little tired of being considered a 37signals hater while I pay monthly for Basecamp, purchase their books and follow their line of work.

> I'm also confused why the overwhelming majority of HN readers manage to claim that a HTML5/PhoneGap app is inferior to a native one, but then somehow bob and weave when 37signals does the same thing. Confusing!

I agree with you there; it is confusing.

This makes me think you may have interpreted my criticism as either PhoneGap or Objective-C bias. For the record, I believe in the right tool for the job, so it does not at all bother me that 37signals went HTML5/PhoneGap/etc.

What bothers me is the slight of hand with the principals they are selling. In some broad respects, 37signals is the Oprah of the web biz - I know that sounds nuts, but I do believe that they sell a philosophy of betterment of the small business. There is a social responsibility, in my opinion, to uphold the tenets or at least explain why they are now different.

I'll agree that they should have at least acknowledged their previous stance.

So glad you posted this, I bookmarked that post exactly 106 weeks ago, and remember it well. especially this part

> So we stopped and thought about it for a bit. Do we want to have to hire an iOS developer and an Android developer? That’s a lot of specialization, and we’re usually anti-specialization when it comes to development.

I don't mind it when people change their minds about something, its a sign of intelligence, but if you're going to do it after having taken such a hard stance against the position you are now in favor of, at least do the intellectually honest thing and at least say "Yeah, we weren't in favor of this before, but we changed our minds. here's why" instead of acting like it never happened.

This. If I could replace my original post with yours, I would. This is exactly what I was trying to say.

Looks good. Shame there is no mention of Android at all.

The biggest thing I took away from this blog post was this.

"NOTE: Basecamp for iPhone requires an account on the new Basecamp (released March 2012). Basecamp Classic is not supported."

I wonder what % of users haven't switched over even after a year. I think this is a good lesson for anyone thinking about effectively launching a new product to replace one they already have.

The company I work for did a similar thing about 15 months ago. We still have about 10% of clients on the old system. We offered free upgrades to get everyone over but some didn't want it. New platform has now diverged sufficiently away from the old one that there is no direct upgrade path any more. This has effectively left 10% of clients stranded.

Looking back I think any replacement product needs to be 100% compatible and after x months clients are forced over. It causes some short term hassle and support costs but in the medium term really simplifies development work if old products are completely retired.

From my experience adoption of new versions is always pretty slow with 'normal' users. They don't care for new versions as long as the current version they're using gets the job done.

There's no mention of Android because this is an announcement for the iPhone version.

We'll be addressing Android at another time.

That makes sense. I figure since most of the pages are web views, it wouldn't be that difficult to release an Android version when/if needed.

Looking back I think any replacement product needs to be 100% compatible and after x months clients are forced over.

I actually think this is a ploy to get their users to convert. 37signals has a strong "we let our users outgrow us" stance, so what I read between the lines is that 37signals sees no hassle continuing to support the old system (it's massively profitable). Dually it gives a better justification for an up-sell to get people on to the new system.

I think this strategy is brilliant.

I'd love to take credit for a brilliant strategy, but this isn't one of them. The story is very simple. We released an iPhone app for the all new version of Basecamp. Nothing more, nothing less.

But do you see it an issue (i.e. costs) supporting two different systems? Why doesn't it support the old system? Surely that had to come up in conversation.

People in the tech world easily assume that upgrade = better. But that is only true if you feel underserved by the existing software you are running. Many customers out there in other fields don't have that feeling of being perpetually underserved that is common in places like Hacker News.

Worth noting: this was built using RubyMotion (http://www.rubymotion.com/).

I think this is the most exciting tech news this year. I really hope that this pushes RubyMotion further out into the mainstream. I've had phenomenal success with that toolchain.

I am interested in hearing how much was in RubyMotion. I would have been more excited to hear the whole thing was. I am not knocking the architecture. They have proven to know what they are doing when it comes to development and business. I am just waiting to hear about bigger projects for RubyMotion.

Seems a bit funny since just last September they blogged their mobile version and "no app required."

https://basecamp.com/1679267/announcements/10

One of the reasons I recall this is that I saved this particular e-mail newsletter at the time. I thought it of particular interest they dedicated resources on making a mobile browser performant version and had eschewed a mobile application approach. So what has changed or did they feel a deficiency in that version?

There's still no app required. The app is completely optional.

So as a confused customer, what option do you recommend and why are there two options if both are similar in function?

Try both for a few minutes and make a decision?

The app is the best experience. If you don't have the app or it's not supported on your platform, then you have the regular mobile web views to fall back on.

Interesting that it's launched within seven days of http://getcampapp.com/... There was even an item about it this 'morning' on HN.

I wish they just put more effort into making their web interfaces more responsive. Trying to use Campfire from the browser on my Galaxy Nexus is nearly impossible.

Not sure if serious.

I downloaded the iPhone app and tried it out. I'm actually quite impressed. The interactions are quite speedy and the app has a "native" feel to it. It also helps that the design of the app is quite nicely done.

I've been a big proponent of full native apps on mobile when possible. But this has got me thinking that the hybrid approach can be a smart move when done right.

I remember when they said the way to go was HTML5 and all that talk. Glad their changed their vision.

It's a hybrid app, views written in HTML5 & CSS3, and wrapped on the device. Navigation is native.

(Source: the post)

I assume he is referring to Basecamp Classic Mobile [1]. Reading the post, it seems they thought HTML5 was the "way to go" because they had more experience with the technology, not for any particular technological reasons.

[1] http://37signals.com/svn/posts/2761-launch-basecamp-mobile

Chances are that in a year or so, they'll release a completely native app. That seems to be the trend now - go HTML5 initially to get an app out fast, then create a native app later.

All of the content screens in the app are still HTML5. Because of that direction, we now have a native experience on iOS AND a solid mobile experience in the browser. HTML5 still offers the greatest reach, a superior layout model and the fastest development. It's a myth that web views are inherently a poor experience.

From a friend I saw logging in, it seemed like the oauth webview screen (that 3rd party apps use to interact with the API) has been ditched for something native as well. Something 3rd party apps can never re-create.

The login screen for the official app is a webview as well. Most of the app is!

So if they're using Rubymotion for their iOS hybrid app, I wonder if they'll use http://ruboto.org for their Android hybrid app?

Simple, dumb questions: So what is the point of it being hybrid, actually? Speed of development? Multiple platforms?

Both, and more. We're aiming to post a series of articles on Signal vs. Noise about the decisions we made.

I'd be curious about this topic, not because I'm pro or against this approach. I've worked on both sides of the spectrum (web app wrappers, full native and lately a hybrid, which is more complex than Basecamp) and it seems like a fine balance needs to be reached. You're "fortunate" that you keep the UI pretty slick and simple. And I say "fortunate", because I know this is actually a choice.

These will be very helpful to the mobile community. It's great to read about larger scale services and how they tackled mobile. It was great when LinkedIn shared about their new mobile app and the development efforts.

Native views and web views are good at different things.

Native is good for high fidelity interaction, animations, responding to gestures. However the native APIs are bad for designing "documents" -- that is, layouts where elements flow within a container and push each other around. That means that things that are extremely easy on the web can be painstaking in native UI without much upside.

Web views have limited interactivity, but they have other advantages:

* Faster iterations. You don't need to push a build when a webview changes.

* Document-style layout, as mentioned above.

* Higher density. We found it easier to show more information on the screen with HTML/CSS than the native controls. Looking at other apps out there makes me think it's an attribute of the medium, not just us.

* No need to sync data or duplicate logic. Sending HTML down the pipe is simple.

Finally yes, we get the multi-platform advantages because the web views are also served to people who hit the regular mobile web version of the app without any wrapper.

I'm on a project where we're taking the hybrid approach and I can second all the points Ryan has made here. We are launching our app soon on iOS and Android so we're getting the full benefit of cross-platform compatibility. We've run into literally zero cross-platform browser issues during the process, too. Hybrid is definitely the way to go if your app is text heavy like Basecamp and our app.

Agree. Another benefit is that the capability of browsers is increasing daily e.g. flexbox layout

Part of the benefits of being hybrid is that yes you can iterate slightly faster, at least if you're coming from a strong web background. Also moving to webviews allows you to bypass some of the issues with submitting/changing content to the App Store which involves on average about a week's wait to get changes out.

What about a native iPad version?

One step at a time.

Reply on news.ycombinator.com