> From minor things like “iOS Safari won’t let you play audio without first interacting with the page” to major, show-stopping things like, “iOS Safari won’t let you play the next song if your app is in the background or if your screen is off.”
I disagree that these things are purely because Apple wants your $99/year. Maybe that's part of the story, but not all.
I am glad that websites cannot play audio without the user first interacting with the page. I am also glad that websites can't play audio in the background — as a user, I would find it too "buried" behind Safari and I wouldn't appreciate the feeling that a website was running in the background. (Yes I know you can control audio via the Notifications Center and Control Center.)
I appreciate that these permissions are reserved for apps that Apple has vetted, even if this is a pain for developers and they are not a perfect institution, as a user I appreciate that they are trying to maintain quality and encourage good app behavior.
I'm glad your app had to jump through these hurdles to gain the functionality your users wanted. Like you said, it's where the users are they were asking you directly for it. These are higher-level permissions and should not be free for the taking.
> as a user, I would find it too "buried" behind Safari
How is this any different than music playing on say Google Play Music on my iPhone? I listen to music from YouTube, iTunes, iHeartRadio, Google Play Music, Pandora, and other apps occasionally. Why don't I feel it's buried in those situations? Because of the simple reason that Apple allows only one source of audio on iOS at any point of time (including Safari), which can be controlled from Control Center. Control Center also displays the app, and tapping on it, takes me straight to the app.
There is no reason a tab on Safari couldn't similarly queue up a playlist, and if I want to get back to it, I go to control center, and tap the safari icon which takes me to Safari and the tab playing the music.
Now I don't think Apple prevents this out of malicious reasons. It's likely a vestige of their older restriction mechanisms which they haven't gotten around to changing because most people do in fact just create apps for things like music playlists.
But I seriously doubt there is any good UI reason to prevent a tab in Safari from queuing a playlist, any more than there is for preventing native app from doing so.
>How is this any different than music playing on say Google Play Music on my iPhone?
Because when I'm browsing the internet, random websites don't use Google Play Music as an attack vector for some autoplaying video that I never asked to see.
From observing non-techy people it's because of intent. When you go to YouTube or Pandora or whatever you intend to make your phone make noise. When you follow a random link from your Facebook news feed on to an unknown website with a 'funny' article you don't. This is why autoplay videos are now blocked from playing audio as well.
This can't be resolved with a confirmation dialog as people don't read those either.
I do hope Apple add support for PWAs in the future, though perhaps with some very guarded APIs available to avoid exfiltration of contact lists and excessive background work etc.
The only way I think this could be done is to only allow autoplay for webpages that have been added to the homescreen. Allowing background play for tabs in Safari would be insane and I hope that will not happen.
Android w/ Chrome will keep playing audio for a website when I lock my phone (I use it here: http://listentothe.cloud/), and the pause / play / skip controls are available on the lock screen. One touch required to pause it, same as any native music apps.
It's super convenient and I'm surprised iOS doesn't offer the same? Seems like a no-brainer no-risk feature to me.
Agreed that apps (web or native) shouldn't have free access to e.g. your contacts without permission.
But Apple goes beyond security and actually makes it impossible to build first-class experiences for iOS without paying $99/year + 33% in-app purchases. I think that's unfortunate.
The free and opened web presents a challenge to Apple's app business. They have a perverse incentive to keep web apps second-class citizens on iOS. And this is a major reason why iOS Safari has become the new Internet Explorer 6.
> The free and opened web presents a challenge to Apple's app business.
The free and opened [sic] web is BS. The "web" was always free and open, if you had worthy and user-respecting stuff to publish. Autoplaying video and other similar features are just plain evil. And if web apps are second class citizens on iOS, that's really a nice thing to hear, IMnsHO, because they are second class citizens on the WWW itself. They are either castrated versions of the native applications they are pretending to be, or overtly bloated thin clients (i.e. glorified <form>s) anyways. There has been one web app that I've used and liked: the old Gmail app.
The requirements of the platform are quite clear, and the service in return is quite desirable (apps being reviewed before publishing, user-centric permissions scheme, etc.) and even though I don't own an iOS device ATM, it sounds quite desirable to me, at least over Android where there is a hundred million billion versions of the OS out there and nobody bothers sending update my way so that I can has some granular control over what I allow the apps do. If you don't like it, don't take it. And it's nothing like IE because nobody has to use iPhones whereas Microsoft had put its OS and its browser on almost every computer out there, and I bet older IE browsers still have more market share than the sum of devices online with Safari installed. They are just a little island of the technosphere that want to get what they paid for, and enjoy the web like it was meant to be, possibly; and I'm just like them with my Qutebrowser where I have to disable JS and maintain a whitelist because the free and open web. Gosh.
The free and open web is BS? Well, I disagree. That any person with the will and the skill can publish something for all the world to see, without the need for gatekeepers? That's incredible freedom the world has never before seen.
>> "Autoplaying video and other similar features are just plain evil."
I'm not even asking for that. My app is a music player in the vein of Pandora. iOS Safari doesn't let me play the next song if I'm not in the fore. Apple has acknowledged this is an issue; maybe they will fix it in a future version.
iOS Safari: As someone who has supported a web app (now PWA) for 7 years on iOS Safari, I say with knowledge and experience that yes, iOS Safari is the modern IE6. I say that because it is the slowest to adopt standard web features, and the reason for doing so is a business one. Both reflect 1990s IE and Microsoft.
You are confounding things here. The actual free and open web is certainly one of the best things ever. But all the app ecosystem we have built on it, the insecure and wasteful universe of web apps, and all the cruft that is created to support them in the name of free and open web, none of them are necessary for tye web to be free and open. Is the open web this whole business of tracking and data ransom? No. It is the content that people publish, and it needs only a fraction of all this complexity. The rest is the closed web. Nobody bars anybody from publishing proper application software or make usable web applications that do not require clients to have software that takes hundreds of megabytes on disk and multiple gigabytes on ram.
In thr nineties MS had almost 100 marketshare in consumer OS market. How much does Apple ecosystem has now. MS and Apple is incomparable in that you can prefer to not use an apple device, but for a long long time you could not prefer to not use the MS software, whatever consumer hardware you had.
Author here. I'm not making any money on their platform. I'm a non-profit, building a free app; this isn't about money.
I mentioned money in the post as a list of all barriers to moving a PWA to app store. $99/year + 33% in-app purchases (plus a $1000+ Mac to build, and probably one or more Mac minis for CI) is a barrier.
The bigger concern is Apple is lagging behind on web standards. I suspect the reason for that is because web apps undermine their app business; this is a replay of the 1990s when Microsoft lagged their browser behind web standards, knowing it undermined their business.
So, keep your violin, brother. :-) My post wasn't a complaint, but a documenting of the hurdles involved in moving a PWA to the app stores.
Just a note on style--your post reads as a complaint, whether you intended it that way or not. The strong editorial slant actually undermines the meat of the article for me, which is, as you mentioned, documenting the hurdles in publishing a PWA. You could make this a better resource by stripping out the overt anti-Apple editorializing. Let the facts speak for themselves--for those who agree with you. Which I don't. Apple is choosing a deliberate strategy here that privileges users over developers. You prefer that they privilege developers over users, but that's hardly a universal position.
> Apple is choosing a deliberate strategy here that privileges users over developers.
What is stopping them from doing both?
There's no reason developers should jump through arbitrary hoops to make their applications available to users. Yes, quality control, security, etc. is very important, but the publishing process should and can be as user friendly as their platform claims to be for end users, and that is what the article is showcasing.
FWIW I didn't notice any bias against Apple in the article. Just a lot of understandable frustration with their processes and platform.
There are two different arguments here, one very common and long lived that Apple is good at protecting users, and the other that Apple is not prioritizing the process for web developers. Maybe you are conflating them?
I don't think I am. I'm suggesting that much of what the OP takes as not prioritizing web apps is part of a deliberate strategy to protect users. I certainly could be wrong about Apple's motives, though.
So the only thing that applies to you is the price to have access to a Mac. Since you're a nonprofit, Apple will waive your developer fee, and you wouldn't need in-app purchases anyways. Also, IIRC the cut Apple takes is 30%, not 33%, in line with the rest of their App Store policies.
And it certainly doesn't mean it's not about money. Depends on the business, of course, but I've seen non-profits that pay million dollar salaries to employees and put millions in the bank as reserves. Fine with me but business is often about money; non-profit or otherwise.
That's what I get for reading the comments before reading the piece, sorry.
I'm still uncomfortable with the extent to which Apple's walled garden is walled though. 25 USD/month does add up, even if you unsubscribe during months where you aren't using the service.
I have an account with them to do testing on different versions of macOS than the one installed on my development machine, and it only costs a few dollars a year.
Author here. That's correct - Apple waived my $99/year fee. I documented that in the post. But my post wasn't about me, it was about the hurdles involved in getting a PWA into the app store. For many people, $99/year + 30% in-app purchases + $1000+ Mac for build and testing + a few Mac Minis for CI servers ...that is a barrier.
If you're of the scale where you need several CI servers for a platform, buying a computer for that platform should be a requirement anyway. The IAP cut is only an issue if you're making money on the app.
BTW, the best solution for your case is VS App Center (https://appcenter.ms), which has a free tier and does CI/CD (on Macs) across platforms.
My understanding is that service workers have buy in from all four major browser vendors now, with implementations in all of them. I haven’t played with it yet but it seems like service workers are here to stay
He doesn't want app store. The whole article is about how the author is forced to submit an app to the store just to allow playing audio in the background.
The author would prefer to just have a web app / website that plays audio, but it is not possible. On iOS, apparently you need to use Cordova and submit an app to the store if you want to play the next song while the app is in the background. And it is not possible to use lock screen controls to control playback (apart from stopping it).
Author here. I'm with you for random websites. But what about apps that are media players, ala Pandora? My app is a music playlist/radio station hybrid. It's expected to play music; it's the whole point of the app.
iOS Safari doesn't let me play audio until user interaction. OK, that's fair.
But it also blocks me from playing the next song when the current one ends. That's not cool. It breaks my app. It forced me to bundle my PWA as an app in the store, just to get around this restriction.
FYI, I reported this problem to Apple's iOS Safari team. They acknowledged the issue and said they can probably fix it in the future. (That was 2 years ago.)
I think you misunderstood something. Websites can play audio in the background on iOS. It works great for podcasts — but only as long as you don’t want to control playback. The API is there, Apple didn’t omit it on purpose. But it is broken.
Also: the author makes the point that mobile users have been conditioned to look in the app stores for stuff to use on their devices.
In other words, having a presence in app stores is important to marketing. And indeed, his new users per month rate went up after he listed in the actual app stores.
And nowhere did I say it was. The fact is every company hopefully has a business plan to be profitable the numbers show that Apple has one of the best business plans to do so.
This is a ridiculous comment unworthy of this community.
Safari doesn’t follow web standards that other browsers follow. That’s worthy of frustration. If they build a browser, they should implement standard APIs.
Yes but given the current state of the App store, with the minor obstacle that is the $99/year, I hasten to imagine what the state of it would be without it!
Are you glad that Safari for iOS (and its web views) don't follow the standards? For example you can't set the height of an <iframe> which is something that has been been possible on every browser since IE4.
I agree that a browser should not be able to access native resources (in mobile nor desktop) but the problem with Safari for iOS goes way beyond that.
I won't claim to know Apple's motivation for not treating web technologies as first class citizens on iOS, but I know for sure that this situation is completely intentional. Apple has the resources and talent to make this happen and this problem has been a constant for years.
Safari has been neglected to the point where reported bugs linger for years, and when reporting a bug the most common answer is silence. The project is seriously underfunded.
Such vetting is not needed for an action such as playing audio in the background. That is harmless and only needs to be a permission the user chooses to allow when visiting that page.
Thank you. I came back here to specifically higlight that bit because Jesus Christ guys you can’t ask for ads that don’t auto play and complain about this thing at the same time.
“The vendor should figure out what I want” is a really easy thing to say...but this is how they’re doing it!
At the end of the day if you want a tiered permissions model you need a strictly tiered authorization model. Right now you implicitly authorize an app/website/service/whatever to do certain things by explicitly installing it as an app. On desktop, web apps explicitly require your authorization for things like pushing notifications (isn’t it weird that EVERY WEBSITE wants to push notifications now?) or using your location data.
> I am glad that websites cannot play audio without the user first interacting with the page. I am also glad that websites can't play audio in the background...
Websites yes, but if you choose to "install" a webapp to your home screen, it still cannot ask for or get these permissions. Not that users ever do install apps without app stores, but that's another story.
> These are higher-level permissions and should not be free for the taking.
But there has to be a balance though, right?
Steve Jobs called the computer a bicycle for the mind, but actually deploying simple apps can feel like a mousetrap for the soul - it crushes your will to create.
> I am glad that websites cannot play audio without the user first interacting with the page. I am also glad that websites can't play audio in the background
> These are higher-level permissions and should not be free for the taking.
While they shouldn't be available to every site, these higher level permissions should be request-able by a PWA with the option to grant that permission indefinately. Apple is deciding they know better than me and providing me no choice. This sort of crap is why I don't own an iPhone.
Requiring developer to buy a Mac and pay $99/year to play audio in the background is developer-hostile in a way that is not user-friendly at all.
It used to be fairly common in Android for developers to just request everything. Developers still request too much, but it's gotten a bit better because in newer versions of Android you have to actually start using the API before the permission will be requested - so as a user if you request microphone access, I know it's because right now you intend to record sound.
It's a very small improvement, but it helps, and it's pretty much copied wholesale from web's permission model. The web also allows you to grant parts of permissions. When a website asks you for location and camera, you can choose to give it just camera - or you can choose to give it camera for one session and then re-ask the next time the API is accessed.
These are all small steps that make it cumbersome for developers to just say "give me everything or nothing works." The trick is to make it easier for app developers not to think about permissions; and then when you get an app that requests 3 permissions upfront, you know something shady is going on because there just aren't a lot of legitimate reasons to do that anymore.
Yeah, exactly. This works pretty well with location tracking -- few people request it, you can deny the request, and things almost always work fine when you do. (I've had one site lock me out for blocking location data, and some things work poorly on Facebook's mobile site without location tracking on, but I haven't noticed any other problems.)
You can be just as user-friendly by giving the user a button "never let web pages ask me again for this / all permissions (you can undo this in settings)" when the first page asks for permissions.
Every webpage and their dog has now started to ask for permissions to popup notifications. I find this really annoying. Sure, I can disable it for one site, but then the next one I visit pops up the same question if it's OK to spam me.
I've turned it off browser-wide as a result.
If asking for permissions is to be an option in the future, I hope it is a completely manual opt-in, available in some kind of site-specific settings thingie (that makes no effort to distract the user by noises, popups or red badges by itself).
I think this is reasonable given the ratio of sites a user should be willing to grant any permissions to, vs the amount they should want as sandboxed as humanly possible.
:) Browser permissions are also ahead of mobile on this one.
What they're starting to do is force some permission prompts to be behind user actions - so, you can request a permission as a response to a user clicking on a specific type of button, but you can't just request it anywhere.
A big reason notifications are spammy is because they don't have those restrictions, I suspect because <tinfoil_hat>Google was heavily involved in their design.</tinfoil_hat>
I suspect that browsers will start to move in the direction of "let the user turn this on via a button someplace" as notification prompts become more common. And I suspect that, like with everything else, those controls will get implemented on the web before mobile.
You're upset that every website can ask you to display notifications. With native apps on Android, they don't even need to ask. Apps I install are by default allowed to spam me with notifications, and I have to opt-out after the fact.
If we're comparing permission models between native and the web, the web is definitely giving users more control right now. I don't understand the perspective of someone who feels safer downloading an app than they do visiting a website.
iOS's permission model is the web model. Your app requests notifications and a user prompt pops up.
It's even advised by a lot of devs on iOS to copy the web's dark pattern of putting up a dummy permission request before requesting so that if the user says no you can re-request in the future.
True enough, Apple's ahead of Android, because there is at least a permission, but they're still behind the web, because there's no setting to universally block all apps from requesting notifications (at least none that I can find, correct me if I'm wrong).
I've yet to see a permission scheme on a mobile OS where I felt like it was ahead of the web. The point I was making was (at best) native permissions are keeping pace with the web, but they certainly aren't surpassing it and the dominant platform in the space is significantly behind.
That's what I said though, you are given the option to opt out entirely, or it could be the default as you said. This can be as fine grained as necessary so it is not intrusive but still allows you to use features if you choose so.
What I object to is the Apple approach to simply take away the option whether you want it or not. It's not user friendly at all, it's patronizing and stifling.
If they want that permission before loading the page/app, they should ask. If they don't want to annoy their customers, they should wait until they need each permission.
> I am also glad that websites can't play audio in the background
If you're saying that web pages should not be allowed to even ask for permission to play background audio, then I disagree with you and Apple 100%.
Nobody should be arguing for anything less than user-controlled choice in the matter of permission to play audio on a website, in the background, any way you like when permitted by user. To deny even the choice, is to feed and validate the theory that Apple has no interest in improving the browser experience because they want to keep that bar low by design, much lower than apps.
> Mobile platform vendors, like Apple, are totally cool with apps that use your phone to its fullest. Access your location, play background audio, get your GPS coordinates, read all your contacts, play videos or audio without app interaction, read your email, intercept your typing, play more than one thing at a time, use your microphone and camera, access your pictures, and more. Apple’s totally cool with that.
Apple is certainly not "totally cool with that:" each of these features comes with strings attached. For example, apps are forbidden from attempting to de-anonymize users via facial recognition.
On the app store, abusive apps can be removed; there is no equivalent enforcement mechanism on the web. This IMO is the primary reason for restricting these capabilities to reviewed apps. Though the fee may be a secondary reason.
99% of websites do user-hostile things, like track users. What will prevent PWAs from extending this to e.g. ultrasonic beacon tracking? Honest question, it's important that it gets solved.
Partially agree. I understand security concerns; we shouldn't allow random web apps to freely access privileged operations, for example. (Should we allow web apps to ask for permission? That is another question.)
But stopping web apps from working? For example, breaking open standards like "you can't play more than one stream of audio", or "you're not allowed to play audio if your app isn't in the fore"? Nah, that's nasty. It gets worse. iOS's new PWA support actually reloads your whole page - losing all context and execution - every time you bring it to the fore. It kills all execution when putting the app into the background.
This is beyond security; it is actually hostile to users and developers.
> iOS's new PWA support actually reloads your whole page - losing all context and execution - every time you bring it to the fore. It kills all execution when putting the app into the background.
There's a bigger story to this, one could assume.
I'll be the first to say that iOS and Safari (particularly on iOS) has generally lagged behind the community in adopting standards. But this seems like a feature, not a bug, to me.
What if the user has 10 PWAs open in Safari? Should they all maintain state as the user goes elsewhere in the OS?
If I put an app into the background, I want it to stop its execution, unless I've given it permission to do a limited set of things. This goes double for websites — no way do I want them to continue using the OS in the background.
Imagine if you install Pandora as a PWA. It's now on your homescreen. You launch it. You start playing some music. Now you switch over to Twitter. Woops! The audio stopped playing. You bring Pandora back to the fore. It reloads and starts playing a different song.
Worse, there's no way to fix that. That's how it's supposed to work.
Imagine you install $ANYTHING as a PWA. It's now on your homescreen, you launch it. You do $THING. now you switch to twitter. Now the PWA -- in the background -- loads some ad with an autoplaying video and now theres ad audio coming from ... well, you're not sure where, but it doesn't seem like it's coming from twitter. now you have to go find it and stop it. Meanwhile bitcoinminer.js is burning through your battery in the background because those video ads just weren't quite enough revenue.
Stepping back a moment, it's worth noting that this was Steve Jobs' original vision for the iPhone:
“The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.”
Here we are, a decade later, and Apple has not only abandoned that vision, they are actively working against it by preventing web apps from becoming first-class citizens on their platform.
I mean, consider an app that does 2FA. "To sign in, please enter the code sent to your mobile device." You switch over to Messenger, and...wooops! Your app just reloaded its home page, and the auth prompt is gone.
Surely, any rational person can see this is too restrictive. Perhaps Apple will loosen these restrictions in the future.
Yes, as you point out, there is the potential for abuse. But that's already there with native apps. The things you just mentioned can -- and have -- been done with native apps.
So now there's some awesome PWA api giving you all those native features, and a permissions model, and so you install SUPERPHONE app, and that needs access to your contacts and to make and receive calls, and you say "ok, yeah this is a better phone app so those are reasonable".
Now everything running JS in the context of $SUPERPHONE_DOMAIN or whatever has these new permissions. superphone pwa's calls to window.PwaGetContacts() and window.PwaMakeCall() work and everyone's happy, and your phone really is super now. the app shows a banner ad from google and you're cool with that because it was free, and hey, developers need to eat too.
Someone who makes ads figures out that ads can run JS. So your app pulls down an ad from some ad network and that ad has some cool JS that detects that those functions are available and starts calling all your friends from your phone and telling them that "`window.PwaGetOwnerName()` is really excited about LinkedIn and wants you to be their contact" after uploading your contact list to every 3rd party data broker that would pay for it.
well, that sucks, maybe there's a better way to limit the code that can run on your phone with specific permissions
> it's worth noting that this was Steve Jobs' original vision for the iPhone
One which they quickly backtracked on after realizing that it needlessly restricted what apps could do, and one which they could not shoehorn security into.
That vision was abandoned while Jobs was still around. It was a way to bootstrap the first wave of apps but Apple’s principles of quality and security mean it’s not feasible. I’ll be really disappointed if they give in to the PWA movement and sacrifice those principles.
I don’t quite understand what the issue with native apps is in all honesty?
If I wanted functionality past the most basic kind, then I would use the full, native app.
Web apps are not a sufficient replacement for a proper application and if a developer can't be bothered building an app properly then they shouldn't be surprised when I don't use it.
Ok, put it this way: they should be sabotaged if they're never going to be as good as native apps. Seeing as they're not going to be, and Apple has standards for how it's phone behaves and the quality of the ecosystem, I have no problems with them essentially insisting that developers build proper apps.
They're never going to be as good because Apple is sabotaging them. A web app has many advantages over a native app. That is why people visit websites instead of installing an app for every website.
Almost literally by definition, a webapp isn't going to be as good as a proper application.
If one of the advantages is "front end guys don't have to learn another language" I'm starting to be of the opinion that that's their reticence to use the proper tools, rather than the inherent superiority of JS.
People visit websites because many of them don't need to be apps. I don't need an app (webapp or otherwise) for each of the half/dozen sites I visit once a week. That's just clutter and wasted space, and in the case of a web-app, clutter, wasted space and a shitty app that's no better than simply visiting the website directly.
> For example, breaking open standards like "you can't play more than one stream of audio", or "you're not allowed to play audio if your app isn't in the fore"?
What standard requires these things? And even if one does, it's not clear that users would be well-served by that standard.
Apple has a rich native API for background audio playing, which covers things like whether the output stream should mix with other apps, what should happen on route changes, etc. AFAIK the web audio specs are much weaker, so Apple is going to make the most conservative choices here.
> iOS's new PWA support actually reloads your whole page - losing all context and execution - every time you bring it to the fore. It kills all execution when putting the app into the background. This is beyond security; it is actually hostile to users and developers.
"Hostile" is much too strong. We don't know what's a deliberate decision, and what's just a limitation of the first iteration of this stuff. And as a user, unrestricted background JavaScript execution sounds horrible to me: I definitely do not want that on my iPhone.
Apps on iOS are only allowed to execute in the background in controlled ways, and there's no web APIs providing similar coverage, outside of Service Workers. So what do you think Apple should do here?
Two points I guess:
1. Native APIs will always be more capable, and have better platform integration, than cross-platform layers built on top of them, including web APIs. It's specious to build on a non-native API and then complain that its capabilities and platform integration are inferior to native.
2. Every tiny piece of web capabilities gets used in a user-hostile way, that is hard to anticipate. For example, AudioContext's authors did not anticipate its browser fingerprinting uses. PWAs invite more of this stuff into my devices. Apple is right to be very conservative with what it allows these apps to do, at least initially.
- Support service workers on PWAs that Safari has added to the Springboard.
- Support permissions-based model for reasonable user-facing features like background audio and camera.
- Don't reload application context when backgrounding PWAs; this doesn't happen if you run the exact same page in Safari-proper.
It's really not hard... Apple has had longer than Google to do this right and has repeatedly chosen to not add mobile APIs to Safari until the 11th hour, which only hampers adoption and makes them take longer to get to the 11th hour in the first place.
> It's specious to build on a non-native API and then complain that its capabilities and platform integration are inferior to native.
It's not, however, specious to compare to non-native APIs on other platforms which is the point of this entire article.
> Apple is right to be very conservative with what it allows these apps to do, at least initially.
The problem here is that last part, the fact that iOS has severely lagged behind in open web API adoption for the better part of its existence
Mobile Safari's support for modern web standards has made IE look good for some time now. It seems very clear that Apple doesn't want a good experience for web users on its devices.
It's very frustrating, because we keep getting requests from users for features we're happy to look into or even already working on... but then discover the user has an iPhone, where the necessary web technologies are supported poorly if at all.
Unfortunately, since Apple also won't let anyone else supply a real browser to run on its devices, there's also no meaningful competition to force them to do better. Maybe monopoly/anti-competition regulations should be adapted so the same principles apply to platforms in this sort of controlling position.
Unfortunately, since Apple also won't let anyone else supply a real browser to run on its devices, there's also no meaningful competition to force them to do better. Maybe monopoly/anti-competition regulations should be adapted so the same principles apply to platforms in this sort of controlling position.
Apple only controls 12% of the smartphone market[1]. This is like asking that Porsche be regulated for not offering a color you want and they have a monopoly on selling Porsches.
It seems more like saying Porsche can't dictate to garages that they can only supply Porsche spare parts and even then only if they become a Porsche dealership, despite someone else's competing part performing better.
Say Porsche implemented something in the cars firmware that did just that. Porsche in the car market, like Apple in the smart phone market, isn't even remotely close to monopoly, so regulation would be extremely heavy handed and unwarranted.
You as a developer could apply pressure by not supporting iOS. You said yourself in another response your app is very niche and has no competition, if you supported Android only your customer's would also have the opportunity to vote with their dollars and switch to Android.
Inconvenient browser selection on one platform is a problem the market can fix, the government isn't needed.
Most web technologies are supported by Safari.it has lagged behind other browsers for a while - not terribly so, but enough that it can be a little annoying at times. But the comparison with IE (or rather Edge now) is just wrong by an order of magnitude.
Really? Let's look at some specifics around PWAs and media content.
Mobile Safari has historically set relatively low and hard limits when storing data for offline use through the various relevant APIs. This is a much more significant limitation in a world of offline-friendly PWAs.
HTML video elements have had so many problems it's hard to keep track, from relying on a broken plugin that didn't do things like sending cookies properly with requests, through to refusing to play videos in-page on iPhones.
Mobile Safari has stuck with only playing H.264 videos even as every other major browser supported open standards.
Obviously IE is no longer developed and doesn't support modern PWA APIs, but even IE had better support and more compatibility with some of the other modern web APIs than Mobile Safari.
The problem is not only that it has lagged, but that it doesn't conform to all standards.
Something that hit me hard a couple of years back is that in Safari for iOS you can't set the height of an <iframe>. Any browser back to IE4 can do this.
It isn't Apple that needs to do better for its users the developers need to invest the time and resources so that the users have the best experience. If you aren't willing to offer it, I'm sure someone will.
If you aren't willing to offer it, I'm sure someone will.
Given that some of the services my businesses offer are in various niche markets, and as far as we know they are totally unique and have no direct competition after several years on the market, apparently you are mistaken.
No doubt, but I've done this a few times now with a few different businesses that are still going several years later, so I'll take my chances. :-)
But seriously, there seems to be this almost universal assumption that if a market is worth serving in business, there will always be competition. That makes little sense to me, because if the modern online world has taught us anything, surely it is that our societies are incomprehensibly diverse and have countless niche interests and small communities within them.
Those in turn create countless business opportunities, as long as you admit the possibility of smaller businesses that serve such markets in some useful and commercially viable way yet have no hope or ambition to become the next unicorn. The most profitable things I've worked on typically weren't in that category, but most of the best-received things I've ever worked on were.
But sometimes that sort of market is only big enough for one player to really do well, or maybe there's only one player willing and able to invest in setting something up to cater to that particular market anyway.
It's quite contrary, actually - apple provides good experience for its users - tightly controlled, secure sandboxed environments. The fact that you find it hard to develop apps for it is irrelevant for them.
Clearly what some of us call a good experience differs from others.
Customers who visit some of my sites on Android devices get useful facilities that customers who visit the same sites on iOS devices do not. This is a direct result of Apple's failure to support functionality in Mobile Safari that is available in other browsers and its policy of blocking any other browser from doing better on its platform. I don't really see how you can spin that as being a better experience for iOS users.
The implicit assumption made by a few contributors in this discussion is that if PWAs don't work properly on iOS then developers will write native iOS apps instead, but often a more realistic alternative is that developers just downgrade their expectations on iOS and concentrate on providing more value on better platforms, with the iOS users losing out.
I doubt that comes into play. App review by humans quickly becomes more expensive than that $99 per developer per year, certainly when one submits multiple applications multiple times a year.
The 30% cut on sales, on the other hand, does bring in significant money, even for a company the size of Apple.
Author here. Thanks all for bringing this to the HN front page.
The jist of the article is getting a PWA into the app stores is harder than it needs to be, especially on iOS. Between Google, Apple, and Microsoft, I found Google's Play Store to be the simplest and quickest store to get a PWA published in.
Another interesting bit is that web technologies haven't caught up to native. My PWA isn't super complex -- it's a glorified music player -- and yet integrating into the OS (now playing song on the lock screen, for example) was painful and non-standard, particularly on iOS.
All that said, I'm quite excited about PWAs. I think they will win in the long run, and will eventually (~5 years) become the dominant type of app in mobile and desktop app stores.
I think they will win in the long run, and will eventually
(~5 years) become the dominant type of app in mobile and
desktop app stores.
Am I the only one who remembers people saying this EXACT thing about Java Swing apps? Not saying it's impossible, but "Write Once Run Anywhere" has been a mirage "just over the horizon" for a long time.
You're right that mobile did help kill plugins. But that was the final blow; HTML5 had already disrupted native apps on desktop OS for a few years, and as browsers picked up HTML5 support, there was almost no need for plugins.
(I say this with first-hand knowledge: several years ago when plugins were still common, I gave the final talk to a Silverlight user group in Minneapolis, in which I told the crowd there was simply no reason to continue using plugins. HTML5 won, and mobile only finalized its success.)
Just as open web technologies ate Microsoft's lunch, undermining the domination of Windows, I predict the same will be true of the Apple (and Google) app ecoysystems. More and more, operating systems are simply environments in which to run web browser. I believe this trend will continue.
The original iPhone cams out in 2007. Flash and Silverlight was still big.
As late as 2010, Apple was still getting beat up about the iPad not supporting Flash.
HTML 5 was not popular a "few years before 2007". Android users were still touting being able to (barely) use Flash as late as 2010.
It also wasn't "open jtechnologies" that caused Windows to be less relevant. Windows still commands 85-90% plus of the desktop. Mobile caused the desktop to be less relevant.
> I am predicting the same thing with regards to native mobile apps: they will largely disappear, and web apps will again win.
But, how do you reconcile this belief with the ample evidence you offer that Apple/iOS are dragging their feet and are resistant (for whatever internal reasons) to letting PWAs offer a first class experience?
In other words, what forces, in your view, will eventually bring Apple over to full support for PWAs?
In the article: "Aside: I guess Apple won’t let you submit an app unless you have a registered, legal company?"
Although it does seem to be this way, you can submit an app to the store without being a registered, legal company. The most common route is to just mark yourself as a sole proprietorship using your own name. No need for an LLC or anything. However, this may vary from country to country.
This is correct, but you must list your full legal name as the store listing, which isnt very ideal in my opinion. In order to list it as a business name you need an LLC or more. No Sol Proprietors allowed.
I've been using it on Android for a while. It's not perfect, but it's definitely good enough. There are still plenty of apps where I'd tell a CEO, "No, we really need three sets of client developers," but the number is certainly dropping over time.
I tried it just now. When I put my phone into airplane mode it just shows "Twitter is taking too long to load", I do have iOS 11.3 so service workers should handle this.
I think PWAs will win in the long run, regardless of WebAssembly. Both are exciting technologies, though, and WebAssembly will help bring performance in line with native.
I answer that in the post. The short of it is, because 1) that's where users look for apps and 2) Apple greatly restricts web apps in Safari. So much so that to be first-class citizen, you need to be an app in the store.
I describe that in the article, but here's the short of it:
iOS: You have to use Cordova plugins. I used RemoteCommand[0] and NowPlaying[1] that lets me write JavaScript that calls into native iOS functionality. Once the Cordova plugins are installed, you write JS to talk to them. Source code for that here[2].
Android: Google has submitted a web standard[3] for this. Integrating with it is simple[4].
Windows: Microsoft automatically injects the Windows API into the JS global namespace. So you write JavaScript that looks like window.Windows.Media.SystemMediaTransportControls.doSomethingHere(). You can see the code for that here[5].
Thank you! That was very informative (sorry for only skimming the article earlier). So Android and Windows don't require a wrapper, but iOS needs Cordova. I'm sure iOS will catch up soon enough...
It's possible. But you currently have to write code for each platform; iOS uses a Cordova plugin for this, so your JS has to talk to Cordova. Windows uses its own proprietary namespace which is injected into your app, so you write JS that talks to the proprietary Windows API.
Google is the unique bright light here. They've submitted a web standard, navigator.mediaSession [0], that lets you do this in a web standard way. Unfortunatly, the only browser that implements it is Chrome on Android.
Why build an app and not just live on the web? I answered that in the article, 2nd paragraph. The answer is two-fold:
1. That's where users are. We've trained a generation of users to find apps in app stores.
2. Some mobile platforms (read: iOS) are hostile to web apps. For example, Apple doesn't let you play audio in the background on iOS. (Or rather, they suspend JS execution if the web app is in the background, or if the screen is off. Thus, you can play exactly a single MP3, then my media player app will stop playing music unless it's still in the fore, which is a show-stopper.) This is just one of dozens of issues with web audio in iOS Safari; I've documented more here[0].
Native apps have no such restriction. Thus, packaging my PWA as an app got around all these restrictions. Plus it lets me integrate with the OS, for example, by showing the currently-playing song name, artist, album, art, etc. on the lock screen.
> I'm OK with that. Web apps are clunkier and provide a worse experience. That Google makes this easier speaks to the sort of UX you get with Android.
Chicken and eggs argument here: web apps are clunkier and provide a worse experience because they are not well supported by the OS or the OS does not provide better support for web apps because they provide a worse experience?
Hybrid app frameworks exist because phone operational systems lack proper support for web applications.
> web apps are clunkier and provide a worse experience because they are not well supported by the OS
No, they are clunkier and provide a worse experience, because most "web apps" are ported version of desktop bloatware, targeting devices, permanently plugged into wall-mounted electric outlet.
What are "web applications" anyway? Something, that requires permanent internet connectivity? Something with DOM APIs? Something with built-in Javascript interpreter? Something with CSS support? The defining qualities of "web" have absolutely nothing to do with mobile devices. If anything, "web" has bad supported for OS. This is why all hybrid frameworks are about exposing additional OS functionality to browser, not the other way around.
Just accept, that you are looking at wrong tool for the job.
I will not debate whether "web apps" are ported version of desktop bloatware but I don't see why you can't write offline-first, mobile-first progressive web applications using Javascript and HTML (except Apple's lack of enthusiasm supporting anything outside their walled garden)
I understand lock downs for security or user experience (e.g. disallow sites to auto-play video, etc). But restricting web apps to the point they're actually broken? No, that really sucks. Shame on Apple.
And if we care about freedom and the opened web, we should not cheer on proprietary, closed platforms like app stores. We should want the opened web to win.
> I understand lock downs for security or user experience (e.g. disallow sites to auto-play video, etc). But restricting web apps to the point they're actually broken? No, that really sucks. Shame on Apple.
Shame on developers for cargo culting web apps over to various mobile platforms. Even on desktop platforms, non-native apps stick out like a sore thumb and generally work poorly (e.g. Slack). Granted I'm okay with my apps not doing autoplay video regardless of whether or not they're native.
> And if we care about freedom and the opened web, we should not cheer on proprietary, closed platforms like app stores. We should want the opened web to win.
How about the freedom to be rid of phishing apps and spyware? The "opened web" is not an all or nothing idea, and promoting web "apps" over proper native apps isn't a win.
I am not. That reinforces a iOS/Android ecosystem lock in. I personally want to see web apps succeed so it would be easier to move off of those platforms. If that happens, then I would foresee that web apps get first rate treatment and won't be "clunkier"
Along with technical reasons in original article, likely submitting as an app adds a marketing channel, and a big one at that, that wouldn't exist for a pure web app. Would be interested to hear from author if this is indeed the case, and if it was, if he feels the effort is worth the benefits.
We're definitely at the point in history where we have to get out of these app stores. I get it if you're doing a game or something that's fine, stay in the app store. But I don't know how many times I've been extremely frustrated with a website telling me to get their app.
* They break my in-browser password store
* They introduce extremely complicated "app-only" device links for Oauth
* Updating your UI for most apps shouldn't require an app-store push (don't talk to me about ionic)
This is the same fight but different players that we're currently facing in getting away from Social Platforms.
Yep, I hear you. Unfortunately, the status quo today is, that's where the users are.
I love the free and opened web. I want it to win. I think it will win and eat native apps (PWAs are already making that happen.)
But the barriers to this right now are 1) app stores are where users are and 2) some mobile platforms (read: Apple) have a perverse incentive to cripple web apps so that submitting native apps to their store (and thus, paying them $99/year + 30% in-app purchases) is required to have a first-class experience.
Unfortunately, the status quo today is, that's where the users are.
I've seen a few people make this argument, but no real data. Does anyone have any relevant stats about web vs. app store sales, perhaps the ratios between customer numbers and/or revenues through different channels, that they'd be willing to share?
Does the free and open web have support for augmented reality? On device security? On device machine learning? Accurate GPS? Accelerometers? What about low level graphics?
The “web” is great for websites and CRUD— not so good if you’re trying to go beyond that.
You mean Google. Android webviews are VERY slow. Tha comnpound with the overall bad android OS (terrible privacy and security, terrible overal performance).
Since KitKat I think, WebView is updatable (and is on the App Store), plus browsers like Chrome and Firefox can provide their own WebView implementation. Most people with non-ancient phones are probably using Chrome's engine in all WebViews.
And also, old engine doesn't even mean "slow".
Only Apple used to an actual problem here, because for a long long time there was no JS JIT in WebViews.
Given Safari can optimise for a single GPU target (which is also probably faster), it is likely the speed differences are not due to the browsers per se.
One of the ones I hate most is Reddit, which actually has a pretty good web interface. The worst part about their app is I can't search for words in threads.
I'm actually on the other side of this - it's really easy to use their app to browse posts and read comments, where it's a bit more involved using the web interface.
My experience with Reddit mobile web has been frustrating, because every page has a secondary loading period that is entirely unnecessary and seems to only be loading styling and JS libraries. The old Reddit mobile (i.reddit.com, I believe) was fairly simple HTML (though to be fair, it didn't look good) that loaded quickly and felt responsive.
I browse the mobile reddit all the time and constant nagging to use the app was a real PITA until I discovered that I don't have to press the link to hide the "browse with the app overlay". You can simply scroll down and it will go away.
This is what I hate with the current software development culture. It's not your UI once it's on my things, its MINE. You shouldn't be able to touch it once I have it.
* 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
As a user I am glad Apple is the "loser" in this article and it's the reason I love iOS and hope Apple doesn't change anything in their attitude towards the "free and open" web.
I do not trust the web, at all. Access the camera? Nope. The microphone? Are you kidding me. Notifications, GPS, background processing? Fuck no.
I am very happy to have Apple as a quality, security and privacy gatekeeper, because I do not have the time anymore to do that all by myself (and related to that, I'm so happy we've left the Windows era behind and I'm not bothered by friends and family anymore with all the crap and problems on their devices thanks to all the "free and open" stuff they'd download and install).
PWA's? Screw that, I hope they never become a first class citizen on Apple's platforms. It's good for Apple's business and their users to keep it that way.
Your trust of Apple and distrust of the web is irrelevant. Nobody is suggesting automatic permission to these things. There is nothing wrong with asking permission to access your microphone for example. You can always ignore request, or click no thanks.
Any website right now can place a link to an exe file in the text and ask users to "please download". It's your choice whether to go ahead and download. It should be the user's choice whether to allow access to camera or anything like that too. Pretty obvious really.
> From minor things like “iOS Safari won’t let you play audio without first interacting with the page” to major, show-stopping things like, “iOS Safari won’t let you play the next song if your app is in the background or if your screen is off.”
As a user, I'm very happy Apple prevents a random website from doing this. I'm sorry this complicates your specific use-case, but the benefit for me is that I don't get audio ads just from opening a webpage (ads), nor will a page I opened a while ago unexpectedly start playing sound at me (ads!)
Furthermore, the latter restriction lets the scheduler/power manager make better decisions about what runs (and thus can consume power).
The broken HTML input though, that sucks and I'm sorry.
"Final thoughts: The web always wins. It defeated Flash. It killed Silverlight. It destroyed native apps on desktop. The browser is the rich client platform. The OS is merely a browser-launcher and hardware-communicator.
The web will win, too, on mobile. Developers don’t want to build 3 separate apps for the major platforms. Companies don’t want to pay for development of 3 apps.
The answer to all this is the web. We can build rich web apps – Progressive Web Apps – and package them for all the app stores.
Apple in particular has a perverse incentive to stop the progress of the web. It’s the same incentive that Microsoft had in the late ‘90s and early 2000s: it wants to be the platform for good apps. PWAs undermine that; they run everywhere.
My software wisdom is this: PWAs will eventually win and overtake native mobile apps. In 5-10 years, native iOS apps will be as common as Win32 C apps."
iOS developers made $27B last year writing apps for the App Store. It ain't going away, it's still growing.
Web apps are fine for quick and dirty apps where the user experience doesn't have to be great. Choosing HTML and Javascript for UX always means you're going to have a compromised user experience compared to native. Again that's fine in segments where it's not as important, but ultimately the best experiences are native and that's where the market is going.
I feel you, every time i have to work with anything apple it's painful. Even their dev tools, i wasn't expecting much from XCode and i was still let down.
The dev experience was better with MS's tools, of course. They created PWABuilder, and it *actually generates a Windows Store package (.appx) that can be submitted to the store. No other steps required. Pretty amazing.
Google wasn't bad; PWABuilder generated an Android Studio project. You open in Android Studio, build, and it generates the package to be submitted to the store.
iOS was sadly the most painful. Not least of which is because it requires a Mac, with XCode and dev frameworks, to build.
XCode is well suited if you want to build an iOS app. If you’re trying to build a glorified web app wrapper and to boot you start out disliking everything that has an Apple logo you’re not going to have a good time.
That’s not a problem though, I’m fine with less web app wrappers and less ported Android apps in the App Store.
It’s a lot to do with what you’re used to. As an Apple user bought into their ecosystem and tools, I find developing for their platforms dramatically easier and more straightforward than for other targets. I can basically do Android development with some pain and confusion, but on Windows I’m totally stumped/useless.
I was trying to learn native iOS and Android app design been a mainly reactnative developer.
Android was very easy to start. I learnt kotlin as I was writing the code. Java I remembered some from college days decade ago. The UI builder was very easy to use. I even went far as using the dagger Di.
iOS I was kind of frustrated. I had gone over swift Lang some time back. But I found its syntax estoric. UI builder had its own issues for some row column the constraint layout kept on failing. Its not user friendly as in android. And in the strange name/ structure of routes, the dragging of ui elements to code.Considering that I would need to write business code for both platforms I just gave it up. Now trying out flutter.
Android isn't just Kotlin and Java. It also bundles Gradle with its Apache Groovy DSL, whose syntax is just as esoteric as Swift. Although Groovy is pitched as having Java's syntax, the DSL portion of it (as used in Gradle) looks nothing like Java.
Apple needs a better onboarding for new developers and definitely needs to improve XCode to be on part with it's high shipping standards, it also didn't help that a lot of the time the iTunesConnect platform was failing.
I can say however that it is easier to create things of higher quality with the iOS Sdk than it is with the Android sdk, at least it was for me.
> Don’t make me pay you to make my app available to your users. My app enriches your platform.
In the 90's Microsoft won market over Apple by, among other things, being a more developer-friendly company. It seems Apple didn't learn any lesson from it: crappy tools (XCode), disregard for standards (Safari), creating barriers...
Problem: "I go to D&B to update my business profile. Surprise! They have a JavaScript bug in their validation logic that prevents me from updating my profile."
Solution: "Thankfully, I’m a proficient developer. I click put a breakpoint in their JavaScript, click submit, change the isValid flag to true, and voila! I’ve updated my D&B profile."
I "loved" that too. Excepting having to find out that the problem really was a JS validation bug. To have to discover this in 3rd party obfuscated JS was not fun. :-) But hooray, I got it working.
Another developer whining that they don't have free range to do whatever they want.
There are a multitude of reasons why Apple doesn't allow Safari sites to do whatever, namely security, power management, feature duplication/user confusion, etc. When you pay to deploy a native app, you are paying for hosting, the reviewers, payments, availability, etc.
There is no control over when a website may change and at any time your server can be hijacked to distribute malicious content vs an app, which is much more protected by layers of security and process.
Your priorities are definitely not priorities of the end user, where Apple, a company that has millions of customers is. If they were irresponsible and distributed iOS in the way you want, it would be Windows XP all over again. Viruses, security holes daily, etc.
Partially true, but knowing that google is making it easier to publish web applications just makes me more attracted to that ecosystem as a web developer. Apple has for long been a closed ecosystem and they have their reasons, they try to control everything in it to maintain a quality standard, so it only makes sense that trying to build something as open as a PWA would not be of interest to them, or beneficial for that matter.
Are there any technical reasons you’re aware of why pwabuilder.com couldn’t also emit Electron wrappers for platforms like Linux and OSX where native support for PWA apps is lacking? (and yes, I do hear you, angry young man, about how much you hate Electron apps and wish they would go away)
UPDATE: it seems to be pretty lightly documented and I wasn’t able to confirm the status, but pwabuilder does appear to have options to generate electron-prebuilt “PWA” wrappers for Linux, MacOS, and win32 platforms. Pretty excited to give it a try.
Developed solely for the IOS appstore for a year in IOS Swift, my app (http://lucid.fyi - shameless plug):
Hated developing for IOS because came from web background and everything is restricted and you need payments to do anything. I'm also a sole developer and so every step that requires money I hate because I don't have a lot of money.
Yeah, PWABuilder is amazing. A web page that analyzes your PWA, tells you any additional things you need to do to your PWA before submission, then generates packages for iOS, Google Play, and Windows Store. Awesome. More web devs need to know about this.
If developers that want their free apps to be uploaded to iTunes don't want to pay the fee I can try to propose a solution.
A collective of similar individuals can pay for one iTunes account and share it between all involved. There can be a entry process for others willing to join as well. Of course, there are a few negatives:
- the account agent account has the keys to this. It would have to be someone highly trusted, but perhaps it can be down to a vote to determine the role. At first, it can simply be whoever starts this.
- if iTunes decides to shut down the account, the all eggs in one basket approach would shutdown all of the apps
- maintenance of distribution keys/provisionings may be a hassle depending on the roles regular members have in this (non-admins can't create iTunes Distribution provisionings)
- The "see all apps created by this dev" feature may show seemingly unrelated apps
I'm sure there's more I can't think of, but I still think it's doable.
This is why I favor Android in these situations. It's far easier and cheaper platform to get a (web) app out there.
I have created a scratch to apk service (requires no permissions either) using javascript and then an apk signer (which can then be side loaded) - Job Done as they say.
The article mentions that the author was worried that the fast processing time for Google Play meant that it hadn't actually been check, but according to Google they do:
I believe the way it works is they run the app through an automated test suite (virus scan and monkey testing) and if it flags anything up then it goes to a human to review.
Author here. Yeah, I suspected precisely this. They run it through an automated test, and a human reviews only if the automated test raises a flag.
I guess that's OK. I did like the fact that my app went from submitted to in the Google Play store in all of 5 minutes. (Compared to 48 hours for iOS, and 72 hours for Windows.)
I found it interesting that he counts having to buy a Mac to do iOS development as a negative, but doesn't make the same case about having to buy a Windows PC to do Windows development. I currently own only Macs. If I want to develop for Windows, I can just buy a Windows license and use it on my existing Mac. And of course, I can install Linux on it, as well. Seems like a stupid thing to call a negative, since no matter what you use, you'll need to buy a machine to do any development.
Requiring a computer to make an app is hardly a fair comparison. The point the author is making is that you need a Mac to build an iOS app. It's impossible to make an iOS app on any other platform.
Meanwhile, you're perfectly capable of building both Windows and Android apps on either Mac, Linux or PC.
There's a big difference between $25 one-off and $99 per year. I make a niche app that gets about $20-$50 per year in sales. I'm not interested in making money on it, but it would not be worth my while developing such an app for iOS. OTOH, I've made back my $25 Play store fees and can now make my app free.
We are building an app store for PWAs to solve the exact issues you're describing over at https://appsco.pe. We won't be able to solve the native capabilities issue though but we don't think Apple can cripple Safari forever either.
Beyond a certain point, the marginal utility of an additional app on the platform doesn't add that much. Even within your very narrowly defined niche, it wouldn't surprise me if there was an alternative app.
Apple is long past the point where marginal utility of adding an app really matters, whereas Windows Phone was missing apps for Instagram and Snapchat.
In this article, I read that you not only need a registered company to publish iOS app, you also need it to be registered with third party (DnB) provider? Is it true? You can't publish on Apple store without having DnB-approved company?
As I'm not in the US getting an approved DnB profile turned out to be painful. Even once I got one, apple still did not consider my profile valid (yes, I did wait a few days)
As I was on a dead line and fed up with the whole DnB crap after a couple of weeks I ended up registering the iOS developer license on my personal name instead of my company name.
Yes, that was the case for me. If there was some other way, it was not available for me.
The good news is that DnB probably already have a profile on your company. The bad news is, if any of the info is incomplete or incorrect, you need to rectify that before getting approved for the Apple Developer Program, which is required to get your app in the store.
The function of this service appears to stream audio in the form of music in brief recorded performances. Is this not the purpose of podcast and met by an existing iOS app from Apple titled “Podcasts”?
Apple decided many years ago that they were going to make it rich by controlling as much of their product/software as they could. In the past, when I guess they put out unique and well crafted products it worked. Today, not so much. Their stuff is garbage. Apple has continuous problems with production and have used strong-arm tactics to control what people can find out and fix on their own.
You hit the nail on the head with "In 5-10 years, native iOS apps will be as common as Win32 C apps. Apple will go kicking and screaming, keeping iOS Safari behind the curve, blocking PWA progress where they can. " Personally, I don't think (hope?) that it will take 5-10 years. Right now they have less than 80% of the market. As more and more people figure out that their products are not what they used to be that market share will become less and less. At some point it will no longer matter.
To the argument that the "sales are there" all I can say is look at the statistics. I believe it's less than 1% of all app store products (regardless of which one) make money. And, the average user goes to five apps on their phones all the time. The chances you're going to write an app that actually makes anything is between slim and none. If the user can't install your app for free you're never even going to get it installed on their phone/tablet at all.
Further, the vast number of apps in the future will be PWAs and many of those will be business oriented. As you said, programmers don't want to have to write three different sets of code (realistically only two: JS and Apple - whatever they're pushing recently). And, most of those apps will be "installed" from the web page for that SaaS or your own enterprise.
Apple is done. Stick it with a fork and take it out of the oven. Obviously, with all the dumb money they've collected over the last 10+ years they could do well without ever shipping another product. And, without a doubt, they will continue to get people to buy their products for sometime in the future. But, they will either come to the realization that they have no choice but work with MS and Google in allowing PWAs or they will become irrelevant. It will take them some time to understand that since they no longer have forward thinking management and just surround themselves with "protect our business" types. Eventually, those turkeys will be replaced (hopefully sooner rather than later - we still need competition) or Apple will become the next Oracle. No longer a player in today's world.
And for those doubters out there, don't forget, Apple was going down when they brought Jobs back the last time. Unfortunately, they have no one to go back to this time. It can, and will, happen again.
What helps to prevent spammed low quality apps is the app review process.
Those who are spamming the app stores with low quality, keyword dense apps are those who are looking to make a quick buck, and they do not hesitate to pay the paltry yearly fee.
He complains about buying a Mac but what about Mac people who want to develop Windows DirectX games? They have to buy a PC (realistically you don't want to emulate a PC).
The article is about PWAs which have no native code. The restriction for DirectX is a technical one, not a business one. Cross-compiling is possible, but difficult as the ABI has to perfectly match.
Not being able to push a bundle of JS+HTML to the Apple store without a Mac is a completely artificial barrier. Even in regards to the full XCode suite (which I could understand why they wouldn't release for other platforms), the unbelievable lengths that Apple go to to ensure that OS X can't run in a virtual environment is quite frankly ridiculous.
So by this author’s estimation, the Apple App Store is the worst and the Microsoft App Store is the best. I can tell him that from the user’s perspective, it’s the exact opposite, and I have exactly one app from Microsoft and hundreds from Apple.
No, that wasn't my conclusion. If you read the article, I offer a summary at the end, where I give a winner. (Winner, meaning best/easiest/simplest/fewest barriers to entry from a developer perspective.)
The winner is Google.
One of the main reasons for that is, Google tries to make everything in the OS available from standard JavaScript. Their platform is web friendly. For example, want to display the currently playing song info and album art on the lock screen? They submitted a new web standard for that.
Really this is all about your aversion to paying the fee and to learning how to develop for the respective platforms. JavaScript does not offer performance or optimization near the same levels of native code, etc. On top of that, there are guidelines, accessibility features, and carefully crafted UI components for a respective OS (that have thousands of hours of user research).
The amount of standard APIs developed in JS are nowhere near native APIs, also JS has barely gotten to the point of good enough for native development, whereas, mobile platforms have had 10 years of mature development.
It's quite the fantasy to pretend that PWAs can offer the user anything better than a native experience at this point.
No, I wrote the post to document how an existing web app can be moved into the app store, the reasons for that, and the hurdles in doing so.
APIs: Yes, Google is improving the situation -- making more and more common OS APIs exposed to standard web interfaces. Meanwhile, Cordova is letting web devs access native functionality that the platform vendors don't expose. The story isn't perfect, but it's actually quite impressive even now.
Web apps: they offer all kinds of things native apps can't. Native apps require install. Native apps must go through approval process for every update. Native apps are restricted in what they can publish on the app store. Native apps are subject to the censorial whims of a single corporation (or government forcing that single corporation). Native apps only work on a single platform; the web works everywhere.
There are lots of wins for web apps. And I think PWAs only increase those wins.
I know your pain about the D&B issue. That was a huge slap in the face when I saw that. Apple, one of the largest companies in the world, has presented some random company as the face of their Developer portal? "Couldn't be... No way... wait a sec they are that stupid... goddammit".
Then, at the end of the day, all it ended up being was a phone call that verified the information I entered on the D&B webpage. Stupid waste of time. I am tempted to think someone on Apple's board partially owns D&B and is forcing it down everyone's throat to make a quick buck, there's no other reason for this kind of experience otherwise.
D&B isn't some "random" company. If you've ever been faced with a project that requires you to have a reasonably complete set of information on most businesses in the country, you quickly learn about D&B. Almost every large company is licensing D&B data in some form or another. Cataloging every business in the US isn't an easy problem to get right, even for a company as large as Apple.
I worked at a trademark search and brand-protection company for a few years, and we never used D&B.
We scraped from every secretary of state in the US and the federal patent and trademark office, and got some info from LexisNexis. We had a mess of regular expressions that had to be updated any time a secretary of state changed their website. But in the end, we had a reasonably complete set of information on all registered corporations and DBA registrations in the country, which was updated at least monthly. We certainly had a record for every company that had a registered trademark.
Apple could certainly do that work itself, at a fraction of the cost of whatever it pays D&B. Any Joe Schmoe in the country can look at a business name, go to the secretary of state of the state they claim to be registered in, and verify the detail, which always includes the name and address of the registered agent, and most of the time also includes the principals of the corporation.
It is a random garbage company that is stuck in early nineties. It preys on stupid first time company owners whom it sells its credit builder for business services. That's the entire business model.
Edit: Can't respond due to rate limit - 40k/year from 1000 companies is nothing compared to $199/mo and more from credit builder from every Jack and Jill with a DBA, LLC or Inc.
Umm...that's comically wrong. The fortune-500 company I worked for paid more than $40k/yr to license their data and update it monthly. Given the description of how Apple is using it, they're probably paying six figures per year. Neither of our companies were buying credit builder services.
They are just a "random" company. They don't sell any product a regular person would know about. Why was I able to setup a Google Play account without D&B? Amazon let me use EC2 without D&B, SendGrid let me use their mail API without any of this. It's a company that appears out of nowhere, for no reason. That's why it's "random".
It's a stupid service that does nothing. If they deny me and I have nefarious, ulterior motives, I'll just register another company. And for what it's worth, my company is Canadian and I'm pretty sure they don't have any ability to verify Canadian companies. The phone call didn't ask me anything about a GST number, business number, or any of that, they just asked if the phone number and address of the company were correct. How do they know if I'm giving them correct information? I could say my company is on the other side of the country, how would they know?
The whole process took me a week to get through. I can purchase a goddamn assault rifle and shoot up a school in less time than that, but heavens forbid I put an app on an app store! Good lord won't you think of the children!
I think you've missed my point. The D&B requirement is a natural consequence of the fact that Apple has decided to require that publishers be an established business. My point wasn't to defend Apple's decision in that matter. You can setup Google Play, use EC2 or send a SendGrid email because those companies haven't made the same decision that Apple has.
I was mainly pointing out that D&B is a huge player that a lot of us have heard of. It makes complete sense that, once Apple has made the decision to require an established business, that they'd delegate the validation process to D&B. Just because people who have never thought about solving a problem like Apple decided to solve haven't heard of D&B, doesn't make them some "random" company. They're the market leader in their space and, as someone used their licensed data in a product, it makes complete sense to me that Apple would use their service in support of their business decision.
Yeah. That was actually one of the most painful points, and it had nothing to do with the software itself.
And to make matters worse, D&B have a client-side validation bug on their site when updating your profile. I actually had to set a JS breakpoint in their code and change .isValid = true. Just so I could update my profile. Unbelievable.
On top of that DnB sales the shit out of your info. Then if you setup a private llc with a registered agent it allows a way for people(patent trolls and attorneys) to find out who you are etc.
And if you make the error of giving D&B valid contact information for you, they will bug the everloving shit out of you until the heat death of the universe. When I was a young pup of a business owner, someone asked me for my DUNS number so, foolishly, I just went to D&B's website and filled out the enticing form there with my cell phone number and company e-mail address.
The spam e-mails and phone calls were unceasing. They wouldn't stop calling me with sales pitches, "unique, one-time offers," and blunt statements that (unless I paid money to them) my business would be "delisted" in "just a few days." The assholes also proceeded to sell that information to other companies, so then I started hearing from accounts receivable financing outlets, merchant processors, and the like.
Several years later, the phone calls have stopped only because I changed phone numbers, but I still get three or four "your D&B profile is incomplete, call us today!!" e-mails per month to that old address.
I disagree that these things are purely because Apple wants your $99/year. Maybe that's part of the story, but not all.
I am glad that websites cannot play audio without the user first interacting with the page. I am also glad that websites can't play audio in the background — as a user, I would find it too "buried" behind Safari and I wouldn't appreciate the feeling that a website was running in the background. (Yes I know you can control audio via the Notifications Center and Control Center.)
I appreciate that these permissions are reserved for apps that Apple has vetted, even if this is a pain for developers and they are not a perfect institution, as a user I appreciate that they are trying to maintain quality and encourage good app behavior.
I'm glad your app had to jump through these hurdles to gain the functionality your users wanted. Like you said, it's where the users are they were asking you directly for it. These are higher-level permissions and should not be free for the taking.