Live data from Hacker News

Start with a Website, Not a Mobile App

atrium.co

81–90 of 587 posts

Re: Start with a Website, Not a Mobile App

#81
post #65

"No one wants to download apps anymore" I stopped reading there. The major advantage of the App Store (primarily for consumer apps though) is the fact that there's some kind of filtering at place. If I find a quality app, I want to actually pay for it. In fact, if it's a good app - then I prefer to pay, as it often ensures some kind of continuity in the app's lifecycle.

the way you use your phone is different than others though. in the non-tech world people use less than 10 apps, email, social media, messenger, and maybe an investment portfolio

I remember trying to get people to download an app I made in college and it was pretty hard, even when the app would show up #1 in the app store results after searching the name. Website would have been smarter, but an email list serv would have been the best bet to get that strong user base.

Once you have the user base, then publish the mobile app. I just don't recommend starting out with it until you've proven the concept and have loyal users

Re: Start with a Website, Not a Mobile App

#82
post #59

Earlier quoted context omitted.

To me, you have to have a really damn good reason to start with an app. Distribution is hell.

how so? click a button and download to device? now you have an icon that the user sees every day. How is the web better than that?

Are you saying you download more apps than you visit websites? I highly doubt it.

Re: Start with a Website, Not a Mobile App

#83
post #65

"No one wants to download apps anymore" I stopped reading there. The major advantage of the App Store (primarily for consumer apps though) is the fact that there's some kind of filtering at place. If I find a quality app, I want to actually pay for it. In fact, if it's a good app - then I prefer to pay, as it often ensures some kind of continuity in the app's lifecycle.

> If I find a quality app

That's a big If. You're also under the assumption that the App is able to do something that cannot be done via a website. The sell is that the App offers a better experience to the user, often (e.g. reddit) that's only because they've nerfed the mobile website intentionally. The truth however is that an installed App gives them more opportunities to monetize you.

Whenever someone says to me "you should check out " I visit the website, if that website doesn't work on the desktop or directs me to download an App then I close the tab and forget it ever existed.

Re: Start with a Website, Not a Mobile App

#84
post #2

Given the fact that most people are already maxed out on apps on their device with just things like facebook and youtube, you're going to be hard pressed to get people to install your app just to try it out. With a progressive web app if they like your app they can add it to their device home screen without installing via the app store and without using up space on their device. Also don't need to pay Apple $100 a ye…

> With a progressive web app if they like your app they can add it to their device home screen Does anyone even know they can do that? I've never seen anyone do it "in the wild". Would love to see any stats around usage of pwa's added to home screen.

I have a HN bookmark/icon on my home screen.

Re: Start with a Website, Not a Mobile App

#85
post #59

Earlier quoted context omitted.

To me, you have to have a really damn good reason to start with an app. Distribution is hell.

how so? click a button and download to device? now you have an icon that the user sees every day. How is the web better than that?

there's a big difference between typing a URL into a web browser & downloading an app:

1. go to the app store 2. search for it and find the right one 3. make sure you have the right amount of space for it 4. download it 5. place it on the 5th screen of your phone 6. never see it

Re: Start with a Website, Not a Mobile App

#86
post #76
post #61

Earlier quoted context omitted.

I don't think that's really true, because Apple has strengthened PWAs in a lot of ways in recent iOS releases. I personally suspect it has a lot to do with waking up a service worker outside of the browser lifecycle - given how aggressively iOS monitors apps no longer running in foreground I can imagine that being quite a hurdle to overcome (without compromising the reason for doing it in the first place).

> I personally suspect it has a lot to do with waking up a service worker outside of the browser lifecycle - given how aggressively iOS monitors apps no longer running in foreground I can imagine that being quite a hurdle to overcome (without compromising the reason for doing it in the first place). I don't think this is true. Please correct me if I am wrong but there are ways to handle the scenario. Apple could crea…

> In addition, it could say something like your worker can only run in the background if a user has been to your site in the last n hours

But iOS apps can't do that. The only way they can guarantee background execution is if they are playing audio, or say they're a VOIP app. Of course, Apple could change those rules for Safari, but what I'm saying is that I don't think it's as simple as just flipping a switch - it'll need OS level changes, which will slow things down a lot compared to stuff like offline caching, which the Safari team can implement themselves.

There's also a fundamental difference between iOS notifications and Web Push ones - the notification is already created in the iOS payload. So it doesn't need to wake the app up at all, it just shows the notification. That's not possible with Web Push, so it's a change compared to how iOS handles every other notification.

Re: Start with a Website, Not a Mobile App

#87
post #18
post #10

Earlier quoted context omitted.

On iOS you won’t get notifications or be able to run anything in the background. Ok, but what are the downsides?

As a user notifications are a problem, but as an app developer they absolutely work to drive engagement, which is why so many apps use them. So if you’re trying to run a business that’s a pretty important thing.

Notification management is the problem. Not notifications themselves.

One part is on the system to provide the right management tools, the other is on the user to tell the system what notifications are important.

Re: Start with a Website, Not a Mobile App

#88
post #68

Earlier quoted context omitted.

This is wishful thinking with no logical argument behind it. WebAssembly replaces JavaScript but the rest of the experience (a web browser) is exactly the same. What would compel users to care?

> This is wishful thinking with no logical argument behind it. 1. A web app developed using WebAssembly offers performance indistinguishable from that of a native app. 2. Since the web app offers native performance, there's practically no need for a native app to exist in the first place. Why should developers waste their time developing for multiple platforms when a single mobile app works flawlessly? 3. This is gre…

> A web app developed using WebAssembly offers performance indistinguishable from that of a native app.

If the performance of your app is limited by the DOM, this will make no difference. Most applications are not doing heavily calculations, they're animating an non-native HTML UI so WebAssembly will make no difference. Raw calculation performance is not the biggest issue for mobile apps.

> Why should developers waste their time developing for multiple platforms when a single mobile app works flawlessly?

Nothing about WebAssembly will make web apps work "more flawlessly" than web apps work right now.

Since WebAssembly doesn't change the user experience of acquiring and using applications it will make no difference, from today, on adoption on web applications.

I'd go so far as to say that users actually don't like going into Mobile Safari run mobile applications and WebAssembly isn't going to change that.

Post reply on HN