I built a progressive web app and published it in three app stores
debuggerdotbreak.judahgabriel.com
debuggerdotbreak.judahgabriel.com
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.
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.
So sad, lemme find my tiny violin.
Dinosaurs will die.
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.
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.
"So the only thing that applies to you is not wanting to pay upwards of a thousand US dollars for yet another development machine."
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.
I thought you meant charities, not non-profits, but TechCrunch reports the latter:
"Apple in early 2018 will waive the $99 developer fee for all government and nonprofits starting in the U.S. to make this transition easier."
https://techcrunch.com/2017/12/20/apple-revises-its-controve...
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.
Google’s bright ideas aren’t necessarily standards. Service workers are only a working draft, and only implemented in 2 of the major browsers.
Obviously Google and Apple have different priorities, and clearly service workers benefit Google more than the other vendors.
Maybe ask jon at apple
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.
> Web app restrictions by ~Apple~ hostile mobile platforms
Their developer story needs work, especially around web apps.
Thanks for letting me know. I'll change my tone in future posts.
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).
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.)
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.
I hope they lose their dominant market position soon so everyone doesn't have to play by their rules.
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.
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.
>> "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.
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.
> 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.
Thereby illustrating the parent's point that developers will still ask for too much and that the power balance is in favour of the developer.
Apple on the other hand heavily restricts what developers can do. It's developer-hostile, but user-friendly.
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.
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.
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.
Which is not the same as native apps on iOS where apps can't spam you without explicit opt-in.
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.
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 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.
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.
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.
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.
1. Open control center.
2. Control music from there.
3. There is no step 3.
So now we need to add a "block webpage" button to control center?
It's super convenient and I'm surprised iOS doesn't offer the same? Seems like a no-brainer no-risk feature to me.
“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.
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.
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.
And what makes an app different from a website, really?
In my opinion, web browsers need to add privilege controls to websites just like the OS does to apps.
That apps have been vetted is the difference.
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.
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.
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.
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.
Worse, there's no way to fix that. That's how it's supposed to work.
This is the state of PWAs on iOS.
I'm not sure which one sounds worse.
“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.
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.
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
I don’t quite understand what the issue with native apps is in all honesty?
The phishing industry is doing well for itself, and there's no sign of the scamming factories shutting down anytime soon.
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.
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.
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.
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.
That's what every company says right before they get their lunch eaten by a startup that comes out of nowhere ;)
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.
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.
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.
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.
[1] https://qz.com/826672/android-goog-just-hit-a-record-88-mark...
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.
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.
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
It's irrelevant. Standards aren't set to satisfy a portion of users.
Can you image the clusterfuck if there were different sizes of Bluray discs?
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.
Sure there is. Apple is already blocking it so its not hard to imagine a world where they only selectively block pages or features.
99% of apps as well, most apps embed tracking code.
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.
Can't play next song if it is in background, etc. All the tech reasons were listed out.
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.
[0]: http://debuggerdotbreak.judahgabriel.com/2016/12/13/its-almo...
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.
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.
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.
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.
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.
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.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Media_Sessi...
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].
[0]: https://github.com/leon/cordova-plugin-remotecommand
[1]: https://github.com/leon/cordova-plugin-nowplaying
[2]: https://github.com/JudahGabriel/Chavah/blob/master/Chavah.Ne...
[3]: https://developer.mozilla.org/en-US/docs/Web/API/Media_Sessi...
[4]: https://github.com/JudahGabriel/Chavah/blob/master/Chavah.Ne...
[5]: https://github.com/JudahGabriel/Chavah/blob/master/Chavah.Ne...
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.
I had to get a DUNS number to apply to the app store. And it had to be an LLC (I think?) and not a sole proprietorship.
I initially just wanted to use a "DBA" (doing business as) but they don't allow those anymore, they used to in the early days but no longer.
A DUNS number is only required for organizations, not individuals.
I suppose I could have just used my name though.
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.
Maybe Java fans, or Sun/Oracle employees and fanboys said that. That doesn't really mean much.
I did predict years ago that open web technologies will destroy native (desktop) apps, Flash, and Silverlight. In hindsight, I was correct.
I am predicting the same thing with regards to native mobile apps: they will largely disappear, and web apps will again win.
(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.
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.
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?
https://blog.twitter.com/engineering/en_us/topics/open-sourc...
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.
* 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.
https://www.cnet.com/how-to/how-to-use-ios-11s-password-auto...
I've found it quite useful.
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.
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?
You mean Google. Android webviews are VERY slow. Tha comnpound with the overall bad android OS (terrible privacy and security, terrible overal performance).
Huh?
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.
I have tested several demos by ionic, framework7, etc... is amazing how slow are androids...
Apple hardware benchmarks well beats Android hardware: http://browser.geekbench.com/mobile-benchmarks
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.
I've been dealing with UIWebView and WKWebView problems for over 3 years now, but Android webviews have given me zero problems.
The “web” is great for websites and CRUD— not so good if you’re trying to go beyond that.
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.
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.
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.
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.
Web apps on Android May "work" but still aren't as responsive as native Android apps.
Doing what he said takes me to:
https://www.apple.com/shop/buy-mac/imac-pro
Clicking the "Buy >" button takes me to
27-inch Retina 5K 5120-by-2880 P3 displayI 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!
This is some silly stuff right here.
All but the vintage 2012 desktop Mac minis have been nuetered in the sense they are not upgradable.
If I needed a beefier machine, I would be making much more money and justifying its purchase.
That's the point: the current mini is worse than what you could get in 2012, due to removing the quad core option and upgradeable memory.
(It also runs a couple other small things for the house.)
So don’t. I also don’t have to use your app.
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.
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.
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.
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.
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.
It does not just require a computer, they require an Apple computer, big difference.
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.
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.
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).
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.
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.)
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.
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.
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.
Not to put too fine a point on it, but some organization's internal engineering goals should not become our UX nightmares.
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.
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.
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.
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.
It's completely the fault of the developer for choosing Electron when there are better tools available.
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.
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.
Let me tell you, people do care about the desktop app, and not in a good way…
Is Slack good enough that enough people will pay for it to make it a sustainable long term business?
https://www.recode.net/2017/6/15/15810088/slack-deal-funding...
If it can be done as a web app why not do it as a web app?
Yes I am a developer and for products that are suited to be on the web, I write websites.
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.
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.
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).
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.
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 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.
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.
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.
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.
Look at Windows Mobile.
Why does not having a smartphone make you loathe native apps?
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.
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.
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.
Well, I mean, besides the 10s of thousands in the software repos, sure. The amount of time I spend in web apps on Linux is minuscule.
Try asking someone who uses native MS Office to use the equivalent web app.
In this sense, the web has already won here: I'm able to take a single codebase (HTML, JS, CSS) and generate apps for 3 major app stores.
Most people releasing apps shouldn’t.
However:
> 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.
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.
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.
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?
This is essentially begging the question, isn't it?
If the developer wasn't required to use a specific development environment, might they be able to produce a higher-quality app?
This is wrong. Cordova has been around for years.
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.
No longer tired of it, thanks.
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.
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.
Average rating on Android is 4.1
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.
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.
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.
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.
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.
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)
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.
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.
-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?
Top app developers should already be on hosted/SaaS CI services that offer Mac servers like Travis or CircleCI.
Where were you ten years ago? Remember installing software on Windows?
> Whereas PWA is all about improving UX
But it doesn't improve UX.
Searching on the app store and hitting "install" is an abysmal amount of friction?
Compared to links, anyway.
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.
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.
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 …
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.
"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?
Well, if the things I put in my refrigerator started acting like malware, I think manufacturers might start taking a different approach...
If your vitriolic rant has any substance, please present it. Otherwise you just come off as a cock-sure, know nothing asshole.
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.
Cheers
Sure, like if the supermarket sold something that spread mold spores to other food.
Why fridge? That's basically what the supermarket does for me. They sift through a sea of garbage and show me a selection.
Apple just happens to be both the fridge manufacturer and supermarket.
If my supermarket released a fridge I might consider it.
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
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.
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.
Of course, that doesn't stop all bad actors [0]. But it's much more process-based security than the web permits.
[0]https://www.theguardian.com/technology/2017/apr/24/uber-brok...
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.
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.
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.
https://www.forbes.com/sites/chuckjones/2018/01/06/apples-ap...
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.
In this regard Microsoft is way superior.
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.
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.
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.
That’s not a problem though, I’m fine with less web app wrappers and less ported Android apps in the App Store.
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."
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.
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.
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.
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.
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.
https://android-developers.googleblog.com/2015/03/creating-b...
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.
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.)
Meanwhile, you're perfectly capable of building both Windows and Android apps on either Mac, Linux or PC.
> Google asked for a token $25 one-time fee. Probably to avoid spammers and decrease truly junk apps from entering the store
So he found an excuse for google to do it, but somehow Apple is evil when they do the same?
I don't know much about the guy or his app but this sounds supremely entitled. I don't think Apple is in want of developers to make apps for iOS.
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.
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.
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.
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.
It helps to prevent spammed low quality apps. If there is a monetary barrier to entry, it helps curb that.
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.
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.
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.
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.
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.
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.
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.
Way to focus on privacy Apple!
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.
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 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.
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.
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.
D&B is almost completely pointless in 2018.