Browsers, not apps, are the future of mobile
blog.intercom.com
blog.intercom.com
This is getting worse and worse though as browsers expose more and more of their host operating system's functionality. The benefits of using a website instead of a native app are quickly disappearing, while the drawbacks have only been somewhat mitigated. We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have eventually become an OS with many fine features - simply lacking a good web browser. For the privacy conscious user, modern web technologies will undermine you every step of the way, or simply break if you choose to stand your ground.
I personally would rather have a dozen well crafted battery sipping native C apps than a million awful contraptions built in a script interpreter on to of a VM by the lowest bidder on ODesk. Sure it's harder to do it right, but that's the cost of quality. Maybe I'm stuck in the 80's, but to me, it seems like a lot of wisdom has been shrugged off in the pursuit of expedience.
Maybe there needs to be a more curated App Store that carries only the best applications?
The iOS App Store isn't perfect in this regard, but it's miles ahead of Google Play, which doesn't seem to have any standards at all.
But yes, Google still gets everything .
Use webapps, a browser to sandbox better websites.
Phone is marvelous now.
To that end, in recent months, I've found myself deleting about half of the mobile apps I'd downloaded over the years, and shifting to using the firm's browser interface whenever possible.
If it's so "garbage" then maybe don't install that app or visit that site?
But people want the content, but not what pays for it (and also don't want to directly pay for it -- not in any sustainable numbers).
It really sucks for the honest developers, but as a result, I'm more comfortable using my browser to interact with dynamic content (like HN, Reddit, etc) while reserving local app installs to an extremely limited set of functions which need to operate on my local data where having both contact and networking permissions are a huge red flag.
This is all due to the interface though. Mozilla is a much more neutral party then Google. I'd rather untrusted third parties negotiate with Mozilla's API than Google's. What I'd like even more is good native software which treats users with dignity and respect, but those are few and far between on Android.
Sorry, but what "race to the bottom"? There are 1.5 millions apps in the iOS App Store. Inevitably a lot of them will be bad. But there are thousands of great apps at any price range.
It is not up to you to decide what is legitimate.
Battery sipping native C apps? Mobile browser-based SPAs are worse battery sipping offenders than native apps.
At least the native C apps don't run 2-3 extra levels of indirection AND the most inefficient GUI stack to top.
WebAssembly might indeed solve this...
Perhaps check out the new permission model, which requests permissions at runtime, instead of upfront.
And about ads, more and more iOS apps are starting it too, i thought ( don't have iOS, read it from multiple sources)
Perhaps I'm just spoiled by the excellent quality software I get for free on my Gentoo/Debian workstation. I just refuse to accept that because my phone fits in my pocket, the standards should be so much lower. I miss my n900 dammit. :/
Apart from performance-intensive apps/services like Netflix or Twitch, even things like Linkedin I find more engaging on a tablet/phone.
The app feels more responsive, the design does not have the same constraints as when designing for a browser.
But I really don't see the need of seeing it as a dichotomy, as a "there will be only one" thing.
The convenience/ubiquity/versatility of a browser is hard to match.
Just like the browser didn't kill desktop applications, native apps won't kill the browser.
I have an app that pays for parking in my city. It's pretty decent and I'm happy with it. If I go to another city once in a while, I'm likely not going to download a different app to pay for parking there. Or if I visit a furniture store for something once, I really don't want their app. And so on.
This mirrors my experience. I derive all the value I'm looking for from my personal and work mobile devices (yes I like to keep them separate) with less than five apps beyond the vendor+carrier distribution on each.
This is particularly true for my work device, which is a BlackBerry Z30. There aren't many apps available for this environment so the browser is the primary point of mobile interaction.
Your point regarding browsers becoming a modern Emacs is a concern and a good expression of the issue. I'm not sure what to do about this - I can only pick and choose a browser where options are available and look to configure it to my advantage. Any suggestions?
Amusingly enough, you just described how apps worked on my first mobile device - a Windows CE PDA. There weren't a lot of free programs available, but the ones I could find were very well-designed.
But it's also the Last New Frontier, because as the comScore charts show, most people spend their time in the top 3 apps -- which are probably the same or come out of the same pool of half a dozen. So the only way to push one's own content is to participate in a popular app maker's content ecosystem (FB Instant Articles, Snapchat Discover, myriad chatbot platforms for various messengers), or participate in a "open web" 'discovery' ecosystem (Google Search -> Google AMP).
So really the article's content seems to imply that the future isn't browsers (in the traditional sense of 'here's a user agent you can navigate to arbitrary URLs') after all, it's content aggregators who provide windows to -- and framing around -- content. This point has been made a few times before, most notably by Paul Kinlan of Google [1], so it's a pretty safe bet it's actually the case.
But the article isn't talking about packaged web apps, it's talking about browsers, and has an interesting redefinition of that term.
It's simple, when you want to do X, you want to do X, you don't want to do a lot of setup work before you start doing X.
Also, I feel like after installing an app, it takes more time to get to the actual content, because every app has a few screens of "Welcome to Foo! Here's how you do stuff in here." Websites are pretty instant compared to that.
Open browser, create new tab or focus url, enter url
Open app store, search for app name, click on the one that seems correct, read reviews, click install, wait for installation to finish, open new app.
This of course is only valid for the trying a new application or website which hypothetically is 0.001% of your usage of an app.
Click install. Review and approve permissions. Wait for some ungodly amount of megabytes to download. Wait for installation. Then open. Then approve some new permissions. Splash screen. Woo, content! But I'm not "deep linked" to the place I need to be.
Or, for a website: I'm just there.
How is this fixed by a web app you have to remember the address for, or at best, remember where on your favorites you saved it?
They kinda have in 2 ways - as of iOS 9 or 10 your app can utilize login credentials from your web domain name if certain requirements are met, and there's touchID for instant login after the first authentication.
I think merged storage is either here in the latest version of android or coming which will hopefully let us stop worrying about storage again but many devices will sadly never see the update.
If you see an ad or pop-up article about an app, what are the chances you install it, even if it looks interesting?
I click on links more than I install apps because loading web pages is a lot faster than installing apps. The flip side is that I hardly ever return to those "interesting links," while I use my installed apps frequently.
I would re-evaluate that stance if I were you: http://www.wired.co.uk/article/xcode-apple-app-store-hack. Hundreds of apps injected with malware by a compromised version of Xcode made it through the App Store review process.
Apple already tried that approach with the iPhone one. It failed because the technology wasn't mature, but there have been nothing but advances since then.
The web is a more flexible and portable platform, so the economic incentives will always be there. And while native toolkits are still based on 1970's lab research, the web as a platform benefits from mainstream usage by the whole world. At some point, the new tech will overcome and replace the old approach. The gap is getting smaller every day even if the old approach has decades of advantage, and all major tech providers are pushing for it.
Is there any active project you can link to regarding this?
If WebAssembly does a good job of exposing features needed for high-performance code, it could become feasible to move everything to WebAssembly and ditch support for native code on both platforms.
Edit: I should clarify that for certain types of apps WebAssembly might be relevant but the discussion seemed to be out UI layer and I don't understand how WebAssembly fills a gap that a native API in JS could also provide along with the same challenges.
A good example is games. Some do manage to use Java, but it's mostly a hindrance; being able to compile languages with a C style ontology to a platform-independent and efficient VM would be very helpful here.
Is your prediction that companies will start compiling their UI toolkits for browsers?
In fact if I had the opportunity to buy a webOS device today I would ditch Android in a hot minute...
If it's more convenient to Google and Apple, they'll push for it, and we can only adapt.
But don't expect developers to ask for it. As it happens with those things, each platform will have their own, incompatible toolkits, and programming for them will not be much different than native programming.
Security and usability are inversely proportional and the browser needs that security more than anything else.
That being said, it's great to see the innovation in the web space. But it will always be limited to specific application domains and the standards move slowly
Ubiquity >>>>> UX.
Problem is, imo, that so much of the web assumes a mouse and keyboard. I keep running into "mobile" sites that are so crammed with links and other tap targets that i have no chance to hit the right one on first try with consistency.
Content is King
I just keep hearing posts about how the mobile web is so clearly superior to apps and it never tallies with the reality on the ground for me.
I still use Thunderbird.
Mobile is already maturing. By the time web technology is good enough to create a native-feeling experience, we will be on to the next runtime.
(Disclaimer: I do iOS consulting, so hugely biased)
If a site is plaintext and has minimal JS, it's usually fine on a mobile device.
But the moment there are interactive elements or menus or web fonts or whatever else, things are visibly broken, or they become broken once you start scrolling. Even relatively inoffensive websites with simple menubars have stuttering scrolling animation.
Any decent native app doesn't animate that poorly. I'm an iOS user because design and UX are clearly valued by (non-shovelware) iOS developers. Having buttons jump around the screen or some weird JS stealing scrolling momentum would be unacceptable if it were in an app, but I visit at least one popular website a day where that's one of the problems.
View source.
Standards.
Cross-platform.
Service workers etc add a lot of features to the web platform in this regard, but it doesn't seem fully solved yet.
How can I, as a user, ensure apps I use in the browser are available? If I want to use an app, I'd hate if the browser had cleared it (or worse, content edited offline that hasn't synced yet) from its caches since it decided it needed space. I haven't seen a clear way to "pin" an app's data in a browser UI yet.
(Of course there are tons of native apps that don't work offline as well, but I believe I can more reliably test that.)
You can smell the city on the authors of these thinkpieces.
At 15.99€ a month for 50GB (free, but reduced speed after that) too.
Providers tell the whole city is covered by 4g. In reality, as soon as you move, sometime you'll have it, sometime you won't. Friends report the same thing in other cities with other providers.
Plus there are data caps on most people's plans IME.
Of course, out of the European countries, our Internet is in the Top 5 at least, if not dare I say it, the best I've seen.
So don't make the mistake to think that progress ends at the borders of San Francisco ;-)
There's no 4G to speak of, you count yourself lucky to get 3G. And it's not just mobile, the Internet you get in hotels is so piss poor it's infuriating.
1. People aren't downloading apps because they have most of the core apps they want/need currently, not because they're browsing the web instead. Look around on any college or high school campus. Barely anyone has mobile safari open. They have instagram, snapchat, a messaging app, and maybe Facebook open.
2. Bots are the future? We'll see. Nobody besides tech people seem to care about bots. I'm in tech and I don't even care about bots - yet. And again, look at today's high schoolers and college students - they don't care about bots.
I believe you are misinformed about this one. Not only is mobile Safari open, but it's open with a bunch of tabs.
If I need to search some definition of a word, some image or whatever I'll use Safari.
Not saying it isn't great, I love to have a browser on my phone - I just don't actually like to use it. Just opening Safari now (it wasn't even in my app switcher list) I see a few categories: image searches, movie searches, definitions, "automatically opened via some app" and Facebook (that time when I uninstalled the app for some dev-testing and forgot to install it again).
Do you think I am correct in saying that Safari is used as a last resort?
And I guess I'm weird because of my tech background, but I absolutely hate apps which present web content in their own browsers instead of my browser of choice.
It's also a pain because of all the different standards a developer needs to support.
On device storage of secrets or valuable private data is a key part of most "real" apps. Apps that do not need this may benefit from quickly improving web technologies. Apps that need this may prosper more on a security conscious platform.
A major factor that pushed users away from Windows and towards webapps was the constant onslaught of viruses and worms. It got so bad that when I was in college (early 2000s), SQL Slammer would be perpetually floating around the college network (I noticed at least 4-5 computers infected in my dorm of 22 residents), and a significant portion of peoples' fileshares were infected with Nimda. The assumption was that if you had ever logged into a computer in administrator mode (and oftentimes, even if you hadn't), it was compromised.
And then desktop e-mail clients died under the onslaught of spam. GMail's spam filters basically saved e-mail (temporarily at least; people hate it again), and they could only be done on the server, with data from lots of people.
Then a major factor in the shift from web to mobile was the huge weight of advertising, clickbait, phishing, and other abuse. Webpages got so heavy and bloated that the clean, fast interface of a mobile app was a huge breath of fresh air.
Now we've got mobile, dying under the weight of apps that request every privilege under the sun so they can do things they shouldn't be able to. And Google, dying under the weight of SEO & content farms.
It's like the tech industry periodically gets reborn because as soon as something gets popular, people swoop in to abuse it, until it's easier to kill the patient and start over with a new platform than to clean up the mess. Full employment for entrepreneurs, I guess.
I had a low-end smartphone for the longest time where I had to fight for every byte on there. After installing Messenger & Instagram, I had less than 1gb left thanks to uninstallable bloatware (there was no safe way to root it). And the Play Store doesn't let you install apps/updates when you're near 300mb or so. My friends with iPhones/Nexus devices that don't sport an SD slot have also shared these sentiments, though most just need to learn how to offload their photos/videos to the cloud. Regardless, not having to install anything is a pretty shweet bonus.
Then you can grade how progressive your app is by running https://github.com/GoogleChrome/lighthouse
Push notifications still aren't widely supported, sadly. https://developer.mozilla.org/en-US/docs/Web/API/Push_API
There's quite a sizable fence you have to jump to get into progressive web app development. They have to serve over https, localStorage & service workers can be a pain, and there's a lot of fallbacks to implement for unsupported browsers (I'm looking at you, Safari!).
There's also a great write-up on all that went into making pokedex.org http://www.pocketjavascript.com/blog/2015/11/23/introducing-...
If you already do web dev, then learning service workers + local storage won't add much difficulty. Plus, they're excellent tools to add to your toolbelt that your future projects could benefit from. And you'd be encouraging Apple to step up the game with their IE- I mean Safari.
There is always someone bragging how some recent development made webapps even slickier and better performing than native ones, and every time I try it out, I'm hugely disappointed by a sluggish mess that barely manages to get most portions of native look-and-feel right.
Same applies when a "native" app uses an HTML/CSS renderer for its UI. For some reason I usually notice it. Well, at least it has some OS integration that way...
Not to say about the value of having an old version (does not apply to apps that are mere remote API adapters, but it's not like every app is like that).
So, I believe it's highly unlikely, no matter how many times this "webapp is the future" mantra is repeated.
Since users aren't always extremely excited to install an app for your new product or service unless it is going to be something they use every day, it makes sense to consider carefully whether everyone might be better served with a mobile website.
One of the first problems I encountered was keeping the screen on. It's not possible in the browser. (Well, there's a workaround with a looping hidden video, but that's crazy.) Which means that people need to keep tapping the screen to keep it awake while playing. Super lame.
And of course, offline is possible in the browser, but clearing your cache for some reason, or just having it get stale, is brutal on that.
I tend to want to make browser-based apps, but it doesn't work out for anything that isn't always-online and pretty simple.
That's not a legitimate redefining of the term "browser", just a convenient (and poor) definition that makes the author's argument (falsely) appear more sound.
Yeah, you guys (who, exactly?) keep saying that, and it keeps walking further away from the truth, no matter the pressure (from whom, exactly?) to make the World swallow it.
Everytime this subject comes to light I can only picture one technology in my mind: Java Applets.
People who talk down app always site that most people regularly use 3-4 apps. But then most people (not the ones on this site) probably regularly only visit 3-4 web pages.
Link?
Conceptually they're not very different from IRC bots except for having natural language processing rather than simple regex/command capabilities.
Chat bots are associated with text, but Google Assistant and Siri are basically chat bots plugged into voice recognition and text-to-speech interfaces.
Bots on Telegram can send and receive messages to you or a group.
My most used bot is one who watches HN for breaking stories and send me a link to the story and the comments.
Net result:
Spend less time checking HN, confident that I'll see 100+ story even if they die before I take lunch or have to wait for something anyway.
BTW: 100 is just an example threshold, you can send a message to the bot to set that to something else.
I remember hearing about / reading about (here? on reddit? at a meetup? who knows) that the Chrome browser on android is going to begin implementing features that allow "psuedo-apps" to be developed. A browser favorite exists on the homepage and has a fat cache to save bandwidth, but isn't an app in the sense it can run in the background. I don't know too much about that, but what I DO know about are cool firefox and chrome Javascript methods like window.getDeviceOrientation or sendVibration or getLightLevel and other experimental features obviously focused on mobile devices.
Just for fun I am going to say by 'the future' I mean fully 10-20 years from now.
The Google Assistant or intelligent/connected chatbot/agent will be in your brain (or maybe somehow just spying on subvocalization nerves/muscle twitches). You will have a brain computer interface (or something) that you use as naturally as breathing or thinking. This will also effectively give everyone telepathic and telekinetic powers.
Installing an app will be like with Amazon Alexa, giving you additional commands/AI capabilities.
Glasses and maybe contact lenses will use eye tracking and transparent OLED microdisplays to augment reality. The phone/BCI is tiny or mainly just a fast wireless transceiver to nearby distributed localized computing clouds.
Smart phones and apps will be for poor people.
Contrast with Lululemon's mobile app, which is an absolute delight to use. I don't buy the authors thesis at all.
Opinions we will have always.
It is true that companies like Patagonia don't need a native app. In fact, most native apps from large media companies and brands are unnecessary.
However, I also think the "native app" form factor has not been explored to its full potential. There are definitely a lot of benefits to apps being native, and they're not what most people think.
One of the most under-appreciated reason is that you have a dedicated icon you can press to enter a new world. This works both ways, because in the current world we live in, people don't want a "dedicated icon" for every single brand they engage with. But this is where my point starts:
People use bookmarks because they want to easily access things they frequently use. The problem is, the appstore is filled with apps that people don't use frequently enough and don't care enough about. We are forced to "bookmark" every single app we download. That's why people don't like clogging up their "bookmark screen" and end up deleting apps.
On the other hand, I think there are tons of potential apps that are NOT being built, that I would be happy to keep on my home screen if they existed. For example, let's say I visit a certain indie coffee shop every day. I would download their app if they had an app that makes my life easier. For example they could have a Starbucks-like app where I can order stuff easily without staying lining up. Also, I would download an app that's super customized for a community I am very attached to.
Then why don't we have these apps in real life? The problem is these organizations and small coffee shops and our small interest groups don't have time and money to build these apps. And not even considering time and money, they just don't want to bother since they have a lot on their hands already.
I think, once we make it extremely easy to build an app (and I'm not even talking about all the "app builders" out there. It should be as easy as copy and pasting MySpace scripts), we will have more useful and personal apps that people would actually want to keep on their screen, just like a bookmark. We are just not there yet.
I've been working on a project that's along this line of thought. It's basically a native app meets browser, where you can send an entire app over HTTP (just like websites), but it translates into 100% native components and native function calls. If you're interested check it out here: https://github.com/Jasonette/JASONETTE-iOS Would love to hear thoughts in the current thread context.
Hopefully WASM will fix the performance issue and the internet speed will get fast enough to compile and serve mature frameworks such Cocoa.
https://github.com/WebAssembly/design/blob/master/NonWeb.md
That doesn't mention HTML but focuses on avoiding JS entirely, so presumably there'd be some more direct way to invoke the program (but don't take my word for it ;) )