Live data from Hacker News

Start with a Website, Not a Mobile App

atrium.co

361–370 of 587 posts

Re: Start with a Website, Not a Mobile App

#361

Earlier quoted context omitted.

I like this concept. Using the smart phone more like a PDA than a tiny laptop. What are your 10 core apps if you don't mind sharing?

For me: Personal Capital (finance), WhatsApp, Slack, Overcast (podcasts), Kindle, Dark Sky (hyper accurate weather app), Google Authenticator, Lyft, RENPHO (my smart scale’s app), 1Password Everything else is very situational and totally optional.

BlackPlayer Ex (Music), MyBible, EasyWay (public transport), Multitran, WireGuard, Moon+ Reader, Smart AudioBook Player, CF.lumen, YouTube Vanced, Flud (torrent client), and YouTube Downloader (from XDA) are my essentials.

I like trying new apps, and will often go through a lot of apps to find ones I like.

Re: Start with a Website, Not a Mobile App

#362

80% of apps are uninstalled in the first 10min (especially if they ask for information or creating an account). Once uninstalled very unlikely they will ever install again. In my dev shop, I always advise clients to look into website MVP over apps unless IT IS CRITICAL to the functionality. Websites can always bring back ppl who were initially uninterested. Faster development/instant updates. Better tracking and UX a…

Thank you! I personally think that mobile web and app design has been one of the greatest atrocities in tech. Not only is it trash on mobile, it's spread and made lots of sites trash on desktop as well because people seek a one-size-fits-none solution. I personally go by the rule that if your service can work as a website, it should be a website. Not ever a standalone app unless there are important requirements which…

Id suggest a cloud VM except for bandwidth/latency issues.

Re: Start with a Website, Not a Mobile App

#363

Earlier quoted context omitted.

What I am aiming for is an application that never locks up and never makes you wait without clear indication if it is making progress or not. I could care less about many "Native Features" but latency is king. I am sick and tired of looking at spinning beach balls and such.

If your data backend is over the internet, it doesn't matter if it's a "native app" or "pwa". You can handle appropriate state in most cases. If you're good at it, you can do it at the most atomic level, and should be relatively quick. If you can shard your api/data systems by locality, even better.

It's the 95% latency that kills you.

I have seen so many people make an app that is blazing fast at the office (either on a LAN or w/ a fast connection to the cloud) that ends up horrible for many end users. Sometimes the people who made the app don't even know.

Re: Start with a Website, Not a Mobile App

#364

Earlier quoted context omitted.

> I don't even bother installing apps anymore, I don't have time to research whether or not they are going to abuse my privacy or have some horrendous TOS. I'm going out on a limb but I'd wager you're not exactly representative of the general userbase for which apps are developed.

I would take that even further and venture a guess that 99% of HN readers are not representative of the intended general userbase of 99% of the apps for ios/android.

My personal guess is even more far-fetched but I think the ratio between useful and useless native apps reached 1/100 very, VERY fast after the industry successfully implemented wiring money as a feature. That was the one thing, even bigger than successfully implementing ads.

Re: Start with a Website, Not a Mobile App

#365
post #275

Earlier quoted context omitted.

> I'm speaking to this discussion, not the submitted article. Precisely my point. That's not what the OP was saying. Per their comment: to get people to install your app just to try it out. > based upon the same "this changes everything" argument we've heard every year. Did we read the same comment? Where did the OP write "this changes everything"?

You're using OP to mean "the root-level HN comment" where @endorphone thought you meant TFA.

I am, but they're both making the same point, so it's kinda moot.

Re: Start with a Website, Not a Mobile App

#366
post #331

This has always been our philosophy with AutoTempest.com. We do pretty regularly get requests to build an app though, although none of the people asking for it have had an answer to the question, "What are you looking for from an app version that the website doesn't currently offer?" So, at least so far I've decided it makes more sense to focus resources on the website. I do occasionally wonder if I'm passing up on a…

Could it be as simple as an icon on the home screen and separate entry in app switcher?

We do have one of those notifications that shows people how to add the site to their home screen, so hopefully that catches most of that use case.

Re: Start with a Website, Not a Mobile App

#367
post #325

This has always been our philosophy with AutoTempest.com. We do pretty regularly get requests to build an app though, although none of the people asking for it have had an answer to the question, "What are you looking for from an app version that the website doesn't currently offer?" So, at least so far I've decided it makes more sense to focus resources on the website. I do occasionally wonder if I'm passing up on a…

As an aside — I would like to say that I really enjoy your website and the service! It has made shopping for a decent deal in my area a breeze. I'm curious about what kind of statistics you gather? It would be neat to track price movements across regions, and to see how the market trends for specific body styles and other characteristics during different time periods.

Thanks, glad it's helpful! So far we only keep statistics on searches, not on listings. We do plan to start that eventually, but so far there have always been more important things to work on. (Important in terms of having more of an impact on the core search experience.)

Re: Start with a Website, Not a Mobile App

#368

Earlier quoted context omitted.

> Think of it like this: If Hacker News required a fat client to function on your desktop, would you actually be here at all? HN essentially is a service that provides only a couple of text views to list and read submittions and their discussions, and requires zero processing or interaction. That's hardly a challenging problem that requires a fat client. If however we were discussing an application that required sign…

> That's hardly a challenging problem that requires a fat client. That's irrelevant. It doesn't matter that making a fat client for HN isn't necessary; that's completely beside the point. You're looking for reasons to ignore the stated premise of an analogy rather than accepting that the premise would be true. It's like this. Say you were beginning to explain how network services work with an anecdote: "Say you need…

> That's irrelevant. It doesn't matter that making a fat client for HN isn't necessary; that's completely beside the point.

If that's your take then you've completely missed the whole point. The functionalities made available to mobile applications are the reason why they exist. Developers don't work on mobile applications for the sake of working on mobile applications. They are paid to develop clients that take advantage of the features made available through a specific type of platform. Otherwise their customers wouldn't be spending their cash looking for specialized technical solutions.

> You're looking for reasons to ignore the stated premise of an analogy rather than accepting that the premise would be true.

The premise is patently false, and you're just complaining that others noticed the premise is false.

> It's like this. Say you were beginning to explain how network services work with an anecdote: "Say you need to go to the market to get a carton of milk." Suddenly your listener stops you and says, "But I don't like milk."

No, it's like you've missed the whole point along with all the reasons why your network service does not work, and instead of acknowledging all the holes in your reasoning you've decided to complain that someone found flaws.

Re: Start with a Website, Not a Mobile App

#369
post #284

Earlier quoted context omitted.

Why not just add the ability to list a PWA in the app store? At that point the installation is intentional and the overhead on Apple/Google is minimal... and Apple still gets their $99/year to allow making it easy to put your app's icon on a user's home screen.

On one hand I can see rational reasons for them not allowing it; Apple doesn't control when you push updates to your PWA, so they don't want to give their seal of approval by listing it in the app store. But on the other hand, it's pretty depressing to give up the dream of instant app updates, by wrapping your shiny PWA in Cordova and promising to never execute external JavaScript.

Pushing updates without going through the app store has been allowed by Apple as long as the assets being updated are not binary code; specifically CSS, HTML, and JavaScript are okay (I wonder whether WebAssembly will be considered "binary" or not... will be interesting to see). I convinced a former employer to abandon their Xamarin-built app and switch to Ionic (Cordova with nice, fancy UI additions) specifically because they could push updates to the app without going through the app store. Officially (unless things changed?) the Google Play store says this isn't allowed but there is no review process with Google Play so publishing a new app and then pushing an update for the previous version won't likely get you in trouble. If someone HAS been busted by the Google Play cops for this it would be news to me.

Re: Start with a Website, Not a Mobile App

#370

Earlier quoted context omitted.

Yes. I don't give them permission to run code on my device arbitrarily and perpetually. Think of it like this: If Hacker News required a fat client to function on your desktop, would you actually be here at all?

> Think of it like this: If Hacker News required a fat client to function on your desktop, would you actually be here at all? HN essentially is a service that provides only a couple of text views to list and read submittions and their discussions, and requires zero processing or interaction. That's hardly a challenging problem that requires a fat client. If however we were discussing an application that required sign…

On mobile, you don't use a fat client for HN? I've even paid money for an app (MiniHack) to have a nicer experience on mobile.
Post reply on HN