You wouldn’t be able to see that debug information on the phone itself if it wasn’t jailbroken, as the GP mentioned you would need to use console on a Mac. The second screenshot is from a phone, ergo, jailbreak.
Also other commenters have mentioned he’s on 15.4.1. That’s two major iOS versions old. It’s possible they’re just on an iPhone 6S/SE/7 which was capped at that version, but a jailbreak is likely.
You talk like a jailbreak is some "dangerous and system-destroying action".
The fact that a jailbreak is even needed to actually get full ownership of your device that's "sold" is laughable. And we have people fighting and demeaning people for demanding the full rights to devices they supposedly own?
Apple fraudulently "sells" rentals as if they were a purchase.
Jailbreaking is a dangerous action... you're running unsupported, privileged software, that inherently takes advantage of an existing flaw in the system. That's not a judgement, I ran jailbroken phones myself for years and years. It's just the facts.
The parent posts didn't seem judgmental of jailbreaking at all.
iOS & tvOS support any controller that can appear as an Xinput Xbox Controller, PS4/PS5 controller, or Switch Pro controller. 8BitDo just doesn’t call out this compatibility for some reason.
You should try the 8BitDo Zero 2, should fit your needs. This also might work in one of those modes. I’d just buy it on Amazon so you can return it easily if it doesn’t.
Windows 7 and Windows 10 had very similar minimum hardware requirements, and few if any artificial restrictions on what hardware is supported. Same with Windows XP when moving to Windows 7. Technology was also much faster moving and new significant features that benefited from hardware improvements were being introduced all the time.
Now the focus is on efficiency and power consumption. As a result, any computer made in the last 10-12 years will be perfectly suitable for what 90% of people use their computers for. The 8th generation Intel cutoff for Windows 11 is ridiculous and is causing this problem.
Yes, Windows 11 works fine on older hardware if you force it to install but most people will not go this route. They’ll continue to use their insecure PC on the internet because it runs very well and does everything they need it to do, and we’ll have a nightmare on our hands.
The landscape is totally different from XP to 7 and from 7 to 10. Microsoft knows that and these pointless hardware reqs are a transparent attempt to force people to upgrade for no reason. The desktop and laptop market has fully stalled, and there is no compelling reason to upgrade your computer if you aren’t using it for gaming or processor/GPU intensive work. This is their attempt to boost sales without innovating, and it’s going to be devastating.
Probably in Ireland. It seems to me that (aka: I have no data) the vast majority of Irish use an iPhone.
The carriers have iPhones at roughly the same price as a half-decent Android phone, and those that can't afford to do that, get them second hand (usually older models..).
I have an Android, and I know several techie friends with Androids, but "normal people" have iPhones.
Really - It's almost a surprise to see someone with an Android here..
It seems like that here in New York too, but I believe it s because iPhones are the only instantly recognizable phone. If I look I can tell iPhone or other very easily.
Irish as well and have the opposite experience.
Everyone from teenagers using cheap android phones up to to a lot of people i know using the latest Samsung.
A lot of companies that would have previously used Blackberry but moved to to Iphones are now starting to move to android.
If I measure by market cap it also looks different, but that's an equally irrelevant measurement in this case.
The issue here is where the anti-trust line is drawn. Why people in the tech side never seem to understand this is beyond me, but the line is clear.
It has everything to do with your marketshare. Google could make zero dollars off Android, if they still own & control it and it reaches a vast majority marketshare, as it has in Europe, then they are pressured to open it up and increase competition within the platform.
Whining about Apple and whataboutism is ridiculous. They are not the majority of devices in any major region (NA/Europe/Asia/Worldwide). Some isolated countries are majority iOS, but they all exist within the EU and the EU is 75% Android.
Nobody but technically inclined users care that much about battery life anymore. For most people, you can throw a rock and hit a phone that has all day battery life. People are used to charging their phones nightly.
People will take a battery life improvement, but it's not a driver. Many manufacturers have slapped in giant batteries or included battery modules, removable back cases that allow for double life batteries. None have caught on, because really. If I have to charge it once a day or twice if I'm using it for games all day or something, then what is the difference? Have a charger at work, a charger at home and a decent phone, and you'll never have a battery life issue. I don't think I've depleted my iPhone X once and I've owned it since day one.
> Stock Android
Another thing nobody but techies care about, and even they are mixed. I know plenty of people who prefer modern TouchWiz, or more likely, simply don't care. Caring about stock Android really only applies to those who spend most of their time in the launcher or OS, which isn't most people. For most, their phone is a gateway to apps, and this goes double for Android phones.
If the primary use of your phone is launching Instagram, Snapchat, WhatsApp, Gmail & Facebook, then who the hell cares what the launcher interface is? Most younger and less technical users don't even use the dialer or contacts or other apps people typically leave stock.
> Durability/Ease of Repair
I can't believe people can actually say this with a straight face. Once again, the last thing on people's list. It's far and away a nice to have, not anything that actually influences a purchasing decision for a significant number of people. For those that it does matter to, they'll just slap it in a case anyways. It also requires a boatload of design compromises to make things easier to repair.
> Bring back the landscape QWERTY keyboard
The icing on the cake. I don't know who you know, but seriously, nobody wants a hardware keyboard. Most people under 30 (y'know, the people who buy new phones frequently and use them as primary computers) would actually be significantly slower on a hardware keyboard, regardless of layout.
What you've described is a giant phone, double or triple the size of any other normal between the massive battery, use of durable materials and durable slider mechanism. Nobody wants this. You might, and some of your friends might, but any company that took a run at actually making this phone would have abysmal sales.
You make a ton of assumptions here, all of which smack of someone who hasn't spoken to a normal consumer or someone under 30 in a long time. I suggest hanging around retail for a little bit, because you're in for a rude awakening.
Things people actually care about in a phone, in rough order:
1. OS - This is tied for the next two for number one. Nobody gives a shit about stock Android, but most are pretty set in one camp or the other in regards to iOS v Android at this point. People do switch though, so its not the highest priority for all.
2. Screen Size - Massive consideration. Many want a giant screen, many want a manageable screen, both are pretty set in their ways.
3. Camera - I can't count the number of times people have asked me for a phone recommendation and had this as their number one concern. I put the other two first because they tend to have those decided before speaking to me, so they are typically more important. Camera quality, as subjective as that can be, can really sell a phone.
4. Design - Gasp! Weight, thickness, materials. Actually really important. It may not show up on a spec list, but people do make decisions based on this even if they aren't acutely aware.
5. Price - For many this is the number one factor, but for many it's not even on the list so it's hard to know where to place this one in terms of order.
6. Cool new features - Hugely important, triggers upgrades. The giant OLED screen & FaceID sold plenty of people on the iPhone X. "What can this phone do that my phone can't" is a strong driver of upgrades that aren't required due to a failing/broken phone.
>Nobody but technically inclined users care that much about battery life anymore.
That is very far from the truth. Just look at the scramble around power outlets in all sorts of public places from cafes to trains. People are desperate to recharge their phones.
Stories of phones running out of battery are now as much part of folklore as not having coins for payphones was a few decades back.
Go to any Android or iOS support forum and you will find that battery draining questions are a major category. And it's plain to see that it isn't just techies asking these questions.
Battery is also _the_ limiting factor for the tasks phones are suitable for. CPUs, especially on iPhones, are capable of so much more than what the battery allows.
I never said people don't have issues with battery life. I said it's not a driver for most phone purchases, and I stand by that. Good battery life or better than average is a nice to have.
> Go to any Android or iOS support forum
The average consumer will never post to any support form in their entire lives. /r/iOSbeta was all battery life posts until they were banned because they cluttered up the subreddit, because of course that will be a common issue.
> Battery is also _the_ limiting factor for the tasks phones are suitable for.
But we don't have an answer for that. All GP is suggesting is slapping in a giant battery. That won't solve the problem at all. If someone has a breakthrough solution for multi-day battery life that isn't just "throw in a bigger battery and to hell with design" then that would be a game changer.
However, is it a major driver in purchases? No. Like I said, there have been plenty of "big ass battery" devices, none have been successful, because it's not a significant driver of sales.
> The icing on the cake. I don't know who you know, but seriously, nobody wants a hardware keyboard.
Not true. If it were true the Blackberry KeyONE wouldn't have been the moderate success that it was. Clearly TCL believe that QWERTY phones are viable as they've just announced the Blackberry Key2.
My better-half has not one, but two, KeyONEs - one for work, and one for personal use. They are very nice, well built phones with a pretty good spec. If you type stuff all day, then they are a great option.
Your experience is anecdotal. So is mine, and I haven't seen a single hardware keyboard in use -- not a single one, from any manufacturer -- since Nokia N900 was a thing almost ten years ago.
It's not actually. What I didn't say, is that my other half works for a large Law firm. Most of the Partners there (100+) have switched from iPhones to Blackberry KeyONEs as they can actually work on them because of the proper keyboards.
At the end of the day, keyboardless and keyboard phones CAN co-exist. I was just disagreeing that with the point that no-one wants a keyboard phone.
> I was just disagreeing that with the point that no-one wants a keyboard phone.
Perhaps glib. I could have clarified further but "a keyboard phone could carve out a small but somewhat lucrative niche amongst people who refuse to get used to software keyboards, people over 30-40, and people who owned devices that sport hardware keyboards in the past but they are ultimately doomed to irrelevancy in the long run" is less pithy.
I can’t find anything even close to “moderate success” for the KeyOne. Most of the articles I pulled up describe awful sales although Blackberry had an optimistic outlook. Most outlets citing sales numbers say that Blackberry only managed to outperform one company: the now-deceased Essential.
> the Blackberry KeyONE wouldn't have been the moderate success that it was.
Ok, well I come from the land of BlackBerry, and I have seen maybe one person with this phone in the wild. Keep in mind that BlackBerry was still a significant force here until years after it was dead everywhere else.
Just out of curiosity, how old is your better-half? Did they have a hardware keyboard device in the past?
I don't think age has anything to do with it. People either prefer hard keyboards or not. Technology should be an enabler, and allow people to use the device formats they want. Just because 90% of people are now used to touch keyboards, doesn't make the remaining 10% wrong.
i would buy a phone with a good hw based keyboard immediately. I was just thinking tonight, after correcting my 400th mistake, how weird it is we as consumers put up with this inefficient on screen keyboard.
>Another thing nobody but techies care about, and even they are mixed. I know plenty of people who prefer modern TouchWiz, or more likely, simply don't care. Caring about stock Android really only applies to those who spend most of their time in the launcher or OS, which isn't most people. For most, their phone is a gateway to apps, and this goes double for Android phones.
Umm, I want a phone with the latest security updates, since it holds very personal information I don't want it to have unpatched access. Phones with Stock Android - on average - get more updates/faster updates [1] (if at all). Also Stock Android gets rid of manufacturer code which can affect apps, for instance some Huawei phones, on Nougat, have USB-OTG disabled in the skin, accessible otherwise with LOS.
I actually based my recommendations off of the most common areas of complaint I come across and specifically the areas the younger set complain about most often.
Battery Life:
You can find someone tethered to a wall outlet in almost any public space these days. The apps which the younger set use most frequently (photo, video, and data heavy social media apps) are also enormous battery hogs. Facebook and Snapchat in particular are the source of more "my phone is on 2%, can I borrow your charger?" requests than anything else.
Durability/Ease of Repair:
Go to any high school or college campus and count the number of phones you see with cracked screens. I can't even count the number of people I know who have been stuck using a phone with a busted screen until they're eligible for an upgrade or able to afford a new one. Back in the days of the iPhone 4, a broken screen was a $50 fix. Now it is a mark of shame that lasts until you buy a new phone because replacing a screen is either not feasible at all or far too expensive to justify (this applies more to phones in the $250-300 range)
Bring back the landscape QWERTY keyboard:
I'll admit this is heavily biased by my curmudgeonliness because I loved my OG Droid and Droid 2, but there's something to be said about a feature that helped those 2 phones rack up huge sales figures but hasn't been seriously tried ever since. In relation to its appeal among the younger set, the amount of horrific typos and "oops, autocorrect screwed that up" I see across all forms of content generated on software keyboards is enormous. People may be "faster" with software keyboards but the speed means nothing when they either butcher their point or have to edit/send a second message to correct their mistakes. Also, the proportion of smartphone users who actually use swipe style predictive input and those who hunt and peck is skewed heavily toward the peckers.
You make good points in relation to camera quality and cost but I see those as inherently "solved" problems in today's smartphone market. There are dozens of phones with great cameras, copying what they're doing is both easy and not a real differentiator. Any feature I neglected to mention can be covered under the heading of "just don't screw it up", there's no excuse for fucking something up when you have dozens of examples of how to do things right. As far as cost is concerned, it's obviously factor #1 these days as the "mid range" is continually eaten away by pressure from unceasingly good budget phones and the "flagship" price point becomes unattainable to startups that can't create an entire supply chain to support the latest whizbang innovations. I still think there's room for a phone like I've described at the $400-500 price point, whether that's achievable with the landscape QWERTY is the real question.
I get that these moves make people nervous, and rightfully so. But as it stands every version of 1Password in active development (not including maintenance mode):
* Can be licensed standalone.
* Supports local & Dropbox vaults.
* Was released within the last year, actively supporting those features.
The only feature they’ve actually killed off (by not baking into future clients) is WLAN sync. This is a regression for some, but personally I always found it super impractical.
I agree that how they are going about this doesn’t inspire confidence that these features will remain in the product, but to some extent it does.
While they downplay the hell out of it, 1Password 6 for Windows was a ground up rewrite that ditched local vaults and standalone licensing. Those features were reintroduced in 1Password 7 for Windows, which is a pretty big backtrack for them and requires renewed development effort.
AgileBits doesn’t always make the right decision. They develop opinionated software, like most good developers. However, just like the MAS-only decision they made with 1Password 4 and stood by for some time, eventually they do right by their customers.
1Password 7 for Windows is a great example of that. As much as they would love to go cloud only, they heard the feedback and brought back those two key features. At this point, I can’t expect much more than that.
I moved to LastPass the moment Agile Bits decided to not support its (non subscription) 1Password paying customers in having a web access to the vault.
I had bought all 1Password versions + updates (Windows, Android, Mac, iOS) which put me well above $100. One day I simply couldn't use 1Password online, which I relied on for Chrome OS use. Dropbox decided, rightfully, that the public folder shouldn't be used as a static web server, which is what 1Password used as online vaults.
There was a long discussion in Agile Bits' forums about this issue. Agile Bits argued that it wasn't its responsibility to solve this since it was a Dropbox decision and its users could still store and sync the online vault manually on their own servers. I argued that losing automatic sync rendered the feature pretty much useless.
In any case, Agile Bits could have transitioned its users to the subscription model by either giving them subscription time or by offering an alternative to the Dropbox public folder, but it decided that its customers were not worth the effort.
I had a lot of respect for Agile Bits and 1Password, but this was a crappy way to treat its customers, specially considering 1Password was not a cheap product.
LastPass is not as elegant, but I'm happy with it.
How many customers read your blog? That post has 225 comments. From that base, 90 people expressing interest in a feature sounds HUGE.
I don't care about that feature... but this HN thread is the first I'd noticed that 1Password 7 for Windows actually exists and finally brings back local vault support. I care very much about that. I'd have liked to know about that the minute a public beta landed. But... I spend approximately 0 minutes a day thinking about ways I could better engage with AgileBits.
Maybe y'all could spare some minutes to figure out how to better engage with me, a customer who gave you some money 3+ years ago and has hardly heard a peep from you since.
That is a real challenge. On one hand we love talking about 1Passsword and what we’re working on. On the other hand...
1) We often don’t even have contact details for customers (e.x. App Store purchases)
2) When we do have such contact details they may have only been given for the purpose of completing a transaction, and did not agree to receive a newsletter or ongoing communications
3) Even when none of the above is a barrier it is very time intensive to send a newsletter. Not only does it require a fair bit of time to craft but the volume of inflows to our customer support team after sending a newsletter are huge.
I understand and agree with your position that putting the onus of keeping up on what is happening at AgileBits on the customer is no solution, but we do have to balance the above considerations. We’ll continue to look for ways we can do better.
Did you subscribe to our newsletter? We also sent an email about it.
Blog and newsletter are the only options we have to communicate with our customers. I agree that it is not enough and not everyone receives this information.
If you have an idea how we can make it better, please let me know!
I agree they are burying the hell out of it, but as it stands licenses for 1Password 7 (which is still in beta on Mac & Windows) can only be purchased from within the client, as they want to test the order flow which was rebuilt in this version.
The Windows version of 1Password 7 still can’t be licensed, they haven’t built that part yet. The Mac version however can be purchased, and if you plan on sticking with it I would do so now, as the price will be much higher in the near future. Right now it’s being offered at 50% off.
I just went through this - there's a tiny "downloads" link at the bottom of their page that takes you to https://1password.com/downloads/
I just went through this. Install v7, open it, unlock your vault, and it'll prompt you to try a subscription, with a tiny option below to just buy a license.
* Barrier to entry. If your project is more than a hobby, you can jump through a couple hoops to reach the iOS userbase. If the difference between $99 and $25 is make-or-break, you're probably trying to publish a hobby/low quality app anyways. There is a reason the Microsoft Store and Google Play are absolutely filled with trash, and this is part of it.
* Forcing you to use native controls. Thank god. I hate webapps. The only people who like webapps and their encroachment on good, native apps are webapp developers because it allows them to use their skillset to build something they don't know how to build. Everyone else wants native apps back, even if they don't know it. Case and point: the hatred for all the apps moving to Electron and the ridiculous amount of resources they consume. Most people don't know what Electron is, but they can tell you how much they hate the new Skype.
* Requiring a Mac. This is similar to the "barrier to entry" one above, but seriously. I've never met a developer who complained about needing a Mac to develop for iOS that has put forth an even halfway decent iOS app.
Software development is already very, very easy. The barrier to wide distribution is almost nothing. This is an extremely developer-centric perspective, which is fair, but at the end of the day, your users pay the bills and it's hard to be developer-first without also being user-hostile.
This strikes me as the analysis of a developer I would never support, because they care far more about making everything as easy as possible for them rather than making the experience good for me. It's important to remember that while you are doing some consuming, you aren't the customer in this equation. The users are.
>If the difference between $99 and $25 is make-or-break, you're probably trying to publish a hobby/low quality app anyways.
Or maybe you live in a situation where $74 USD is a meaningful barrier to accessing a market.
>The only people who like webapps and their encroachment on good, native apps are webapp developers because it allows them to use their skillset to build something they don't know how to build.
You're excluding people and organizations who want to maintain a single codebase.
>I've never met a developer who complained about needing a Mac to develop for iOS that has put forth an even halfway decent iOS app.
My takeaway from this is that you've not met a lot of developers outside the U.S. or who have ethical concerns about mandatory hardware / software purchases as prerequisite to market access.
Or maybe you live in a situation where $74 USD is a meaningful barrier to accessing a market.
So they could afford a Mac and internet access, but they couldn't afford the extra $74?
As far as excluding people and organizations that want to use a single codebase - good. If they didn't want to take the time to customize their apps enough to make it work on my platform of choice, it's not an app I wanted anyway.
My takeaway from this is that you've not met a lot of developers outside the U.S. or who have ethical concerns about mandatory hardware / software purchases as prerequisite to market access.
And the market is at work - they chose not to take the time to make an app optimized for my platform of choice, and I'm not stuck with an app that isn't optimized for my platform of choice.
> So they could afford a Mac and internet access, but they couldn't afford the extra $74?
An old mac should be pretty cheap (the latest xcode runs on pre-2010 macs, even more so as they can be upgraded by hand — to a point) and if you're in SEA or eastern europe your internet connection is not $150/mo comcast. For instance in Romania high-speed internet is $15, but the average net income is $650~700 and minimum wage is ~200.
And I'd add that requiring a Mac is another unnecessary barrier to access. Things like Fog Creek's Glitch IDE are making it clear that it's possible to build things from any device with a browser.
Well that's really cool. How is React Native coming along? I see it's still pre-1.0, but given that they've been going 3 years, I assume there's been a lot of progress.
Consider all *nix tools one uses on a Mac. Consider the hack which git on Windows is.
VS Code is an example of an universal, well-optimized app. Slack on the other hand...
Stuff like this is driven by diluted business decisions. Inferring from it that probably one would not use the app eitherways is borderline Linux-like fanatism fueled by self-delusion.
> You're excluding people and organizations who want to maintain a single codebase.
Isn't one of the long held up tenants of software development that you should "pick the right tool for the job"?
Because if, as a user the choice is between another shitty JS/web-app masquerading as a real app, and an app that's built properly with native API's and native code, I'm 100% going to choose the latter.
> You're excluding people and organizations who want to maintain a single codebase.
Not my problem. Don’t shit on my user experience because what YOU want. Remember, I don’t need your product, but you need customers.
As far as ethical concerns about mandatory software purchases as a prerequisite— it’s not mandatory: you don’t have to develop for iOS. Make a website instead.
> Remember, I don’t need your product, but you need customers.
Not all customers are desired. Some are enough of a hassle for support (both in developing for the idiosyncrasies of their platform and potentially dealing with the idiosyncrasies of their personalities) that they represent a cost rather than a profit.
This is why some are perfectly happy that Apple's policies effectively exclude Apple users from some of their output. It effectively means a bunch of self importants, who would complain that the moon is the wrong shade of grey if given it on a stick, are conveniently diverted away from bothering them. Unfortunately while Apple platforms seem to have more than their fair share, such self importants exist everywhere...
Similar arguments can be made for not supporting IE, particularly legacy IE: unless you are targeting certain industries (investment banks: I'm looking at you!) supporting users stuck on old browsers can be more time+hassle cost then they are worth.
Is the person's app going to automatically end up on your device or did I miss something here?
If Apple's review board feels the app is trash, it will be rejected as such. And the original poster wanted to just do a website instead, but they also wanted audio to be playable in the background (which makes sense when you're making a for all intents and purposes radio app).
> If Apple's review board feels the app is trash, it will be rejected as such
Apple is not as strict here as you're supposing. While Apple's review guidelines do say that they reserve the right to reject apps during the review process if they're ugly or don't work well, in reality this is almost never the case.
> Remember, I don’t need your product, but you need customers.
This becomes much less compelling with apps built to be used within a large enterprise. At this point cost of development and maintenance become much more important, because you can always train your workforce to fudge their way around the suckass user-experience.
(Although, in principle, I agree with you and am generally not a fan of systems and products that sacrifice UX for developer expediency.)
Or maybe you live in a situation where $74 USD is a meaningful barrier to accessing a market.
Like what situation? To build an app at all he requires at least one computer, which is guaranteed to cost more than $99. He didn't blink at paying $25 to access MacInCloud.
The $99 fee is hardly a big deal. It's quite clearly there to encourage people to report charges on stolen credit cards, i.e. to make credit cards usable as a form of ID verification.
You're excluding people and organizations who want to maintain a single codebase.
There are ways to do that which don't require the web.
> Like what situation? To build an app at all he requires at least one computer, which is guaranteed to cost more than $99. He didn't blink at paying $25 to access MacInCloud.
You're from eastern europe, south america or SEA, and $99 is a serious chunk of money.
The latest Xcode requires sierra which runs on a late 2009 macbook (or even older using sierra patcher), and you can use that for other things than just publishing your application.
Like anybody was forced to write iOS apps... I'm an undergrad from Turkey and buying Apple hardware is impossible for me (and not really desirable ATM, but that's not the topic). But I don't feel I'm barred entry to the app-making business, I can start with a desktop app, a web business, or a even a Flutter app on Android and later port to iOS when it's financially feasible. iOS crowd is a bunch that wants quality software and is willing to pay for it, and that the entry to the market is not free is completely understandable. Otherwise it's like wanting to run a caf but not wanting to pay rent or resources. They don't owe you nothing.
> To build an app at all he requires at least one computer, which is guaranteed to cost more than $99.
Well, the question is who does it cost? The original purchaser, or the person that was gifted it or got it for free because it didn't work and put the time in to fix it?
Plenty of people get computing hardware for free or close to it.
> There is a reason the Microsoft Store and Google Play are absolutely filled with trash, and this is part of it.
It's kind of ridiculous to pretend that the App Store isn't also filled with trash.
There are some excellent things (especially in security and privacy) you can depend on Apple's review either catching or warding off, but poor app quality is definitely not on that list.
(and as others have noted, far more apps are built with web views than you apparently realize)
I love electron and I've never built one and don't have any immediate plans to do so. I'm a Linux user and because of how easy electron has made cross platform, I am enjoying far more applications that support Linux because barrier is so incredibly low.
Are they resource hungry? Yes. Are they as smooth as a well polished native app? No. But, for many of these apps, the alternative is having nothing at all.
"Requiring a Mac." This most often bites me for testing Apple Pay. This assumes that writing an iOS is my primary responsibility. For some folks, that's not the case. This isn't a huge deal because I can just use a test device, but it is annoying.
The silver is somewhat dulled by the fact that an Electron application is barely better than no application at all, only slightly less heavy than running VirtualBox in seamless mode, and has about the same level of native integration.
Dude what are you on about? VirtualBox is 1GB minimum, better 2 and has to virtualize gfx card, meanwhile electron is talking to gfx drivers directly and takes 100-200 MB if used correctly.
I don't care about the $99, I absolutely loathe native apps (because I don't have nor want a smartphone) and there is no way I'll ever buy a Mac to do iOS development. I do have some Apple hardware here but it runs Linux.
Developers should be free to make their choices without being forced into some kind of eco-system, especially not with Apple itself focusing more on their gadgets and fashion items revenue streams than on making actual computers.
Does your distaste for native apps extend to the desktop computer? Many HN users (myself included) dislike Electron-type apps because they feel slow and bloated. On my computer, native apps are much nicer, and feel like they fit in much better with the desktop environment.
If you agree that native apps on the desktop are a good thing, than I think you would agree that, for smartphone users, native mobile apps are a good thing as well, for the same reason.
VSCode, as far as I'm aware, uses Electron and is great.
Twitter's React web application was so good on performance and hitting all of the marks I used the mobile native application for that I was able to delete the native application saving space, and "adding to homescreen" for like, what, a few bytes of storage?
Facebook I just use the mobile web app inside of Safari proper instead of installing the native app. It's a pain that I have to wait until I'm on my iPad or PC to use messages (I don't install Messenger because I don't want a separate application just for a small feature of Facebook proper), but it's serviceable enough. Would be nice if Facebook would follow Twitter's lead and build a native-like web experience, but I guess they don't feel it adds the value and that's their right.
I'm completely game for people using these things and doing it right and if done so, yeah, I think it is better than or at least equivalent to native (PWAs != Electron apps, but can be served in them). It is also crazy to compare a 32GB-128GB device vs my PC with storage measured in TBs. I can afford bloat on my PC that I would prefer to keep away from my phone.
A native app to me is something that works independent of a network connection (with the exception of browsers and an email client, those are obviously pretty useless without and a browser is the 'gateway' to the online world), and without an interpreter. Most mobile phone apps aren't native by that definition, but let's stretch the definition and include binaries targeted at virtual machines.
So native apps that I'm happy to use: compiler, editor, whatever stuff I've written myself, cli tools, bash, ssh, openoffice, okular, Firefox and Thunderbird.
Your typical mobile app is just an extension of someone else's server. As such it should be a web app rather than a native app.
That's a strange definition. Native usually means that the application uses the platform's native APIs. The application could require a network, or not. I grant you that an app that should not need the network fails to work without a network connection probably means it's not a native app, and instead it's trying to execute on some server somewhere else (like a classic web page for instance).
> Many HN users (myself included) dislike Electron-type apps because they feel slow and bloated.
How much of this is the fault of the Electron runtime and how much is fault of the developers?
When one looks at the sheer amount of code that popular frameworks (or, as I call them, crapworks) like Angular require the browser to load, compile and run, plus the resources that these apps end up gulping down... it's madness, compared to how far plain old jQuery will get you while running at a quarter of consumed resources.
Sure, using only jQuery requires lots of thinking about your code structure and it will undoubtedly be more complex. But also: orders of magnitude faster.
This is effectively asking to double the size of the engineering team, or slow it down dramatically.
If I were a startup or small business, I'd rather ship a slightly slow-feeling app with my existing team of web developers who already know their tools, than to hire a bunch of native developers and somehow get them all on the same page.
> If I were a startup or small business, I'd rather ship a slightly slow-feeling app with my existing team of web developers who already know their tools, than to hire a bunch of native developers and somehow get them all on the same page.
That might be the time where you'd want to stand out from your competitors by shipping a fast, native app rather than a web app.
Slack was able to stand out from its competitors by providing a reasonably fast web app. Nobody cared (cares?) about the desktop app.
It sure seems like you can compete with a good feature set and fast iteration on your product. Throwing more web developers on the project is often the right call, so you can keep shipping new features quickly on every platform.
I'd love to be proven wrong, but performance seems to be an afterthought to the market.
What if that business wants to provide an "app" icon in the macOS dock, and a "program" in the windows start menu, without hiring a bunch of native developers? What would you advise for them, if not electron?
Eh, I like it. It loads quickly and doesn't tap resources. I typically use Visual Studio as well, but I do it when I need to do a quick edit of a file or quickly see syntax highlighting on something to review. Basically, Electron isn't bad. It is most likely the fault of the implementer if it goes that direction.
I think Brackets is served in Electron as well and that seems to be a lesser quality implementation. I like Brackets, but the performance is somewhere between VS Code and a full fledged IDE.
Sure, using only jQuery requires lots of thinking about your code structure and it will undoubtedly be more complex. But also: orders of magnitude faster.
It’s really, really not. You might be able to pull together some specific targeted DOM manipulation that is faster in jQuery than in React, for example, but the difference is going to be minimal and the development impact substantial.
> You might be able to pull together some specific targeted DOM manipulation that is faster in jQuery than in React, for example, but the difference is going to be minimal and the development impact substantial.
The usage difference in RAM and CPU usage will always be massive, because with jQuery (or if you're in for really high performance code, plain JS) you cut all the framework cruft and black magic away.
In addition, I would not be so sure about the development impact. JS frameworks come up every two or three years and vanish in about the same timeframe, yet the good old KISS-based dog jQuery happily barks along. jQuery devs are a dime a dozen, good luck finding someone today who does emberjs (if you want to maintain a legacy project) or knows the innards of the latest compatibility-breaking version of Webpack (if you ditch your legacy project and "relaunch" it).
I just don’t agree with this from any perspective.
First, the impact is minimal. React or a similar framework is not that big. In fact, React + ReactDOM is roughly the same code size as jQuery - 100k vs 85k minified.
Second, your custom DOM manipulation code is probably going to be a bit less optimised than a widely used library.
Third, you are overstating the difficulty. I would expect any competent front-end engineer to be able to pick up whichever of these frameworks is required. The different skills are a matter of a little on boarding and studying. Of course, there are many unskilled JS developers out there, but I don’t think that’s an excuse.
If you agree that native apps on the desktop are a good thing, than I think you would agree that, for smartphone users, native mobile apps are a good thing as well, for the same reason.
That doesn't necessarily follow. The average mobile app is so simple in terms of both the data it's working with and the complexity of its UI that reasonably efficient code is unlikely to challenge a modern mobile device, whether it's native or running within a browser.
> The average mobile app is so simple in terms of both the data it's working with and the complexity of its UI that reasonably efficient code is unlikely to challenge a modern mobile device, whether it's native or running within a browser.
Unfortunately, it has been shown time and time again that this isn't the case. Somehow, it seems that web apps just never get the performance that native apps do.
Unfortunately, it has been shown time and time again that this isn't the case.
Has it? Web apps might be positively correlated with poor performance, but I don't see any causal relationship there for the kind of apps we're talking about here.
From direct personal experience, some of the UIs I've worked on have been relatively complicated by web app standards, yet typically there's been no perceptible lag in any rendering or interactions. We could achieve that kind of responsiveness at least a decade ago, on much less powerful hardware than sits in your pocket today. Obviously there is an inherent delay in any communication required with the server, which is one of the main areas where PWAs and some of the other modern APIs can help to minimise the effect. Other than that, modern JS runtime environments running on just about any smartphone, tablet or laptop from the past few years are plenty fast enough for the kinds of software most of us are trying to run within them.
Of course, that's not to say there aren't many poorly performing web apps out there. It's just that I've yet to see one where the poor performance was demonstrably attributable to the fundamental web technologies involved, as opposed to simpler explanations like developers who had no idea what they were doing and relied on inefficient designs, bloated frameworks, and so on. You get that with native desktop software as well, but no-one's saying a modern PC can't do things quickly just because someone managed to write yet another text editor that had a noticeable delay just opening a file with a few thousand lines in it.
I'm guessing that the OP is an advocate of open software and user freedom. Native apps are generally locked to a specific proprietary platform: Windows, macOS, Android, iOS.
As somebody in support of free software and individual control over our computers, I think web apps are the best class of apps we've seen yet. Thanks to the proliferation of web apps, desktop Linux is finally a viable platform.
Of course, I'd personally love to see the bloat of the browser disappear. In my dreams, we'd be able to run React Native applications on desktop. This is already possible with react-native-windows, but we still are waiting for stable support on macOS and Linux.
-Having a barrier to entry is good useful only if your App-store search is crap.
Also, the $99 is every year. Developing on iOS has cost me $900 in certificates, compared to $25 with Google.
-That's obviously wrong, see 100% of the top selling games.
-The top developers have to make clusters of freaking mac minis just to run their continuous integration tests. Do you think they are happy about that?
> -The top developers have to make clusters of freaking mac minis just to run their continuous integration tests. Do you think they are happy about that?
Top app developers should already be on hosted/SaaS CI services that offer Mac servers like Travis or CircleCI.
Furthermore, it’s detached from reality. I released an app made with Ionic. It’s an app for average joe, not for devs or designers. Out of 20,000 downloads, I received exactly 0 complaints about performance or UI. Most users don’t care and don’t notice anyways.
And it’s pretty much the only way how I can maintain an app for both platforms as a solo dev.
> I released an app made with Ionic. It’s an app for average joe, not for devs or designers. Out of 20,000 downloads, I received exactly 0 complaints about performance or UI. Most users don’t care and don’t notice anyways.
Personal anecdote: I wrote an app to replace one that was written using Ionic because the experience was so poor. None of the complaints for that app were about the UI, because I assume most users, not being developers or designers, couldn't put their finger on what was wrong with it. However, once I released my app most my of reviews ended up being about how it was much better designed.
Especially the iOS app is almost indistinguishable from a native iOS app. Ionic is very well designed to mimic native UI controls.
In the end, it doesn’t really matter if your native UI lot runs some sliding animation in 60fps or if the very same animation is done in JS and runs with 60fps.
How accessible is your app? Have you tried it with VoiceOver? How does it do with battery and memory vs another comparable native app? When there's an OS upgrade, does your app automatically adjust to new resolutions and device classes?
> When there's an OS upgrade, does your app automatically adjust to new resolutions and device classes?
HTML and CSS are far more proven at adjusting to arbitrary resolutions and device classes than the vast majority of "native" UI frameworks, specifically because nearly every device class needs to support HTML+CSS, but "native" frameworks don't have to support every device class.
Yes, it is neat that specifically, iOS is playing from some interesting fun toys like Cassowary solvers to support some pretty advanced stuff. From a pragmatic standpoint as a cross-platform dev I'd rather just let HTML+CSS do the work, because that can be used everywhere.
(Similarly, Browsers in general are pretty strongly accessible and HTML can be written very accessibly. Again, pragmatically cross-platform it's the easiest accessibility solution available.)
(Memory and Battery are somewhat fair questions. Given how much time people will spend in a Browser, though, I think the turnabout is better fair play: if there is such a noticeable battery/memory difference between native apps on your platform and websites/webapps, but you spend the majority of your time in websites/webapps, then what is your platform doing wrong?)
Battery and memory: no big difference. And JS doesn’t run in the background.
Download size: 5MB
Upgrades: I had a native iOS app back in 2011 and this app required quite a few UI adjustments over the years to work properly on the latest iOS version and hardware.
Can’t tell yet for the Cordova app, but it works out of the box for all iPhones and many Android phones without writing a single line of additional CSS.
For sure, there are downsides to Ionic, but I’d strongly consider it. The single code base has so many advantages and cuts development costs with almost no downside for the customers.
I’ve been getting tired of seeing accessibility, accessibility, accessibility in every front end web/iOS/etc conference. Like we get it, everyone’s got it...
Controls: It doesn't force me to use native controls. :-) My web app today is still using the free and opened web, and all the goodness that comes with that, for UI and code.
Requiring a Mac: Now you've met one. I built a halfway decent iOS app, and I don't want to spend $7000 on a Mac and its crappy dev tools and frameworks.
I've poured nearly 7 years of work into user experience. I don't need to redo all that for Apple's closed, proprietary platform.
While possible, it's far from ideal. I had this experience, using an old MacBook to build an iPhone app. It repeatedly crashed because I had Atom and XCode open at the same time.
The $500 Mac mini can handle Xcode just fine, and that is a many year old machine that hasn't been updated. Maybe not if you've been spoiled on better hardware, but it performs adequately.
I used my personal $500 mac mini for full-time desktop and webapp development when employed at Citrix. This excludes the cost of peripherals, of course.
We're talking about a Cordova-wrapped SPA. You can develop those on Raspberry Pis if you had to. A 9 year old $250 MBP off ebay will absolutely suffice.
Yes, I'm using hyperbole. :-) Even $1000 to build a free app is too much. (That said, going to Apple.com and clicking Mac shows me the base model for $4999.00 [0])
What happened to cross-platform apps? Why is it that Google and Microsoft are champions of the free and opened web, and even cross-platform dev tools for web development, while Apple is holding back progress?
I think the reason is their business is jeopardized by the free and open web, just as Microsoft was in the late 1990s.
Yeah, no, it actually literally doesn't. There's no "Macbook" button on Apple's site. There's a Mac button. The Mac page then shows you a range of Macs, from the Macbook to the Mac mini, at the top of the screen. they are showing you the iMac Pro--their halo-effect product and newest release--on the Mac landing page; that's not the same thing and it is dishonest to assert that it is.
Open standards are good. (The open web, whatever. I use React Native, because I like writing applications that feel responsive.) Open standard thumping as a proxy for weird platform fandoms is really not. Stop.
Mac button, not Macbook, but you already knew that.
Open standards are good. And we should want them to win, because it provides a safe haven from the abuses of big corporations. And I think right now, Apple is stepping into those waters: they are holding back web standards in order to keep promoting their business, which is reliant on native apps.
Right, because computing is full of cross platform frameworks that you can write once and run anywhere and have as great of an experience as native apps - look how great Java and Swing were.
Android uses the Java language on top of Google's non cross platform framework. That's completely different than using Java with Swing. An Android app is not cross platform.
Web apps on Android May "work" but still aren't as responsive as native Android apps.
To be fair, judah said "going to Apple.com and clicking Mac shows me the base model for $4999.00"
Doing what he said takes me to:
https://www.apple.com/shop/buy-mac/imac-pro
On which the only computer I see without scrolling is the Mac Pro. My UI design friends constantly tell me anything "below the fold" may as well be invisible.
Clicking the "Buy >" button takes me to
27-inch Retina 5K 5120-by-2880 P3 display
$4,999.00
I know there are other options, but that's the default path for a naive user wanting to buy a mac from apple.com.
I hope casual users don't end up following that path often!
First you said "$7000 on a Mac", then I said "You can buy a Mac for <$1000", then you said "Macbook shows me the base model for $4999.00" and you linked to an iMac Pro.
You can buy a completely dev-usable Mac for under $1000. (My CI machine is a Mac mini I bought used for $350 and dropped an SSD and an extra stick of RAM into.) Its "crappy dev tools" are free.
How reliable is your CI machine? I don't have the log entries anymore but in the past I've seen Mac Minis that were set up as Jenkins nodes throttle hard, leading to variable job results. The Minis were running VirtualBox VMs which would arbitrarily report long running test failures. I remember thinking perhaps it was VirtualBox specific behaviour until I search for "mac mini cpu throttle" and found similar results.
For my purposes? Very reliably. But my use cases are very sporadic; I'm just exposing a webhook for my VCS and running when one of a small set of my personal projects are updated.
(It also runs a couple other small things for the house.)
"Neutered" is a weird term. The line is due for a refresh, I think it's got an i7-4578U Haswell in its top-end machine, but that's not "neutered". Yeah, they want you to pay for upgrades themselves and that sucks, but, whatever--my 2012 one has an Ivy Bridge i7 in it and it is still plenty fast for build tasks in my (fairly price-conscious) environment.
If I needed a beefier machine, I would be making much more money and justifying its purchase.
You've poured nearly 7 years of work into user experience, and you don't appreciate the benefits of native UX, especially on iOS?
My company builds our app in React, with the performance and UI critical functions in Java (Android) and Swift (iOS). I've spent my career learning and applying one key rule about UX, little things can make huge differences in how enjoyable and productive the user experience is.
Barrier to entry. If your project is more than a hobby, you can jump through a couple hoops to reach the iOS userbase.
Sure, I can do that. But I won't. If you buy an iPhone, I'm afraid you will just get an inferior version of my service, or you won't find it at all, because you bought into a platform that is developer-hostile.
In the meantime, all of my other customers, who are happy to visit my web sites directly or find them via more developer-friendly channels, will be benefitting from improved features or extra content or lower prices that we could offer because we didn't waste time jumping through Apple's hoops.
This is very much about barriers to entry, because every barrier cleared represents an opportunity cost. Nothing about jumping through Apple's hoops makes my service better for my customers, and all of it makes life harder for us.
Your whole argument about being developer-first also being user-hostile seems like one big false dichotomy to me. It is precisely because I have limited time and resources and I want to spend them making things better for my users and thus ultimately being more successful as a business that I won't play these games.
So people keep saying around these discussions, but I've yet to see any hard data to support it, either published by others or from our own market research.
Your comment doesn't make sense, but even if it did, you don't have enough information about what we do to make any intelligent judgement and you're just being unnecessarily aggressive and hostile. Please stop doing that.
Really? Does the argument that you're saving on development time by not writing a native app for your users, which gives them a subpar experience, not "make sense"?
> you don't have enough information about what we do to make any intelligent judgement
You're coming off as "you don't know me, don't judge". If this is how you feel, maybe you could share more information about what you do rather than trying to shut down the discussion?
I suspect that the comment he replied to had some typos. It basically says "You aren't making it better for the users, you aren't making it better for you". Taken at face value, it doesn't make much sense.
From a user perspective, I want PWA. I would rather PWAs (or something similar) to get first rate apps/aupport, so then it would be trivial to move off the iOS/Android OS. I want to have a smartphone I control. For iOS, I just don't control the phone. So far Apple has been reasonably good with privacy, and Android is almost by design user hostile for user privacy. If a third OS comes out (think Librem 5, PostmarketOS) with PWA support and there are already apps out there, it makes the switch much easier.
> Everyone else wants native apps back, even if they don't know it. Case and point: the hatred for all the apps moving to Electron and the ridiculous amount of resources they consume.
The main complain people have with electron, is its heaviness. You ship a whole browser just for your tiny app. If every electron instance was using the same library & the same process (esp. the same JavaScript VM), most of the trouble would go away.
> Most people don't know what Electron is, but they can tell you how much they hate the new Skype.
Most people hate UI changes, and the new skype brings a lot of it! On a technical point of view, the new Skype is quite ok, it's not like the old ones were especially good either …
> The main complain people have with electron, is its heaviness. You ship a whole browser just for your tiny app. If every electron instance was using the same library & the same process (esp. the same JavaScript VM), most of the trouble would go away.
Among other things, such as lack of accessibility, a UI that looks out-of-place on the platform, and general lack of refinement.
> Most people hate UI changes, and the new skype brings a lot of it! On a technical point of view, the new Skype is quite ok, it's not like the old ones were especially good either …
I'm still running Skype 7.59 because it's not a RAM hog and looks a lot nicer than Skype 8. The new Skype is significantly worse.
> This is similar to the "barrier to entry" one above, but seriously. I've never met a developer who complained about needing a Mac to develop for iOS that has put forth an even halfway decent iOS app.
That quote could be in Wikipedia article about survivor bias as an illustration. Of course you haven't heard it - anybody for whom it is a problem is not developing iOS apps and probably doesn't talk to you about it. I am in software industry for decades now, and I have developed software for dozens of systems, but I wouldn't waste my time at trying my hand at iOS development anytime soon - one reason being because there are too many hoops to jump over. And I already own a Mac. Imagine same position where you may need to buy one.
As someone who is both, there are times where you'd like to create a quick web application to do a task that is either very specific to one's needs or only needed for a brief period of time rather than going wholesale application development.
In this particular user's case, they just need some API features accessible to web and they'd be golden. As a user, if I have the ability to approve and later revoke the permissions (in the event WebAppX is a bit malicious in its permissions usage), I'm game. That's value added.
> they just need some API features accessible to web and they'd be golden
But now you have every single website asking for permission to use the microphone and camera and accelerometer or battery sensor. Every time some sort of device hardware is exposed to web applications, it needs to be rolled back in some way or the other because someone's found a way to use for fingerprinting.
> Every time some sort of device hardware is exposed to web applications, it needs to be rolled back in some way or the other because someone's found a way to use for fingerprinting.
This is odd to me. Do you think it's harder for a native app to fingerprint you? At least on the web I can block specific domains or scripting in general.
A native app will always be a net loss for privacy and sandboxing.
No, of course it's a lot easier for a native app can fingerprint you. The difference is that with native apps, I can trust that someone has already looked at this app to ensure that it's not doing anything malicious. Plus, I, myself, have to install the app, which shows that I put my trust in it.
I used to have this perspective, but recently I've started to find it problematic.
Curation, while effective, is always a monkey patch on top of security. Ideally, I want to sandbox code. I don't want to have to trust it. I think it's unnecessarily limiting to assume that users should only ever run code that they trust.
In fact even native apps already try to do some sandboxing through a permission model. It's just that their permission model is less effective than the web, gives users less control, and leaks more information.
I'm also not sure that this matches my real world experience. I might use Facebook messenger or Twitter on my phone's browser. Installing something like Matrix makes me feel even better about that. I would never install their native app.
In theory I trust apps more than websites, but in practice I find that I usually view the app store with just as much suspicion as I do a random website.
No kidding. If you hope to develop apps for iOS, you better have a machine with the corresponding build tools.
I make a number of Cordova plugins. Many devs without a Mac often use PhoneGap Build as their dev build service. The turn-around to make a code-change and see the result must be about 60s.
You might be applying your anti-Electron arguments a bit too broadly. PWA is not that easy, but the UX friction involved with downloading and installing native mobile apps is abysmal. Electron is (arguably) a shortcut for desktop apps, putting webdev convenience above UX. Whereas PWA is all about improving UX, and is also typically (in practice) more relevant to mobile than desktop.
> the UX friction involved with downloading and installing native mobile apps is abysmal
Wouldn't PWA be the same too? In fact, I think having to figure out the web address and type it in, and then add it to the home screen is much more tedious.
For me the great advantage of web apps is that you build a single code base for that can run on any platform (browser). That make it so much easier to maintain so you can focus more on features.
If you build a native app for iOS you'll have to build another for Android and so it could be harder to maintain.
I think you've discovered his point. The advantage that you describe makes the developer's job easier, not the user's.
If you're an iOS user, where the monetary incentive is there for developers to invest the time to build you a native app, you don't care whether that imposes a greater hardship on the developer, because you're not the one affected. You've become accustomed to developers building something specifically for you and you're not willing to throw that away for what is a somewhat compromised experience that makes the developer's life easier.
1. Web apps typically work everywhere, including on my Android phone, on my Windows machine, on my mom's Mac, and on Linux when I used to use it as my primary desktop platform. I know this without having to look up a compatibility table because I opened it in my browser, and other than mobile-version/desktop-version, web apps work the same way everywhere. Native apps are often platform exclusives, and even if they do work on multiple platforms, they work differently on different ones. Try asking someone who owns a Mac how to use MS Office when you're on Windows.
2. I know how to share web apps with my mom by texting her a link. Even if your native app has a share button, it's in a different place in different apps instead of just "click the address bar and hit Ctrl-C".
3. Web apps almost always work with my browser's password manager, ad blocker, and stuff. Native apps are more of a crapshoot there.
4. Web apps are limited by the browser's sandbox (this is not applicable to native apps on Android or iOS, since they're sandboxed pretty much the same way as web apps, but Windows and Mac are both still playing catch-up).
5. If Linux users didn't have web apps, they'd have no apps at all.
> I know how to share web apps with my mom by texting her a link. Even if your native app has a share button, it's in a different place in different apps instead of just "click the address bar and hit Ctrl-C".
On macOS and iOS you iMessage her the App Store link.
> Web apps almost always work with my browser's password manager, ad blocker, and stuff. Native apps are more of a crapshoot there.
And they do this on iOS as well, as long as you use Apple's password manager and ad blocker.
Also, all Android apps are Linux apps (when we want to avoocate Linux as having lots of apps) and none of them are really Linux apps (when we want to advocate freedom).
Android apps aren't inherently closed; I use a handful from F-Droid, for example. I'd love it if a more open collection of apps could make the Android/Linux experience on my phone as good as GNU/Linux on my PCs (but tailored to the workload that I use my phone for, of course).
Why are you generating apps? Sounds like you need a website. Do your apps use the camera, accelerometer, AR, ML GPS or any other parts of a device? Or is it just a website with the cachet of being “an app.”
> You might wonder, “Why even put your app in the app stores? Just live on the opened web!”
> The answer, in a nutshell, is because that’s where the users are. We’ve trained a generation of users to find apps in proprietary app stores, not on the free and open web.
Also from a user's perspective, I'd prefer everything that doesn't need to be a native app to be a pwa. They are much more lightweight and more limited in permissions. Probably those apps don't need to be submitted to the store either, except for discoverability (users are now used to search for apps on the store)
> There is a reason the Microsoft Store and Google Play are absolutely filled with trash
So is the iOS App Store. If you dig past the first few search results you find tons of trash. But I'm not sure it matters how many low quality apps there are overall, as long as the store does its job of showing me the good ones first.
Yet most of the apps in the AppStore are absolute crap. Add to that the useless search. OTOH, many students or open source developers may want to try offering free or cheap apps of ok quality, but they are disincentivized by the cost.
The reason you don't like app's developed in a certain technology is because you are a developer. Normal users can't tell the difference, or don't care.
Gosh darn the cognitive dissonance!! The free market and users are completely capable of choosing quality apps, iOS/Apple needn't babysit, nay play brainwashing big-brother-evil-megacorp strangling competition/dissent, them in the process.
"If your project is more than a hobby, you ...."
Yes yes - if you're serious about your project, you'll willfully submit yourself to anal-probes by monopolistic mega-corporation that has inserted itself as the gatekeeper to running software on one's own legally owned hardware - which, in the history of computing, is a first.
When was the last time you let your refrigerator manufacturer tell you what items are allowed in your OWN FUCKING refrigerator? Why is different for iOS/Apple?
> When was the last time you let your refrigerator manufacturer tell you what items are allowed in your OWN FUCKING refrigerator? Why is different for iOS/Apple?
Well, if the things I put in my refrigerator started acting like malware, I think manufacturers might start taking a different approach...
But 99.9999% of app store rejections aren't malware related. It's a scapegoat reason of convenience, but not the real reason, v.i.z. Apple's insatiable monopolistic ambition of totalitarianism, of cock-blocking freedom on their devices.
Ironic that you accuse someone of being a cock-sure know nothing asshole without a shred of evidence that app store rejections are somehow malware-deterrence driven.
Unless your vitriolic rant arises from some jingoistic fervor for Apple, and it bat-blinds you to Apple's totalitarian rules of engagement, the evidence is really, really apparent!!
Or maybe you really enjoy the Stockholm syndrome of Apple telling you want apps you can and cannot run on your iPhone. And you really crave for your Mac to get locked down in a similar fashion, in some sadomasochistic homage to your tormentor. But hey, whatever floats your boat.
> The free market and users are completely capable of choosing quality apps
You should get your ideology out of the way. Apple's customers generally expect Apple to curate its App Store and expect Apple to not allow malware in its App Store. This is true for Google Play and the MS Store, except that they are in a poorer position to demand greater scrutiny for its developers, and are lousier app stores for it.
TL;DR: an app store is not a government, it is more like a mall: its patrons expect it to exercise some oversight ensuring that its vendors don't sell lemons.
I suggest you get your ideology of rinsing and taking deep enemas in Apple's P.R. out of the way.
There's ample evidence against your fictitious arguments - if indeed Apple users LOVED the app store, the Mac app-store would drastically eclipse the traction of non-app-store-ed apps. Which clearly isn't the case. Q.E.D
Also other commenters have mentioned he’s on 15.4.1. That’s two major iOS versions old. It’s possible they’re just on an iPhone 6S/SE/7 which was capped at that version, but a jailbreak is likely.