May 31, 2018 at 10:53I did PWA and put it in three app stores. And here is what I found out
- Transfer
Translation of I built a PWA and published it in 3 app stores. Here's what I learned .
I recently published a progressive web app called Chavah Messianic Radio , a music player like Pandora, and put it in three app stores (Google Play, iOS App Store, Windows Store).
The laying out process was hard and instructive. Here is what I found out.
You were probably surprised: “Why did you even put the application in the store? Let it live on the open web! ” The fact is that users are concentrated in the stores . A generation of people has grown that we have been accustomed to looking for applications in their respective app stores, and not in the public domain.
As for my application, I had two big reasons to put it in stores:
User demand: for years my users have been asking me, “is there an application for Chavah? I did not find it in the store. " They asked me this question because we taught them to look for applications in their respective stores.
Until recently, I replied:
But I lied.
Real web applications only work approximately on mobile phones. And that led me to a second reason:Apple’s web application restrictions on some mobile platforms.
Mobile platform developers like Apple are completely satisfied with the applications that use your phones to the fullest: get access to your geolocation, play sound in the background, get your GPS coordinates, read all your contacts, play video and audio without interacting with the application , read your mail, intercept typed text, simultaneously execute several processes, use a microphone and a camera, access photos, and much more.
Apple is completely satisfied.
But only if you pay Apple $ 99 a year for all these privileges.
If you want to use one of the above in your old web application, then, damn it, Apple just won't allow it. She will not even let you request permission .
For my application like Pandora, this terrible powerlessness manifested itself in different ways . Starting from minor troubles, such as "iOS Safari will not allow you to play audio without first interacting with the page," to major problems, like "iOS Safari will not allow you to play the next song if your application is in the background or if the screen is off."
And, well, in addition, strange visual anomalies when you enter text in a text field, and it appears elsewhere on the screen.
In general, for my HTML5 music application to work properly on user devices, it was necessary to put it in the store.
In an ideal world, publishing an application in stores looks like this:
Your web / cloud host or CI provider:
You have published a progressive web application. Want to publish in app stores?
iOS App Store
Google Play
Windows Store
Or, as Microsoft is experimenting , your PWA will automatically appear in the store as soon as it is indexed by the Bing bot.
But alas, our world is not perfect. So we are faced with all kinds of proprietary native garbage when we try to put our web applications in stores. Each store has barriers to entry: that is, certain difficulties are created for placing the finished application in a particular store.
Here is some of them.
Do not make me pay to make my application available to your users. My application enriches your platform. Without good applications, nobody will need your platform.
Apple used to understand that. When the first iPhone arrived, Steve Jobs firmly believed that the future was HTML5 and that all applications would be prefixed with a “web”. There was no native iPhone SDK for third-party developers. However, since then, Apple's opinion has changed.
Google asks for a one-time fee of $ 25 for the token. Perhaps this is done in order to prevent spammers and reduce the number of truly slag applications entering the store.
Microsoft seems to be just trying to increase the number of applications in the store, despite the quality.
Winner: Microsoft. It's hard to beat the free.
In an ideal world, I would not have to write a single line of additional code to integrate my web application into the operating system. Or, as Steve Jobs said in 2007 :
For me, this means that my web application should play music in the background using standard HTML5 audio tools that work great on all operating systems. That is, my application announces which file it plays, and operating systems take this into account and show the current song on the lock screen. At the same time, my application plays using the standard HTML5 audio API, and the OS displays on the lock screen controls: play, pause, go to another file, change the volume, and rewind.
Unfortunately, our world is not perfect. All of the above does not work out of the box on all three platforms.
My web application needs the ability to play in the background. And the ability to download URLs from my CDN. Sounds reasonable, right? What about displaying the current song on the lock screen? And control playback from the same screen? How difficult is it?
There are three approaches:
Let's take a closer look at each approach:
iOS store . Does your web application need to play audio in the background? Use the Cordova plugin . Need to show the current song on the lock screen? Use the Cordova plugin . Need to control playback from the lock screen? Use the Cordova plugin . Well, you get the point. In essence, Cordova allows Apple to consider you a native application. And since you are not a nasty web application, Apple allows you to do everything that native applications allow. For this you need only native tricks - Cordova-plugins.
Google play. It's great that I can only write JS code, and everything will work. No Cordova plugins needed. Of course, this JS will not work anywhere outside of Chrome on Android ... but suddenly one day (in an ideal world!) All mobile browsers implement these web APIs ... and the world comes together. I almost sing John Lennon's utopian hippy anthem.
Store the Windows . Want to play audio in the background? Sorry! It will not work until you declare your intentions in our proprietary property manifest (it's simple) and don't implement this proprietary media interface using window.Windows.SystemMediaTransportControls (not so simple). Otherwise, turn off the sound when the application goes into the background.
Winner: Google. It is enough for me to write only in JavaScript, and the OS simply receives signals from my application.
Catching up : Windows. I can still write good old JavaScript, but I have to communicate with the proprietary Windows JS API that was embedded in my process when running under Windows. Not too scary.
Loser: Apple. They do not care about web applications. Even worse: they seem to be really hostile to web applications. iOS Safari is the new Internet Explorer 6. It lags behind almost all modern web standards, especially in the field of progressive web applications. This is probably due to business reasons: web applications make it difficult to collect $ 99 per year + 33% of sales fees in applications. Therefore, in order for my web application to work on this platform, I had to pretend that this is a native application.
To publish PWA in the store, you need to register, pass a business audit and overcome bureaucratic obstacles:
For me, the main problem was passing Apple’s legality test.
First I went to the site and registered as a developer. I entered my name and information about the company (I think Apple will not allow the application to be posted if you are not a registered legal company?). Clicked "Next."
"The information you entered does not match your D&B profile."
My ... what?
Googled a little and found out that the “D & B profile” is Dun and Bradstreet. I had never heard of them before, but it turned out that Apple uses the services of this company to verify information about legal companies.
And it’s obvious that my D&B profile does not match what I entered during registration.
I also googled and found out that the Apple-forum for developers is littered with such posts. No one received a sensible answer.
Wrote in support. After 24 hours, they answered my e-mail to contact D&B.
I decided to write to them ... but Apple said that getting a response will take several days.
At that moment I wondered if I could spit on the whole undertaking.
While I was waiting for a response from D&B support, I decided to go back to their website, check my data and update the information about the company, which they probably took from the state database.
I have already said, what kind of filth? But I just wanted to publish the finished application in the store.
I went to the D&B website to update my business profile. Surprise! They have a JavaScript bug in the verification logic, which does not allow updating the profile. Fortunately, I am a skilled developer. Added an interrupt to their JavaScript, clicked "Submit", changed the isValid flag to true, and you're done! I updated my D&B profile.
Returned to the Apple website for developers -> try again. I am registering my company ...
"Error: The information entered does not match your D&B profile."
ARE YOU KIDDING ME.
I am writing to Apple again. “Oh, updating information from D&B in our system can take 24-48 hours.”
Well, you understand, because digital information takes two days to travel from server A to server B.
Trying to register in two days ... it worked! I am now a member of the Apple Developer program and can submit applications for approval.
Winner : Google and Microsoft. In both cases, registration took 5 minutes.
Loser : Signing up for Apple Developer was slow and painful. It took me about a week. I had to get in touch with two different fucking companies. And it was necessary to fix the runtime bug in the JavaScript code on a foreign site in order to bypass their customer check curve, so that my information would go to Apple so that I could send the application to the store. Well, just ... wow.
If there is any excuse for Apple, then this is their 501c3 nonprofit program, thanks to which nonprofits can be exempted from paying $ 99 annually. I took advantage of this. And, perhaps, this complicated the situation.
Having made a web application, you have to use magic to turn it into something that can be sent for approval.
Good News: There's a free tool to magically transform web applications into application packages . It is called PWABuilder . The program parses the URL, says what you need to do (for example, add desktop icons to the web manifest of your PWA). And the wizard will help you in three steps to download packages that contain all this magic:
Again, Apple created the most problems. I do not have Mas. But without it, you cannot build an Xcode project for your PWA.
I don’t want to pay several thousand dollars for publishing my free application in the Apple store. I do not want to pay the privilege of enriching the iOS platform. Fortunately, MacInCloud costs around $ 25 a month. You are given Mac with Xcode already installed. You can connect to it remotely using Windows Remote Desktop, or even through the web interface.
But collecting an Xcode project and submitting it to the site is not enough. I had to generate a security certificate on the site for developers, then create a new application profile on a separate iTunes Connect site and send the package there for approval.
But this is not all: since Apple is hostile to web applications, I had to install special frameworks and add Cordova plugins that allow my application to play music in the background, add the current song to the lock screen, control playback there, and other actions.
It took me a week to bring the application to working condition with all sorts of tricks before I could send it to the store.
Winner : Microsoft. Imagine: you can go to the site generating the package from your web application. Or you can even download command line tools that do all this. Prefer graphical interfaces? It offers free Visual Studio.
Catching up: Google. Requires Android Studio, but it's free, works everywhere, and is easy to use.
Loser : Apple. I do not have to buy Mac for a few thousand dollars, just to build the application. The confusion with the Apple Dev Center -> iTunes Connect looks like an attempt to take developers away from real life to drive developers into iTunes. You just had to combine everything into one Apple Developer Center.
When you finally read all the spells that turn your web application into a mobile application package, you may want to send it to testers before allowing a crowd of unwashed users to access it.
Winner : Not clear. The Apple Test Flight app is easy to use. Admin can control alpha / beta validity. Google is also not too annoying, does not even require a separate application.
When your product is ready for prime time, you submit it for approval. The application passes an automatic checklist (for example, do you have an icon to run?) And is checked by people ("your application is clone X, we reject it").
Winner : Apple.
Of course, as a developer, I like that my application instantly hit Google Play. But I suspect only because a person did not look at him.
And as for human verification, it takes Apple the least time. Updates are also approved within 24 hours.
Microsoft did it somehow: the initial approval took 3-4 days, and the subsequent update was approved in a day. And the second update, added for the Xbox platform, again claimed 3-4 days.
To take the finished PWA, bring it to working condition on mobile platforms and place it in stores is hard and costs money.
Winner : Google. The easiest way to get to their store is the application. They also have the easiest integration with the native platform thanks to the standardization of the web APIs accessed by the OS (hello, favorite navigator.mediaSession).
Catching up : Microsoft. The easiest way is to use magic to turn PWA into a package that can be sent to the store (this can be done for free using the PWABuilder website !). Integration with their platform implies automatic implementation of the window.Windows. * API API namespace into the JavaScript namespace. Will go.
Loser: Apple. Do not make me buy Mac to build an iOS application. Do not force me to use native wrappers for integration with your platform. Do not fool me with your security certificates, let your build tools do them for me and automatically attach them to my Dev Center account. Do not force me to use two different sites: Apple Dev Center and iTunes Connect.
Final thoughts: the web always wins. He crushed Flash. He killed Silverlight. He destroyed native desktop applications. The browser is a powerful client platform. The OS has become a means of launching a browser and linking hardware.
The web will win in the mobile segment. Developers do not want to develop three separate applications for the main platforms. Companies do not want to pay for the development of three applications. We can create powerful web applications - PWA - and pack for all app stores.
Apple is tempted to stop the development of the web. Microsoft had the same temptation in the late 1990s and early 2000s: it wanted to be a platform for good applications. PWA destroyed these plans, now they are everywhere.
Wangyu: in the end, PWA will prevail over native mobile applications. In 5-10 years, native iOS applications will become as widespread as Win32 C applications. Apple will kick and scream, trying to keep iOS Safari away from this trend, blocking the development of PWA in every way (even their recent “support” for PWA in iOS Safari 11.1 is just disfigured PWA ).
I suggest that mobile platforms automatically add high-quality PWAs to application stores, or allow developers to easily (for example, for free and in three clicks) add PWAs on their own.
I recently published a progressive web app called Chavah Messianic Radio , a music player like Pandora, and put it in three app stores (Google Play, iOS App Store, Windows Store).
The laying out process was hard and instructive. Here is what I found out.
What for?
You were probably surprised: “Why did you even put the application in the store? Let it live on the open web! ” The fact is that users are concentrated in the stores . A generation of people has grown that we have been accustomed to looking for applications in their respective app stores, and not in the public domain.
As for my application, I had two big reasons to put it in stores:
- User demand.
- Web application restrictions by Apple on certain mobile platforms.
User demand: for years my users have been asking me, “is there an application for Chavah? I did not find it in the store. " They asked me this question because we taught them to look for applications in their respective stores.
Until recently, I replied:
“Yes, you do not need an application, just go from your phone to the site! He works!".
But I lied.
Real web applications only work approximately on mobile phones. And that led me to a second reason:
Mobile platform developers like Apple are completely satisfied with the applications that use your phones to the fullest: get access to your geolocation, play sound in the background, get your GPS coordinates, read all your contacts, play video and audio without interacting with the application , read your mail, intercept typed text, simultaneously execute several processes, use a microphone and a camera, access photos, and much more.
Apple is completely satisfied.
But only if you pay Apple $ 99 a year for all these privileges.
If you want to use one of the above in your old web application, then, damn it, Apple just won't allow it. She will not even let you request permission .
For my application like Pandora, this terrible powerlessness manifested itself in different ways . Starting from minor troubles, such as "iOS Safari will not allow you to play audio without first interacting with the page," to major problems, like "iOS Safari will not allow you to play the next song if your application is in the background or if the screen is off."
And, well, in addition, strange visual anomalies when you enter text in a text field, and it appears elsewhere on the screen.
In general, for my HTML5 music application to work properly on user devices, it was necessary to put it in the store.
Entry barriers
In an ideal world, publishing an application in stores looks like this:
Your web / cloud host or CI provider:
You have published a progressive web application. Want to publish in app stores?
iOS App Store
Google Play
Windows Store
Or, as Microsoft is experimenting , your PWA will automatically appear in the store as soon as it is indexed by the Bing bot.
But alas, our world is not perfect. So we are faced with all kinds of proprietary native garbage when we try to put our web applications in stores. Each store has barriers to entry: that is, certain difficulties are created for placing the finished application in a particular store.
Here is some of them.
Cost
- Apple : $ 99 per year to put your application in the iOS app store.
- Google : A one-time fee of $ 25 to place your application on the Google Play Store.
- Microsoft : Free!
Do not make me pay to make my application available to your users. My application enriches your platform. Without good applications, nobody will need your platform.
Apple used to understand that. When the first iPhone arrived, Steve Jobs firmly believed that the future was HTML5 and that all applications would be prefixed with a “web”. There was no native iPhone SDK for third-party developers. However, since then, Apple's opinion has changed.
Google asks for a one-time fee of $ 25 for the token. Perhaps this is done in order to prevent spammers and reduce the number of truly slag applications entering the store.
Microsoft seems to be just trying to increase the number of applications in the store, despite the quality.
Winner: Microsoft. It's hard to beat the free.
Adding Native Features
In an ideal world, I would not have to write a single line of additional code to integrate my web application into the operating system. Or, as Steve Jobs said in 2007 :
“The Safari engine is entirely on the iPhone. Therefore, you can write incredible Web 2.0 and Ajax applications that look and behave exactly like iPhone applications. And all your applications will be perfectly integrated with iPhone services. They will be able to make calls, will be able to send mail, will be able to search for places in Google Maps.
For me, this means that my web application should play music in the background using standard HTML5 audio tools that work great on all operating systems. That is, my application announces which file it plays, and operating systems take this into account and show the current song on the lock screen. At the same time, my application plays using the standard HTML5 audio API, and the OS displays on the lock screen controls: play, pause, go to another file, change the volume, and rewind.
Unfortunately, our world is not perfect. All of the above does not work out of the box on all three platforms.
My web application needs the ability to play in the background. And the ability to download URLs from my CDN. Sounds reasonable, right? What about displaying the current song on the lock screen? And control playback from the same screen? How difficult is it?
There are three approaches:
- Apple : we do not allow web applications to announce such opportunities. You need to write a native wrapper (for example, with Cordova) to interact with the OS.
- Google : the web is driving! Let's create a new web standard for playing and controlling audio from the lock screen. Playing in the background? Of course, wallow!
- Microsoft : we will embed our proprietary window.Windows. * API in your global JavaScript namespace, and with it you can do what you want.
Let's take a closer look at each approach:
iOS store . Does your web application need to play audio in the background? Use the Cordova plugin . Need to show the current song on the lock screen? Use the Cordova plugin . Need to control playback from the lock screen? Use the Cordova plugin . Well, you get the point. In essence, Cordova allows Apple to consider you a native application. And since you are not a nasty web application, Apple allows you to do everything that native applications allow. For this you need only native tricks - Cordova-plugins.
Google play. It's great that I can only write JS code, and everything will work. No Cordova plugins needed. Of course, this JS will not work anywhere outside of Chrome on Android ... but suddenly one day (in an ideal world!) All mobile browsers implement these web APIs ... and the world comes together. I almost sing John Lennon's utopian hippy anthem.
Store the Windows . Want to play audio in the background? Sorry! It will not work until you declare your intentions in our proprietary property manifest (it's simple) and don't implement this proprietary media interface using window.Windows.SystemMediaTransportControls (not so simple). Otherwise, turn off the sound when the application goes into the background.
Winner: Google. It is enough for me to write only in JavaScript, and the OS simply receives signals from my application.
Catching up : Windows. I can still write good old JavaScript, but I have to communicate with the proprietary Windows JS API that was embedded in my process when running under Windows. Not too scary.
Loser: Apple. They do not care about web applications. Even worse: they seem to be really hostile to web applications. iOS Safari is the new Internet Explorer 6. It lags behind almost all modern web standards, especially in the field of progressive web applications. This is probably due to business reasons: web applications make it difficult to collect $ 99 per year + 33% of sales fees in applications. Therefore, in order for my web application to work on this platform, I had to pretend that this is a native application.
Registration in stores
To publish PWA in the store, you need to register, pass a business audit and overcome bureaucratic obstacles:
- Apple : You must prove that you are a legal, registered company. We are not checking, but a third party , which may not know about you.
- Google : want to publish your application with us? We are glad.
- Microsoft : want to publish your application with us? We are glad.
For me, the main problem was passing Apple’s legality test.
First I went to the site and registered as a developer. I entered my name and information about the company (I think Apple will not allow the application to be posted if you are not a registered legal company?). Clicked "Next."
"The information you entered does not match your D&B profile."
My ... what?
Googled a little and found out that the “D & B profile” is Dun and Bradstreet. I had never heard of them before, but it turned out that Apple uses the services of this company to verify information about legal companies.
And it’s obvious that my D&B profile does not match what I entered during registration.
I also googled and found out that the Apple-forum for developers is littered with such posts. No one received a sensible answer.
Wrote in support. After 24 hours, they answered my e-mail to contact D&B.
I decided to write to them ... but Apple said that getting a response will take several days.
At that moment I wondered if I could spit on the whole undertaking.
While I was waiting for a response from D&B support, I decided to go back to their website, check my data and update the information about the company, which they probably took from the state database.
I have already said, what kind of filth? But I just wanted to publish the finished application in the store.
I went to the D&B website to update my business profile. Surprise! They have a JavaScript bug in the verification logic, which does not allow updating the profile. Fortunately, I am a skilled developer. Added an interrupt to their JavaScript, clicked "Submit", changed the isValid flag to true, and you're done! I updated my D&B profile.
Returned to the Apple website for developers -> try again. I am registering my company ...
"Error: The information entered does not match your D&B profile."
ARE YOU KIDDING ME.
I am writing to Apple again. “Oh, updating information from D&B in our system can take 24-48 hours.”
Well, you understand, because digital information takes two days to travel from server A to server B.
Trying to register in two days ... it worked! I am now a member of the Apple Developer program and can submit applications for approval.
Winner : Google and Microsoft. In both cases, registration took 5 minutes.
Loser : Signing up for Apple Developer was slow and painful. It took me about a week. I had to get in touch with two different fucking companies. And it was necessary to fix the runtime bug in the JavaScript code on a foreign site in order to bypass their customer check curve, so that my information would go to Apple so that I could send the application to the store. Well, just ... wow.
If there is any excuse for Apple, then this is their 501c3 nonprofit program, thanks to which nonprofits can be exempted from paying $ 99 annually. I took advantage of this. And, perhaps, this complicated the situation.
Packaging, assembling and shipping the application
Having made a web application, you have to use magic to turn it into something that can be sent for approval.
- Apple : buy a Mac first. You cannot build an iOS application without a Mac. Install Xcode and all these build tools and frameworks, get a certificate from our developer program, create a profile on a separate iTunes Connect website, link it to the certificate generated in the Apple Dev center, and then send your application using Xcode. Just, one, two, three- ... thirty seven ...
- Google : download Android Studio, use it to generate a security certificate and package the application. Download the package on the site for Android developers.
- Microsoft : generate the .appx package using Visual Studio or these free command line tools. Download the package on the Microsoft Dev Center.
Good News: There's a free tool to magically transform web applications into application packages . It is called PWABuilder . The program parses the URL, says what you need to do (for example, add desktop icons to the web manifest of your PWA). And the wizard will help you in three steps to download packages that contain all this magic:
- For Windows : Generates an .appx package that can be sent to the Windows Dev Center site.
- For Google : Generates a Java wrapper application that contains your PWA. You are building a project in Android Studio that generates an Android package for upload to the Android Dev Center website.
- For Apple : Generates an Xcode project that can be built using Xcode. And for this you need a Mac.
Again, Apple created the most problems. I do not have Mas. But without it, you cannot build an Xcode project for your PWA.
I don’t want to pay several thousand dollars for publishing my free application in the Apple store. I do not want to pay the privilege of enriching the iOS platform. Fortunately, MacInCloud costs around $ 25 a month. You are given Mac with Xcode already installed. You can connect to it remotely using Windows Remote Desktop, or even through the web interface.
But collecting an Xcode project and submitting it to the site is not enough. I had to generate a security certificate on the site for developers, then create a new application profile on a separate iTunes Connect site and send the package there for approval.
But this is not all: since Apple is hostile to web applications, I had to install special frameworks and add Cordova plugins that allow my application to play music in the background, add the current song to the lock screen, control playback there, and other actions.
It took me a week to bring the application to working condition with all sorts of tricks before I could send it to the store.
Winner : Microsoft. Imagine: you can go to the site generating the package from your web application. Or you can even download command line tools that do all this. Prefer graphical interfaces? It offers free Visual Studio.
Catching up: Google. Requires Android Studio, but it's free, works everywhere, and is easy to use.
Loser : Apple. I do not have to buy Mac for a few thousand dollars, just to build the application. The confusion with the Apple Dev Center -> iTunes Connect looks like an attempt to take developers away from real life to drive developers into iTunes. You just had to combine everything into one Apple Developer Center.
Application testing
When you finally read all the spells that turn your web application into a mobile application package, you may want to send it to testers before allowing a crowd of unwashed users to access it.
- Apple : Your testers should install Test Flight on their iOS devices. Then add the testers email addresses to iTunes Connect. Each of them will receive a notification and will be able to test the application before it becomes available in the store.
- Google : In Android Dev Center, add tester addresses. After that, the alpha / beta version will be available to them in the store.
- Microsoft : I have not tested on this platform, so I can’t say anything.
Winner : Not clear. The Apple Test Flight app is easy to use. Admin can control alpha / beta validity. Google is also not too annoying, does not even require a separate application.
App Approval
When your product is ready for prime time, you submit it for approval. The application passes an automatic checklist (for example, do you have an icon to run?) And is checked by people ("your application is clone X, we reject it").
- Apple : Xcode will warn you of potential problems during the build before shipping. Checking people takes 24-48 hours.
- Google : is anyone at home? Android Studio did not warn of possible problems, and the application was approved within a few minutes after sending. I do not think that one of the people checked it.
- Microsoft : after sending, a quick automatic checklist revealed an error related to the wrong icon format. And after passing the checklist, an employee approved my application after four days.
Winner : Apple.
Of course, as a developer, I like that my application instantly hit Google Play. But I suspect only because a person did not look at him.
And as for human verification, it takes Apple the least time. Updates are also approved within 24 hours.
Microsoft did it somehow: the initial approval took 3-4 days, and the subsequent update was approved in a day. And the second update, added for the Xbox platform, again claimed 3-4 days.
Conclusion
To take the finished PWA, bring it to working condition on mobile platforms and place it in stores is hard and costs money.
Winner : Google. The easiest way to get to their store is the application. They also have the easiest integration with the native platform thanks to the standardization of the web APIs accessed by the OS (hello, favorite navigator.mediaSession).
Catching up : Microsoft. The easiest way is to use magic to turn PWA into a package that can be sent to the store (this can be done for free using the PWABuilder website !). Integration with their platform implies automatic implementation of the window.Windows. * API API namespace into the JavaScript namespace. Will go.
Loser: Apple. Do not make me buy Mac to build an iOS application. Do not force me to use native wrappers for integration with your platform. Do not fool me with your security certificates, let your build tools do them for me and automatically attach them to my Dev Center account. Do not force me to use two different sites: Apple Dev Center and iTunes Connect.
Final thoughts: the web always wins. He crushed Flash. He killed Silverlight. He destroyed native desktop applications. The browser is a powerful client platform. The OS has become a means of launching a browser and linking hardware.
The web will win in the mobile segment. Developers do not want to develop three separate applications for the main platforms. Companies do not want to pay for the development of three applications. We can create powerful web applications - PWA - and pack for all app stores.
Apple is tempted to stop the development of the web. Microsoft had the same temptation in the late 1990s and early 2000s: it wanted to be a platform for good applications. PWA destroyed these plans, now they are everywhere.
Wangyu: in the end, PWA will prevail over native mobile applications. In 5-10 years, native iOS applications will become as widespread as Win32 C applications. Apple will kick and scream, trying to keep iOS Safari away from this trend, blocking the development of PWA in every way (even their recent “support” for PWA in iOS Safari 11.1 is just disfigured PWA ).
I suggest that mobile platforms automatically add high-quality PWAs to application stores, or allow developers to easily (for example, for free and in three clicks) add PWAs on their own.