9 ms·
Here's the thing. Apple, Google, etc are trying to lock developers into specific platforms. This is why Apple has been so hostile towards PWAs. It's totally p
by burtonator 6y ago
Here's the thing. Apple, Google, etc are trying to lock developers into specific platforms.
This is why Apple has been so hostile towards PWAs.
It's totally possible to build a PWA that behaves like a native app but Apple actively tries to destroy them.
There will never be a viable hybrid app platform.
- athenot 6y ago> It's totally possible to build a PWA that behaves like a native app but Apple actively tries to destroy them. It may look the part but it rarely feels like it. Something like OmniGraffle would not end up feeling the same. Even Microsoft's apps on mac feel better than their web-based counterparts in O365.
- giantDinosaur 6y agoOmniGraffle could be fine; hasn't Figma shown us the way?
- durandal1 6y agoFigma falls into the trap of all other claimed high performing web apps, conflating maintaining a 60fps refresh rate with responsiveness. Try dragging any object around (even simple shapes) and you'll see it trail the mouse cursor in Figma. Does not happen in OmniGraffle. The result is a distinct difference in feel.
- lucasverra 6y agoCan any person in the planet edit the same document than you in real time, for free, running hardware up to 5 to 10 years old, in < 3 min after receiving a link with Omnigraff ? Because that is the main feature of figma. Latency of mouse issues is a good trade off from my POV.
- giantDinosaur 6y agoFair point! I might file this under 'latency' which is often ignored for improvement so long as it's tolerable.
- wtallis 6y agoYeah, proponents of cross-platform frameworks love to ignore the second half of "look and feel". It's ridiculous to claim that a web app can behave like a native app when even Qt apps still tend to have obvious tells.
- Silhouette 6y agoThe important question is, does that matter? Slick web apps are taking over the software world, whether the likes of Apple want them to or not. Looking like any specific native platform is less important, if it's even relevant at all, in an era when users are working with different web apps each with their own look-and-feel all the time anyway.
- wtallis 6y agoDoes it matter? Yes, of course. The desire for consistency and usability may not be strong enough to reverse the current trend away from native apps, but that doesn't remove their advantages. And I find it very telling that even your own comment continues the trend of over-emphasizing look over feel. I'd be happy with apps randomly launching in night mode, if they would just have all the right controls in the right places, and have the performance and memory footprint of native apps.
- Silhouette 6y agoThe problem with that argument is that you're assuming consistency with native platform standards is the dominant consideration. I contend that, today, it often is not. Many users are spending much of their time using web sites and applications rather than native ones; this trend does not appear to be in dispute here. Moreover, the basics of how web sites (and by extension web apps) work have a longer history of established conventions than any of the major native platforms; the likes of Jakob Nielsen were making the case for consistency and following user expectations more than two decades ago, long before the likes of iOS and Android and whatever we're calling Windows' UI today were glints in their respective creators' eyes. Also, web technologies can perform just fine the vast majority of the time. Modern JS engines have excellent performance, obviously not rivalling expertly coded C and assembly, but certainly comparable to your average native application for most purposes. Modern browsers also have good support for hardware acceleration and can render UIs that respond quickly enough to user interactions that again for most purposes there is no perceptible delay or jank. Today we're looking towards WebAssembly as a vehicle for potentially more efficient languages and runtimes, though clearly that technology is still in its infancy and its future is far from certain. Now, you can undermine all of that potential if you bloat your web site/app with tens of megabytes of junk scripts that are all competing for resources and blocking stuff and phoning home and whatever, but that's not really the fault of the web technologies, it's just bad developers and/or bad managers creating a bad application.
- jiofih 6y agoYou should try Figma. Will open your eyes a bit.
- wdb 6y agoYeah, you can only use it when you got internet
- osrec 6y agoI think that can often be due to a lack implementation skill. Our users (https://usebx.com https://usebx.com) seem to appreciate the native performance and feel of our web app.
- emodendroket 6y agoThe fact you can just run it without installing anything makes up for a lot of faults (doubly so when the vendor isn't Microsoft but somebody nobody's ever heard of).
- wtallis 6y agoOn the flip side, most web apps don't offer their full feature set without requiring you to go through a sign-up process that is at least as onerous as downloading and unzipping a Mac app bundle. Even when a web app outsources authentication to something like Facebook, there are still at least as many clicks.
- emodendroket 6y agoIt's not about clicks so much as sandboxing.
- pseudalopex 6y agoMac apps are sandboxed.
- emodendroket 6y agoI'd nevertheless sooner visit an unknown Web site than install an unknown application.
- kgin 6y agoIt easily could feel like it, given a very reasonable amount of support by platform owners. There is nothing magical about Ui powered by compiled vs interpreted code. It is limitations in the platforms that are the roadblocks.
- leadingthenet 6y agoI always hear about these theoretical web apps that are just as good, nay, better, than native apps. Where are they?! Certainly no web app I ever used would qualify...
- Razengan 6y ago> It's totally possible to build a PWA that behaves like a native app but Apple actively tries to destroy them. Ugh, no. No it's not. At least not yet. Accessibility features alone are almost always woefully crap in web-apps, compared to what native apps have access to, at least on macOS (and SwiftUI is amazing in how it lowers the barriers in implementing accessibility in your app from the get-go.) Shit like Electron and PWAs seem to be championed by user-hostile developers that just want things to be easy for themselves, without considering what's best for the users and their hardware resources.
- candiddevmike 6y agoYou really think accessibility for native apps will always be better than a web app that follows a11y?
- someUserTonight 6y agoI think so. If we're talking about "out of the box" or what you'd find on average. As an Android dev for a few years now I think we get a lot out of the box and I get that web devs also use libraries or frameworks that have similar benefits. At that point it's comparing framework A's a11y vs framework B's a11y vs Android a11y. Not an Android fanboy but I'm going to assume that the bigger (widely used/constantly iterating) "platform" (for a lack of a better term) has better a11y. And if there is a web framework that provides this (react?) do the majority of websites use it ? like they do native api's for native apps (and this isn't even talking about the api's accessible to native vs web app)
- Silhouette 6y agoShit like Electron and PWAs seem to be championed by user-hostile developers that just want things to be easy for themselves, without considering what's best for the users and their hardware resources. There is a standard counter to that argument at this point. Developers on native platforms might be able to achieve a better experience on that platform than a web app given the same time and resources. However, if the time and resources have to be split N ways to build a native app on each of N platforms, compared to investing everything into polishing a single web application, the outcome might be very different. While each native developer is still worrying about whether they're aligning and labelling a button in the platform-standard way, the web team is already refining their UI using the results of their third round of usability testing and has determined that the button shouldn't have been there in the first place and designed and implemented a more intuitive UI. And since they launched their version 1 two months earlier than any of the native apps did, they even have the extra revenue in the bank to pay for those usability tests, too.
- choathedolls 6y agoIsn't that curious then, that Apple is forcing some developers to turn to web-based solutions [1,2] instead of encouraging them to actually create native locked in experiences? Seems to me that there's less of a "apple is purposefully malicious towards PWA because of their master plan for platform lock" and more of a "apple has a very long history with being completely incompetent on the web (see: icloud as a whole, safari now slowing standards adoption, newer web endeavors like the apple music app) which in turn is slowing PWA adoption because they now own one of the most dominant mobile platforms. [1] https://www.businessinsider.com/microsoft-xbox-game-pass-apple-iphone-ipad-2020-10 https://www.businessinsider.com/microsoft-xbox-game-pass-app... [2] https://www.theverge.com/2020/9/25/21455343/amazon-luna-apple-app-store-rules-cloud-gaming-streaming-google-nvidia https://www.theverge.com/2020/9/25/21455343/amazon-luna-appl...
- jjtheblunt 6y agoAre you suggesting Javascript has access to all hardware functionality exposed to C/ObjC/Swift?
- impassionedrule 6y agoI've heard of Ionic/Cordova which gives JS apps the ability to access native APIs, but haven't used it to see if it's truly capable of all functionality
- SquareWheel 6y agoWith a proper permission system in place, sure. Desktop apps got the permission model all wrong. You run a program and that grants them access to everything. The web's model is closer to that of mobile apps. It asks for a permission at the time that it's needed. Not all sites get this right, but browsers are starting to crack down on requests the moment you enter a site.
- fastball 6y agoDoesn't really pass the smell test. Google is developing cross-platform Dart/Flutter. Apple is developing cross-platform Swift/SwiftUI. Facebook made React and then cross-platform React Native.
- russli1993 6y agoApple is definitely not developing cross platform. Swift the language is cross platform. But the SwiftUI is only "cross platform" within apple's different devices. A true cross platform is when a SwiftUI app would work on Android. Native OSs can be built to be "cross platform". For example, the OpenGL API. The same API works on different OSs, developers can code against the same API and it works on different OSs. In an ideal world, maybe there could be a standard API for presentation controls, UI drawing, animation, 2D/3D graphics, networking, filesystem access, threading and more. Each OSs would implement the same API and add additional platform specific APIs to differentiate themselves. The key is application developers would have a common core set of APIs and language to implement the 80% business logic and UI logic. Note, this is essentially what HTML, JS and CSS is doing. But the web platform is creating a runtime that exposes APIs to do a lot of different things. A CSS transform a single API that causes the DOM to animate in specific way. There are thousands of these APIs, and the runtime implements all of them. This is why the web runtime itself heavier and it takes 100mb just to show something simple on web platform. For flutter, the core engine is just a 2D drawing surface, the APIs it exposes is just drawing shapes. And all of the widget self contains rendering, various settings and the application pulls in the widget used in the app. This makes the runtime smaller. Flutter is more efficient because the abstraction is lower and the core runtime is trying to do less things. On the scale of level of abstraction, flutter is on one end and the web platform is on the other. For our ideal OS platform, we can select the right level of abstraction to balance between performance, standardization, and flexibility. But in the real world, all of this require collaboration between OS vendors. Apple's business model is try to sell more IPhone, Mac, Apple Watch, IPad. They make the argument that Apple's platform has the best apps that isn't available on Google's or Microsoft's platform. And this actually works. Why is Android tablets not taking off, and IPad Pro is? People buy the IPad Pro for apps like Notability, Photoshop and more. People still buys Windows and not ChromeOS because its got native Photoshop and Matlab. These apps are coded using Apple's or Micosoft's language, frameworks and APIs. And that exactly is what is preventing these apps from appearing on Android and ChromeOS easily and reducing people's need to buy Apple and Microsoft's devices. While these vendors may not say they are actively trying to lock in developers. They definitely don't want the some developers who coded an complex application for their platform to easily move it to another platform. If this transition cost is too low, it doesn't play into their business model. Their business model pushes them to differentiate their platform against others, and as a side effect, it increases the barrier and transition cost. This is a tug of war between application developers desire to have all platform as similar as possible, and the platform owners desire to differentiate their platform and prevent other platforms obtaining the same capabilities as my platform.
- intellix 6y agoThis is why Apple should be forced to allow multiple web browser rendering engines on iPhone. Cause they're so damn anti-competitive and being forced to develop for Safari makes developing web apps horrible
- barnaclejive 6y agoIf it were so easy, why is Postman pure garbage compared to Paw on mac?
- pjmlp 6y agoThere are many local markets across the globe where Apple devices are irrelevant, so trying to block PWAs won't work as much as they would like to.