Mobile clients for SaaS web apps

Discussions
#1

This comes from a discussion @ian and I had on the latest episode (19) of Bootstrapped. I’d love to get feedback from some of you as well.

My new app will be a web SaaS product, with a strong focus on making mobile the primary interface to the app. This is mainly due to the fact that the web app is a derivative from some of our existing BlackBerry applications, which already have customers that have moved on to Android and iOS, but for whom I cannot build native Android and iOS ports (due to technical reasons). So, the idea is, they’ll be transferred to a web-driven application, with iOS and Android client apps working against the web app, rather than being bound to the platform API of the device.

Anyway, my personal background puts me in a situation where building native mobile versions of the iOS and Android clients would be faster for me, than building either “responsive”, or dedicated mobile web apps with HTML5/Javascript/jQuery Mobile/Backbone/CSS3, etc.

If you listened to the discussion on the show, @ian is a proponent of building the client apps native. But I’m of the opposite mindset. Here’s the reason.

Even though it’s a larger learning curve for me to be able to build the mobile clients as a web app than as native apps, I don’t want the mobile client apps to have the dependency on the ranking star system of either the Apple app store, or Google Play.

If someone who couldn’t care less about my app finds it on a “new releases” list, then gives it a 1 star rating because they’re having a bad day (VERY typical behavior in the mobile marketplace these days), then my mobile client is sitting in the app store with a low rating that I can’t do anything about. And, if a person who is actually looking for something like my app finds it in the store, that low rating will turn them off before I can even try to sell them on the product.

The other side of this, is that if I don’t have a native app, I have to swallow the pill of having to tell my customers that we’re not in the app store, but if you go to this URL, and click the favorites/bookmark button, you can still get the same icon on your home screen, and the app will still be just as good as if it were native (there really isn’t anything in this app that would require the performance or feature access of the native device).

Thanks for reading this far – it’s sort of a brain dump.

Thoughts?

1 Like
#2

Hey Andrey,

So, although I have limited experience doing native apps, I do have a lot of experience doing HTML mobile apps.

The big win with HTML is that you control the distribution channels, hands down. As you mentioned, that alone can be a good reason.

That said, there are some apps (game, or game"like" apps) that are a waste of time to try with HTML (although some people have gotten very good at it). But, it sounds like your idea may be a good candidate for HTML.

With the handful of products I’ve worked on that targeted mobile, we often started out with HTML thinking, once we got the product out there, we would do native versions … but we never had to. Customers never asked for it.

Also, having the web version makes email marketing much more effective. The links you put in your email don’t flip the user out of context into the app store, but go right to your app.

Lastly, I’m sure we’ve all heard it, but the local storage, Backbone, and CSS transformations have made good quality HTML apps a reality. See forecast.io for one of my favorite examples.

If you have questions about how to approach HTML apps, or what the problems are specific to your use case, feel free to ping me.

#3

We went through the same decision process and came down solidly on the side of building a mobile web app. Some reasons:

  1. One platform/code base to develop and support. Yes, there are all kinds of difference between various mobile browsers, but jQuery Mobile and other similar tools do a very good job of abstracting away most of those differences. Having to build/maintain/support separate applications for iOS/Android/Windows/Blackberry is just not something that I think makes sense for small product teams with limited resources.

  2. Consistent user experience. We can provide a much more consistent user experience across devices with HTML5/CSS than we could with the native SDKs. This pays dividends when providing documentation and customer support.

  3. No app stores to deal with. No dependency on app stores being up when you need to push a critical update. No waiting periods for acceptance into the store. Also, we try to turn this into a positive for our customers. No need to go to an app store and download an app. No need to worry about ever updating it. Just visit this URL in your browser and you are good to go and will always have access to the most recent version.

  4. Star Ranking. We never even considered this aspect, but you have made a pretty compelling case that until the app stores provide a way for developers to respond to user comments, this whole aspect is best avoided if possible.

In my opinion, the only reasons to go native are if you need access to device functionality only provided by native SDKs, or you need the performance of native UIs. It doesn’t sound like either of these are an issue for your app.

#4

Well now Andrey you and these guys have been swinging back the other way :smile:

I still have a few concerns.

  • If you need something only a native app can provide (like native notifications from what I can tell)
  • If it’s an app you’re in all day (I like forcast.io a lot, but waiting for it to load I do find bothersome sometimes and that’s just weather)
  • If competing apps have native apps and your installation procedure is now more complex

It’s such a tough call. I guess something else to mention is the phonegaps of the world and the general idea of a native app that’s mostly just a web view. Any experience with those? Perhaps providing the best of both with a web only option and light native wrapper?

#5

I love this discussion so hard.

For what it’s worth, I’m on board with Andrey - not being enslaved by the stores and their rating systems sound great. But it depends on the app and who it’s for. If it’s aimed at businesses, I don’t think not being the store will be a HUGE deal. If it’s aimed at consumers, not being in the store might mean you effectively don’t exist.

#6

Why not just start with a web app as the front end? You can keep the front end/back end logically separated so that it would be easier to replace the front end if needed. I suspect web developers, even responsive, mobile ones, cost less than native mobile devs, so you might be able to outsource the creation of an initial front end while you work on the back end.

#7

@steve I believe @andrey will have a normal browser front end no matter what. It’s more a question of if the mobile solution for this saas app should be a mobile specific web view or a native mobile app.

#8

Thanks, @ian. I understand that; sorry if my reply wasn’t clear. Start with a mobile-friendly web app as the front end. Create a native front end at some later point if it makes sense to do so.

#9

I think I am leaning toward web only based on what I have read. Of course not ever developing for mobile only I do not know all the idiosyncrasies of the “app” stores. But having to wait on an approval before pushing updates seems worrisome. I guess I am spoiled in that with a SAAS app we deploy multiple times a day and it’s all just magical.

Going back to the original iPhone wasn’t a bookmarkable app all they initially included until the masses complained so they built the app store? I could be way off but I do remember pre-appstore days.

I also like the thought of a light weight native wrapper like @ian mentioned. I think that is doable but would still be in the store so may not be ideal. But an advantage could be you package all the js dependencies inside so you don’t have to worry about downloaded those. In your example jquery mobile, backbone, plugins. Then your main app.js would just pull in as normal saving those few milliseconds. Also depending on your app with backbone you can pre-seed your primary data so you are only doing minimal requests to get most of the data you will need.

I guess at the end of the day it’s just a toss up. :smile: Go web only as long as you can reasonably get up to speed on those technologies and if it becomes an issue PIVOT. When you have customers paying you millions hiring somebody to build you a native app will not be to difficult.

#10

Thanks for all of your feedback guys. It’s awesome to have a place when the answers to these types of questions are backed by such thoughtfulness and experience.

Right now, I’m still leaning toward making the client app a web app, but it’s early yet in the development of this project - things could go either way.

I will probably post an update here eventually, when the app is closer to launch, and I’ll certainly keep the conversation going on the podcast.

#11

It looks like http://phonegap.com/ has really come a long way. Just poked around a little bit, it seems like it wouldn’t be too much work to start with a web app and then if needed or as a little extra sugar provided a wrapped version so that you could reach the app store or provide niceties like native notifications.

#12

I think that making the client a SPA with something like Marionette or Ember would be a good fit. You then benefit from a few things:

  1. You have an API that can be a selling point
  2. The same API can be used later for a Native app
  3. You can port it directly to Phonegap and give a somewhat native experience

Real time and push notifications might be a problem, but it sounds like you are already using email alerts for things like usage so that should be fine for the use case (I think Phonegap may have something to handle notifications too…)

#13

For those with a little budget, the Sencha Complete package actually looks pretty cool. Seemingly everything you need and apparently even an included utility that will bundle your app into a native one. Even without that though, it seems the most capable for serious B2B setups.

http://www.sencha.com/products/complete/

#14

At Paymo we currently have two natives apps (IOS and Android). Since we didn’t have in-house talent at the time we decided to build the mobile apps we outsourced this task to a couple of mobile dev companies. After a very long and painful process we ended up with two “meh” apps that we’re not really satisfied with and we found out that outsourcing this simply won’t work for us.
Right now we’re closing in on launching our brand new version 3.0 that we’ve rebuild from the ground up and decided to do web apps for mobile in Sencha. Some of the reasons:

  • one codebase to support, the interface differences are much easier to handle than having two or three separate versions of the app. Supporting 3 platforms is very hard, costs a lot of money and time.
  • more consistent UX
  • we used Sencha to build the “desktop” app, we should be able to re-use some code
  • a lot of users list performance as an issue when talking about native vs web, imho in 90% of the cases it doesn’t really matter. We’ve seen excelent performace with web apps, check out this Sencha Facebook app If you’re not building games or anything that relies on the hardware a lot you have a safe bet in html.

We plan on adding the apps in the appstores but we’ll also allow users to access them directly. I think the risk of not being in the appstore outweighs the risk of negative comments (btw, unfortunatelly it’s a very common practice for competition to leave negative feedback).

#15

I agree with the concern that a free app will have a lot of 1 Stars and un-needed support for people not actually signing up.

I think you can get a bit around this by making the client app 99c (possibly link up a coupon discount for users where you discount their monthly subscription?). This will have fewer of the mass downloaders that will annoy you.

On another note, while there are gotchas moving to Javascript from Java/ObjC, frameworks like Ember or Marionette give you a more Cocoa and Swing development feel respectively.
From there if you have a lot of demand for actual mobile apps, then just wrap the single page app in phone gap and call it a day!

#16

If you have an existing customer base why are you worried about app store reviews? I’d focus marketing the customers you know about who have already transitioned to Android/iOS.

Lastly, assuming your product makes customers happy, worrying about 1-star reviews is just a different kind of bikeshedding. The users having a bad day aren’t typically significant enough discourage people who want a solution to a problem.

#17

Am I the only one that can’t be fucked crawling through a mile of shit in the various app stores to find an app that does the job? App stores seem pretty useless for actually finding apps. Instead, I google ‘best blah app for device’, find some reviews by people who have a modicum of credibility (set up a blog?), and go with whatever they recommend. I probably wouldn’t discover a mobile optimised web-app that way, but then, when I’m searching for apps I’m in the mood to pay 0.99 cents, so you probably don’t WANT me to find you that way.

(Love the fact that I can push apps to my android phone from the browser. Oh AND that I don’t have to type in my password to install a free app. AND that I don’t have to make a tradeoff between the security of my data stored in the cloud and convenience of being able to install stuff without remember a complex password. But that’s another story.)

(ALSO people who “write” “reviews” of the “97 best pdf viewers for iOS” with no ranking or recommendation can go drive into a tree. Wasting my precious bandwidth.)

#18

First off I haven’t listened to the latest episode of the podcast and I’m biased because I do native Android dev, so please take whatever I write with a grain of salt.

That being said, my Android wine app is ranked #1 worldwide, and has 20K new users/month without any marketing or advertising, so I must have done something right.

I don’t think it would have been possible to achieve those results by developing a webapp. I haven’t yet seen webapps that come close to the level of polish that can be achieved in native apps. I just installed Forecast.io on my Nexus 7, and all I see is a relatively cool webpage. Nothing that can be compared to native weather apps like Yahoo weather and others.

Publishing in Google Play isn’t really that bad, especially now that you can reduce the risk of pushing out a new version by using staged rollouts. Being in Google play and getting thousands of 4 and 5 star reviews was an essential part of that. And yes of course there are those people who give you a 1 star, but as long as they are vastly outnumbered it doesn’t make a difference.

Of course for a B2B app things would be completely different.

2 Likes
#19

OK, now that I’ve listened to the podcast, and had more time to reflect I’ll try to add some value to the conversation by actually concentrating on the SaaS B2B question as originally posed.

Ian’s arguments sounded way more convincing to me than Andrey’s.

Aside from that, it seems to me like the major flaw in Andrey’s thinking is that he has to cover all the platforms to be successful. But if you try to do that with limited resources, at best the result will be a mediocre app on all platforms. If someone else goes after the same market with the same amount of resources but concentrates on making a kick-ass app for the most promising platform they will win. And then if it makes sense, they can then extend the product to the 2nd most promising platform.

Of course the App store must be a huge pain to deal with, but it does also alleviate the pain of marketing.

To avoid the 1 star drive by reviews, I would consider selling the app for the same price as the first month of the SaaS subscription.

Andrey, I hope you don’t take any of this as criticism. I’m just trying to help by bringing in another perspective.

One last thing, I think http://archisnapper.com/ is a pretty good example of SaaS with a native app front-end. They seem to have gotten some traction, 4K MRR last I heard. And they went native.

#20

I thought it worth updating this thread to include the thoughts of Dan Bricklin on the topic (gosh, I really hope I don’t have to explain who he is to anyone here… ok super short version: he invented the spreadsheet.) who’s thoughts on pretty much any computing subject I give serious weight.

Summary, for most things/teams Javascript/HTML5 would be the way to go.

1 Like