构建meteor应用程序

by JudahGabriel Himango

犹大(Gabriel Himango)

我构建了一个渐进式Web应用程序并将其发布在3个应用程序商店中。 这是我学到的。 (I built a Progressive Web App and published it in 3 app stores. Here’s what I learned.)

一个月的工作，几百美元和很多繁文tape节。 (One month of work, several hundred dollars, and lots of red tape.)

I recently published Chavah Messianic Radio, a Pandora-like music player, as a Progressive Web App and submitted it to the 3 app stores (Google Play, iOS App Store, Windows Store).

我最近发布了Chavah Messianic Radio (类似于潘多拉的音乐播放器)作为渐进式Web应用程序，并将其提交给了3个应用程序商店(Google Play，iOS App Store，Windows Store)。

The process was both painful and enlightening. Here’s what I learned.

这个过程既痛苦又启发人。 这是我学到的。

为什么？ (Why?)

First, 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.

简而言之，答案是因为那是用户所在的位置 。 我们已经培训了一代用户来在专有应用商店中而不是在免费和开放的网络上查找应用。

For my web app, there were 2 big reasons to get in the app store:

对于我的网络应用程序，进入应用程序商店有两个主要原因：

1. User demand用户需求
2. Web app restrictions by Apple hostile mobile platformsApple恶意移动平台对Web应用程序的限制

User demand: My users have been asking me for years, “Is there an app for Chavah? I don’t see it in the store.”

用户需求：我的用户多年来一直在问我：“ Chavah是否有应用程序？ 我在商店里看不到它。”

They ask that because we’ve trained users to look for apps in proprietary app stores.

他们之所以这样问，是因为我们已经培训了用户在专有应用商店中查找应用。

My response to my users has up until now been,

到目前为止，我对用户的回复是，

“Aww, you don’t need an app — just go to the website on your phone! It works!”

“噢，您不需要应用程序-只需通过手机访问网站！ 有用！”

But I was kind of lying.

但是我有点说谎。

Real web apps only kinda-sorta work on mobile. Which brings me to the 2nd reason: web app restrictions by Apple hostile mobile platforms.

真正的网络应用只能在移动设备上运行。 这使我想到第二个原因：Apple恶意移动平台对Web应用程序的限制。

Mobile platform vendors, like Apple, are totally cool with apps that use your phone to its fullest. Access your location, play background audio, get your GPS coordinates, play more than one thing at a time, and more.

苹果等移动平台供应商对于完全使用手机的应用程序非常满意。 访问您的位置，播放背景音频，获取GPS坐标，一次播放多个内容，等等。

Apple’s totally cool with that.

苹果对此非常酷。

But only if you pay Apple $99/year for the privilege.

但前提是您需要每年向Apple支付99美元的特权。

If you want to do any of those things in a regular old web app, well, goshdarnit, Apple won’t just deny you these things, it prevents you from even asking permission.

如果您想在常规的旧Web应用程序中执行任何这些操作，那么，天哪，Apple不仅会拒绝您执行这些操作，还会阻止您甚至征求许可 。

For my Pandora-like music player app, this horrible brokenness showed up in numerous ways.

对于我的类似Pandora的音乐播放器应用程序而言，这种可怕的破坏以多种方式表现出来 。

From minor things like “iOS Safari won’t let you play audio without first interacting with the page” to major, show-stopping things like, “iOS Safari won’t let you play the next song if your app is in the background or if your screen is off.”

从次要的事情(例如“ iOS Safari不允许您先不与页面进行交互就无法播放音频”)到主要的，令人大跌眼镜的事情，例如“如果应用程序在后台运行，则iOS Safari不允许您播放下一首歌曲或如果您的屏幕关闭了。”

Oh, plus weird visual anomalies like typing in a textbox and seeing your text appear elsewhere on screen.

哦，还有怪异的视觉异常，例如在文本框中输入文字，然后看到您的文字出现在屏幕上的其他位置 。

So, to make my HTML5 music app actually functional and working on people’s mobile devices, it was necessary to turn my PWA into an app in app store.

因此，要使我HTML5音乐应用程序真正起作用并在人们的移动设备上工作，有必要将我的PWA变成应用程序商店中的应用程序。

进入壁垒 (Barriers to entry)

In the ideal world, publishing your web app to the app stores would look like this:

在理想情况下，将您的Web应用发布到应用商店中将如下所示：

• Your Web/Cloud Host or Continuous Integration Provider您的Web /云主机或持续集成提供商
• You’ve published a Progressive Web App. Publish to app stores?您已经发布了渐进式Web应用程序。 发布到应用商店？

☑ iOS App Store

☑iOS应用商店

☑ Google Play

☑Google Play

☑ Windows Store

☑Windows应用商店

(Or alternately, as Microsoft is experimenting with, your PWA will just automatically appear in the app store as Bing crawls it.)

(或者，作为Microsoft的试验 ，您的PWA将在Bing对其进行爬网时自动显示在应用商店中。)

But alas, we don’t live in this ideal world. Instead, we have to deal with all kinds of proprietary native BS to get our web apps in the stores.

但是，a，我们并不生活在这个理想的世界中。 相反，我们必须处理各种专有的本机BS才能在商店中获取我们的Web应用程序。

Each of the app stores has a barrier to entry: how difficult it is to take an existing web app and it in the app store.

每个应用程序商店都有一个进入壁垒：将现有的Web应用程序和应用程序放入应用程序商店有多困难。

I list some of the barriers below.

我在下面列出了一些障碍。

成本 (Cost)

• Apple: $99/year to have your app listed in the iOS app store.

  苹果 ：每年$ 99美元，即可在iOS应用商店中列出您的应用。

• Google: One-time $25 fee to list your app in the Google Play Store.

  Google：一次性收取25美元，即可在Google Play商店中列出您的应用。

• Microsoft: Free!

  微软：免费！

Don’t make me pay you to make my app available to your users. My app enriches your platform. Without good apps, your platform will be abandoned.

不要让我付钱让您的用户使用我的应用程序。 我的应用程序丰富了您的平台。 没有良好的应用程序，您的平台将被废弃。

Apple used to understand this. When it first introduced the iPhone, Steve Jobs was adamant that HTML5 was the future and that apps will simply just be web apps. There was no native iPhone SDK for 3rd parties. Apple has since abandoned this vision.

苹果曾经了解这一点。 当史蒂夫·乔布斯(Steve Jobs)首次推出iPhone时，他坚信HTML5是未来，而这些应用程序将仅仅是Web应用程序。 没有用于第三方的本地iPhone SDK 。 此后，苹果公司放弃了这一愿景。

Google asked for a token $25 one-time fee. Probably to avoid spammers and decrease truly junk apps from entering the store.

Google要求一次性支付25美元的象征性费用。 可能避免垃圾邮件发送者，并减少真正的垃圾应用程序进入商店。

Microsoft seems determined to just increase the total number of apps in their app store, regardless of quality.

微软似乎决心不考虑质量而只增加其应用商店中的应用总数。

Winner: Microsoft. It’s hard to beat free.

优胜者： Microsoft。 很难被击败。

添加本机功能 (Adding native capabilities)

In an ideal world, I wouldn’t have to write a single extra line of code for my web app to integrate into the OS. Or, as Steve Jobs said back in 2007,

在理想的情况下，我不必为Web应用程序写一行额外的代码即可将其集成到OS中。 或者，就像史蒂夫·乔布斯(Steve Jobs) 在2007年所说的那样 ，

“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.”

“完整的Safari引擎位于iPhone内部。 因此，您可以编写出色的Web 2.0和Ajax应用程序，这些应用程序的外观和行为与iPhone上的应用程序完全相同。 这些应用程序可以与iPhone服务完美集成。 他们可以打电话，可以发送电子邮件，可以在Google地图上查找位置。”

-Steve Jobs, 2007

-史蒂夫·乔布斯(Steve Jobs)，2007年

For me, that means my web app plays background audio using standard HTML5 audio; that works just fine on all OSes.

对我来说，这意味着我的Web应用程序使用标准HTML5音频播放背景音频； 在所有操作系统上都可以正常工作。

My web app declares what audio is playing, and the OSes pick up on that, show currently playing song info on the lock screen.

我的Web应用程序声明正在播放的音频，然后操作系统进行拾取，并在锁定屏幕上显示当前正在播放的歌曲信息。

My app controls audio using standard HTML5 audio API; the OS picks up on that and provides play/pause/next/volume/trackbar controls on the lock screen.

我的应用使用标准HTML5音频API控制音频； 操作系统会对此进行提示，并在锁定屏幕上提供播放/暂停/下一个/音量/轨迹栏控件。

But sadly, we don’t live in this ideal world. All the things listed above don’t actually work out of the box on all 3 platforms.

但是可悲的是，我们没有生活在这个理想的世界中。 上面列出的所有内容实际上在所有3个平台上都不是开箱即用的。

My web app needs to play audio in the background. And load URLs from my CDN. Sounds reasonable, right? And bonus, how about showing currently playing song info on the lock screen? And controlling the audio (play/pause/next, etc.) from the lock screen? How hard is this?

我的Web应用程序需要在后台播放音频。 并从我的CDN加载URL。 听起来合理吧？ 另外，如何在锁定屏幕上显示当前播放的歌曲信息？ 并从锁定屏幕控制音频(播放/暂停/下一个等)？ 这有多难？

Three very different approaches taken here:

这里采用了三种非常不同的方法：

• Apple: We don’t give web apps a way to declare such capabilities; you’ll need to write a native wrapper (e.g. with Cordova) to interact with the OS.

  苹果 ：我们没有为网络应用提供声明这种功能的方法； 您需要编写一个本地包装器(例如，使用Cordova)才能与操作系统进行交互。

• Google: Web FTW! Let’s create a new web standard that shows audio & controls from the lock screen. Background audio? Sure, go ahead!

  Google ：网络FTW！ 让我们创建一个新的Web标准 ，从锁定屏幕显示音频和控件。 背景音频？ 好，去吧！

• Microsoft: We’ll inject our proprietary API, window.Windows.*, into your JavaScript global namespace and you can use that to do the things you want to do.

  微软：我们将专有的API window.Windows。*注入到JavaScript全局命名空间中，您可以使用它来完成您想做的事情。

Going into more details here for each store:

在这里详细了解每个商店：

For iOS app store, does your web app need to play background audio? Use a Cordova plugin. Need to show currently playing song on the lock screen? Use a Cordova plugin. Need to control the currently playing song from the lock screen? Use a Cordova plugin. You get the idea. Basically, Cordova tricks Apple into thinking you’re a native app. And since you’re not a yucky web app, Apple lets you do all the things native apps can do. You just need native tricks — Cordova plugins — to let you do it.

对于iOS应用商店，您的Web应用是否需要播放背景音频？ 使用Cordova插件 。 是否需要在锁定屏幕上显示当前播放的歌曲？ 使用Cordova插件 。 是否需要从锁定屏幕控制当前播放的歌曲？ 使用Cordova插件 。 你明白了。 基本上，Cordova诱使Apple认为您是本机应用程序。 而且由于您不是一个讨厌的Web应用程序，Apple允许您执行本机应用程序可以执行的所有操作。 您只需要本地技巧-Cordova插件即可。

For Google Play, it’s nice that I can just write JS code to make this work; no Cordova plugins required here. Of course, that JS won’t work anywhere except Chrome on Android…but hey, maybe one day (in an ideal world!) all the mobile browsers will implement these web APIs…and the world will live as one. I’m almost ready to bust out some John Lennon hippie utopia tunes.

对于Google Play，很高兴我可以编写JS代码来完成此工作； 这里不需要Cordova插件。 当然，除了Android上的Chrome之外，该JS无法在其他任何地方运行……但是，嘿，也许有一天(在理想的世界中！)所有的移动浏览器都将实现这些Web API……世界将像一个世界一样生活。 我几乎准备结束约翰·列侬的嬉皮乌托邦曲调。

For Windows Store, do you want to play background audio? Sorry! That is, unless you declare your intentions in our proprietary capabilities manifest file (easy) AND you implement this proprietary media interface using window.Windows.SystemMediaTransportControls (not so easy). Otherwise we’ll mute you when your app goes to the background.

对于Windows Store，您要播放背景音频吗？ 抱歉! 也就是说，除非您在我们的专有功能清单文件中声明您的意图(简单) ，然后使用window.Windows.System.MediaMediaTransportControls (不是那么容易)实现此专有媒体接口。 否则，当您的应用程序进入后台时，我们会将您静音。

Winner: Google. I want to be able to just write JavaScript, and let the OS pick up cues from my app.

优胜者 ：Google。 我希望能够编写JavaScript，并让操作系统从我的应用中获取提示。

Runner-up: Windows. I can still write plain old JavaScript, but I need to talk to a proprietary Windows JS API that was injected into my process when running on Windows. Not terrible.

亚军 ：Windows。 我仍然可以编写普通的旧JavaScript，但是我需要谈谈在Windows上运行时注入到我的进程中的专有Windows JS API。 不可怕

Loser: Apple. They don’t care about web apps. Actually, it’s worse than that. It feels like they are actually hostile to web apps. iOS Safari is the new Internet Explorer 6. It has lagged behind in nearly every web standard, especially around Progressive Web Apps. This is probably for business reasons: web apps disrupt their $99/year + 33% in-app purchases racket. So to make my web app work on their platform, I have to basically pretend I’m a native app.

失败者 ：苹果。 他们不在乎Web应用程序。 实际上，这比那更糟。 感觉他们实际上对网络应用程序怀有敌意 。 iOS Safari是新的Internet Explorer6。它几乎在所有Web标准中都落后，尤其是在Progressive Web Apps周围。 这可能是出于商业原因：网络应用破坏了他们每年99美元的应用+ 33％的应用内购买球拍。 因此，要使我的Web应用程序在其平台上工作，我必须基本上假装自己是本机应用程序。

App Store注册 (App Store Registration)

Submitting your PWA to the app store requires registration, business verification, and more red tape. Here’s how the 3 app stores fared:

将PWA提交到应用商店需要注册，业务验证和更多繁文tape节。 这是3个应用商店的销售情况：

• Apple: You must prove that you’re a legal, registered business. This verification isn’t done by us — but by a 3rd party, which may or may not know about your business.

  苹果 ：您必须证明自己是合法的注册企业。 该验证不是由我们完成的，而是由第三方 (可能会或可能不会了解您的业务)进行的。

• Google: You want your app in our store? Cool by us.

  Google ：您想在我们的商店中使用您的应用吗？ 酷我们。

• Microsoft: You want your app in our store? Cool by us.

  微软 ：您想在我们的商店中使用您的应用程序吗？ 酷我们。

The biggest pain point for me was getting verified as a legal business by Apple.

对我来说，最大的痛苦是被苹果公司确认为合法公司。

First, I went to the site and registered for Apple’s Developer Program. I filled out my name and company information. (Aside: I guess Apple won’t let you submit an app unless you have a registered, legal company?)

首先，我去了网站并注册了苹果的开发人员计划。 我填写了我的姓名和公司信息。 (此外：我想除非您拥有注册的合法公司，否则苹果不会让您提交应用程序？)

I click next.

我点击下一步。

“The information you entered did not match your D&B profile.”

“您输入的信息与您的D＆B个人资料不匹配。”

My…what?

我的...什么？

A bit of Googling showed that “D&B profile” is Dun and Bradstreet. I’ve never heard of this group before, but I find out that Apple is using them to verify you legal corporation details.

有一点谷歌搜索显示“ D＆B档案”是邓和布拉德斯特。 我以前从未听说过该小组，但是我发现Apple正在使用它们来验证您的合法公司详细信息。

And apparently, my D&B profile didn’t match what I put in my Apple Dev registration.

显然，我的D＆B配置文件与我在Apple Dev注册中输入的内容不匹配。

I google some more and find the Apple dev forums littered with similar posts. Nobody had a good answer.

我在Google上搜索了更多的内容，并发现有类似帖子的Apple开发论坛。 没有人有一个好的答案。

I contact Apple Dev support. 24 hours later, I’m contacted by email saying that I should contact D&B.

我联系Apple Dev支持。 24小时后，通过电子邮件与我联系，要求我与D＆B联系。

I decide to contact them…but Apple says it will take up to a few days for them to respond.

我决定与他们联系...但是Apple表示，他们最多可能需要几天时间才能做出答复。

At this point, I’m thinking of abandoning the whole idea.

在这一点上，我正在考虑放弃整个想法。

While waiting for D&B support to get back to me, I decide to go to the D&B site, verify my identity, and update my company information which, I assume, they had taken from government registration records.

在等待D＆B支持返回给我时，我决定去D＆B网站，验证我的身份，并更新我的公司信息，我认为这些信息是从政府注册记录中获取的。

Did I mention how sucky this is? I just want to list my existing web app in the store. Plz help.

我有提到这有多糟吗？ 我只想在商店中列出我现有的Web应用程序。 请帮助。

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.

我去D＆B更新我的业务资料。 惊喜！ 他们的验证逻辑中有一个JavaScript错误，阻止我更新个人资料。

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.

值得庆幸的是，我是一名熟练的开发人员。 我单击在其JavaScript中放置一个断点，然后单击提交，将isValid标志更改为true，然后瞧！ 我已经更新了D＆B个人资料。

Back to Apple Dev –> let’s try this again. Register my company…

返回Apple Dev –>让我们再试一次。 注册我的公司...

“Error: The information you entered did not match your D&B profile.”

“错误：您输入的信息与您的D＆B个人资料不匹配。”

AREYOUFREAKINKIDDINGME.

AREYOUFREAKINKIDDINGME。

Talk to Apple again. “Oh, it may take 24–48 hours for the updated D&B information to get into our system.”

再次与Apple交谈。 “哦，更新的D＆B信息可能需要24-48小时才能进入我们的系统。”

You know, because digital information can take 2 days to travel from server A to server B. Sigh.

您知道，因为数字信息从服务器A到服务器B可能需要2天的时间。

Two days later, I try to register…finally it works! Now I’m in the Apple Developer program and can submit apps for review.

两天后，我尝试注册...终于可以了！ 现在，我进入了Apple Developer计划，可以提交应用程序以供审查。

Winner: Google and Microsoft; both took all of 5 minutes to register.

优胜者 ：Google和Microsoft； 两者都花了5分钟才能完成注册。

Loser: The Apple Developer registration was slow and painful. It took about a week to actually get registered with their developer program. It required me contacting support from 2 different freaking companies. And it required me to runtime debug the JavaScript code on a 3rd party website just so that I can get past their buggy client-side validation, so that my info will flow to Apple, so that I can submit my app to the store. Wow, just…wow.

失败者 ：Apple Developer注册缓慢而痛苦。 实际花了大约一个星期的时间向他们的开发人员程序注册。 它需要我联系来自2个不同的怪胎公司的支持。 而且它需要我在第三方网站上运行时调试JavaScript代码，以便我可以通过他们有漏洞的客户端验证，这样我的信息才能传递给Apple，从而可以将我的应用提交到商店。 哇，只是……哇。

If there is any saving grace here for Apple, it’s that they have a 501c3 non-profit program, where non-profits can have their $99 annual fee waived. I took advantage of that. And perhaps this extra step complicated matters.

如果苹果有任何节省的余地，那就是他们拥有501c3非营利计划，非营利组织可以免除其99美元的年费。 我利用了这一点。 也许这额外的步骤使事情变得复杂。

应用打包，构建，提交 (App Packaging, Building, Submitting)

Once you have a web app, you have to run some magic on it to turn it into something you can submit for App Store review.

拥有网络应用程序后，您必须对其运行一些魔术，才能将其转变为可以提交给App Store审查的内容。

• Apple: First, buy a Mac; you can’t build an iOS app without a Mac. Install XCode and these build tools and frameworks, acquire a certificate from our developer program, create a profile on a separate website called iTunes Connect, link it up with the certificate you generated on the Apple Dev center, then submit using XCode. Easy as one, two, three…thirty-seven…

  苹果 ：首先，购买一台Mac； 没有Mac，您将无法构建iOS应用。 安装XCode和这些构建工具和框架，从我们的开发人员程序中获取证书，在名为iTunes Connect的单独网站上创建配置文件，将其与您在Apple Dev中心生成的证书链接起来，然后使用XCode提交。 容易做到一，二，三……三十七……

• Google: Download Android Studio, generate a security certificate through it, then package it using the Studio. Upload the package to Android Developer website.

  Google ：下载Android Studio，通过它生成安全证书，然后使用Studio打包。 将软件包上传到Android Developer网站。

• Microsoft: Generate an .appx package using these free command line tools, or Visual Studio. Upload to the Microsoft Dev Center website.

  Microsoft ：使用这些免费的命令行工具或Visual Studio生成.appx包。 上载到Microsoft Dev Center网站。

The good news is, there’s a free tool to do the magic of turning your web app into app packages. That awesome free tool is called PWABuilder. It analyzes a URL, tells you what you need to do (e.g. maybe add some home screen icons to your PWA web manifest). And in a 3 step wizard, it lets you download packages that contain all the magic:

好消息是， 有一个免费工具可以将您的Web应用程序变成应用程序包 。 那个很棒的免费工具叫做PWABuilder 。 它分析URL，告诉您您需要做什么(例如，可以在PWA Web清单中添加一些主屏幕图标)。 在一个三步向导中，它使您可以下载包含所有魔术的软件包：

• For Windows, it actually generates the .appx package. You can literally take that and submit it on the Windows Dev Center site.对于Windows，它实际上会生成.appx包。 您可以直接将其提交到Windows Dev Center网站上。
• For Google, it generates a wrapper Java app that contains your PWA web app. From Android Studio, you build this project, which generates the Android package that can be uploaded to the Android Dev Center site.对于Google，它会生成一个包装Java应用程序，其中包含您的PWA网络应用程序。 在Android Studio中，您可以构建此项目，该项目将生成可上传至Android Dev Center网站的Android程序包。
• For Apple, it generates an XCode project which can be built with XCode. Which requires a Mac.对于Apple，它将生成一个XCode项目，该项目可以使用XCode构建。 需要Mac。

Once again, Apple was the most painful of all of these. I don’t have a Mac. But you cannot build the XCode project for your PWA without a Mac.

再一次，苹果是所有这些中最痛苦的。 我没有Mac。 但是，如果没有Mac，则无法为PWA构建XCode项目。

I don’t want to pay several thousand dollars to publish my free app in Apple’s app store. I don’t want to pay for the privilege of enriching Apple’s iOS platform.

我不想花几千美元在Apple的应用商店中发布我的免费应用。 我不想为丰富Apple的iOS平台而付出的代价。

Thankfully, MacInCloud costs about $25/month, and they give you a Mac machine with XCode already installed. You can remote into it using Windows Remote Desktop, or even via a web interface.

值得庆幸的是， MacInCloud的费用约为每月25美元，他们为您提供了已安装XCode的Mac机器。 您可以使用Windows Remote Desktop甚至通过Web界面远程访问它。

It wasn’t enough to just build the XCode project and submit. I had to generate a security certificate on the Apple Developer site, then create a new app profile in a separate site, iTunes Connect, where you actually submit the package.

仅构建XCode项目并提交还不够。 我必须在Apple Developer网站上生成安全证书，然后在单独的站点iTunes Connect中创建一个新的应用程序配置文件，在该站点中您实际提交了软件包。

And that wasn’t all: since Apple is hostile to web apps, I had to install some special frameworks and add Cordova plugins that allow my app to do things like to play audio in the background, add the current song to the lock screen, control the song volume and play status from the lock screen, and more.

不仅如此：由于Apple对网络应用程序怀有敌意，因此我不得不安装一些特殊的框架并添加Cordova插件，以使我的应用程序能够执行诸如在后台播放音频的操作，将当前歌曲添加到锁定屏幕，在锁定屏幕上控制歌曲的音量和播放状态，等等。

This took at least a week of finagling to get my app into a working state before I could submit it to the app store.

在将我的应用提交到应用商店之前，至少花了一周的时间使我的应用进入工作状态。

Winner: Microsoft. Imagine this: you can go to a website that generates an app package for your web app. And if that’s not your thing, you can download command line tools that will do the job. GUI person? The free Visual Studio will work.

优胜者 ：Microsoft。 想象一下：您可以访问一个为您的Web应用程序生成应用程序包的网站。 如果那不是您的事，则可以下载可以完成此任务的命令行工具。 GUI的人？ 免费的Visual Studio将起作用。

Runner-up: Google. Requires Android Studio, but it’s free, runs everyone, and was simple enough.

亚军 ：谷歌。 需要Android Studio，但它是免费的，可以运行所有人，并且非常简单。

Loser: Apple. I shouldn’t have to buy a proprietary computer — a several thousand dollar Mac — in order to build my app. The Apple Dev Center –> iTunes Connect tangling seems like an out-of-touch manager’s attempt to push iTunes onto developers. It should simply be part of Apple Developer Center site.

失败者 ：苹果。 我不必购买专用计算机(数千美元的Mac)来构建我的应用程序。 Apple开发人员中心–> iTunes Connect纠缠似乎是管理者试图将iTunes推向开发人员的一种尝试。 它应该只是Apple Developer Center网站的一部分。

应用测试 (App Testing)

Once you finally did all the magic incantations to turn your existing web app into a mobile app package, you probably want to send it out to testers before releasing your app on the unwashed masses.

一旦您完成了所有神奇的尝试，将现有的Web应用程序变成了移动应用程序包，您可能希望在将应用程序大量发行之前将其发送给测试人员。

• Apple: For testing, you have your testers install Test Flight on their iOS device. Then you add the tester’s email in iTunes Connect. The tester will get a notification and can test your app before it’s available in the app store.

  苹果 ：要进行测试，您需要让测试人员在其iOS设备上安装“测试飞行”。 然后，您可以在iTunes Connect中添加测试人员的电子邮件。 测试人员将收到通知，并可以在您的应用商店中将其测试之前对其进行测试。

• Google: In Android Dev Center, you add email addresses of testers. Once added, they can see your alpha/beta version in the App Store.

  Google ：在Android Dev Center中，您可以添加测试人员的电子邮件地址。 添加后，他们可以在App Store中查看您的Alpha / Beta版本。

• Microsoft: I didn’t actually use this, so I won’t comment on it.

  微软 ：我实际上并没有使用它，所以我不会对此发表评论。

Winner: Toss up. Apple’s Test Flight app is simple and streamlined. You can control alpha/beta expiration simply on the admin side. Google wasn’t far behind; it was quite painless, not even requiring a separate app.

优胜者 ：加油。 苹果的Test Flight应用程序简单而精简。 您可以直接在管理员端控制alpha / beta到期时间。 Google并不落后。 这非常轻松，甚至不需要单独的应用程序。

应用程式审查 (App Review)

Once your app is ready for prime time, you submit your app for review. The review is done using both a programmatic checklist (e.g. do you have a launch icon?) and by real people (“your app is a clone of X, we reject it”)

一旦您的应用程序准备好迎接黄金时段，您就可以提交应用程序以供审核。 使用程序清单(例如，您是否有启动图标？)和真实人(“您的应用是X的克隆，我们拒绝它”)进行审核

• Apple: Prior to submission, XCode warns you about potential problems during build. The human app review takes about 24–48 hours.

  苹果 ：在提交之前，XCode会警告您有关构建期间的潜在问题。 人工应用审核大约需要24-48小时。

• Google: Anybody home? Android Studio didn’t tell me about any potential problems, and my app was approved within minutes of submission. I don’t think a real human being looked at my app.

  Google ：有人在家吗？ Android Studio没告诉我任何潜在的问题，我的应用程序在提交后的几分钟内就被批准了。 我认为没有人会看着我的应用程序。

• Microsoft: Upon submission, a fast programmatic review caught an issue pertaining to wrong icon formats. After passing, a human reviewed my app within 4 days.

  微软 ：提交后，快速的程序审查发现了与错误图标格式有关的问题。 通过后，一个人在4天内审核了我的应用。

Winner: Apple.

优胜者 ：苹果。

Sure, as a developer, I like the fact that my app was instantly in the Google Play store. But that’s only because, I suspect, it wasn’t actually reviewed by a human.

当然，作为开发人员，我喜欢我的应用程序立即在Google Play商店中的事实。 但这仅仅是因为，我怀疑，这实际上并没有被人类审查过。

Apple had the quickest turnaround time for actual human review. Updates also passed review within 24 hours.

苹果公司进行实际人工审查的周转时间最快。 更新也在24小时内通过了审核。

Microsoft was hit or miss here. The initial review took 3 or 4 days. An later update took 24 hours. Then another update, where I added XBox platform, took another 3–4 days.

微软在这里受到打击或错过。 最初的审核历时3或4天。 后来的更新花费了24小时。 然后，我在其中添加了XBox平台的另一个更新又花了3-4天的时间。

结论 (Conclusion)

It’s painful, and costs money, to take an existing PWA and get them functional on mobile platforms and listed in the App Store.

采取现有的PWA并使其在移动平台上运行并在App Store中列出，这很痛苦且要花钱。

Winner: Google. They made it the easiest to get into the app store. The made it the easiest to integrate into the native platform, by attempting to standardize web APIs that OS platforms can pick up on (hello, lovely navigator.mediaSession)

优胜者 ：Google。 他们使进入应用程序商店最容易。 通过尝试标准化OS平台可以使用的Web API，使其最容易集成到本地平台中(您好，可爱的navigator.mediaSession)

Runner-up: Microsoft. They made it the easiest to sprinkle your web app with magic, turning it into a package that can be submitted to their store. (Can be done for free using the PWABuilder site!) Integrating with their platform means using the auto-injected window.Windows.* JavaScript namespace. Not bad.

亚军 ：微软。 他们使向您的Web应用程序添加魔力变得最简单，将其变成可以提交给他们商店的包。 (可以使用PWABuilder网站免费完成！)与其平台集成意味着使用自动注入的window.Windows。* JavaScript名称空间。 不错。

Loser: Apple. Don’t require me to buy a Mac to build an iOS app. Don’t force me to use native wrappers to integrate with your platform. Don’t require me to screw around with security certificates; let your build tools make them for me, and store them automatically in my Dev Center account. Don’t make me use 2 different sites: Apple Dev Center and iTunes Connect.

失败者 ：苹果。 不需要我购买Mac即可构建iOS应用。 不要强迫我使用本机包装与您的平台集成。 不需要我随身携带安全证书； 让您的构建工具为我创建它们，并将其自动存储在我的Dev Center帐户中。 不要让我使用两个不同的站点：Apple Dev Center和iTunes Connect。

Final thoughts: The web always wins. It defeated Flash. It killed Silverlight. It destroyed native apps on desktop. The browser is the rich client platform. The OS is merely a browser-launcher and hardware-communicator.

最后的想法：网络总是赢。 它击败了Flash。 它杀死了Silverlight。 它破坏了台式机上的本机应用程序。 浏览器是富客户端平台。 该操作系统仅仅是一个浏览器启动器和硬件通信器。

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.

网络也将在移动设备上获得胜利。 开发人员不想为主要平台构建3个独立的应用程序。 公司不想为3个应用程序的开发付费。

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.

这一切的答案就是网络。 我们可以构建富Web应用程序-渐进式Web应用程序-并将其打包到所有应用程序商店中。

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.

特别是苹果公司有阻止互联网发展的不正当动机。 这与微软在90年代末和2000年代初的动机相同：它希望成为优质应用程序的平台。 PWA破坏了这一点； 他们到处跑。

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. Apple will go kicking and screaming, keeping iOS Safari behind the curve, blocking PWA progress where they can. (Even their recent “support” for PWAs in iOS Safari 11.1 actually cripple PWAs.)

我的软件智慧是：PWA最终将赢得并超越本地移动应用程序。 在5-10年内，本地iOS应用程序将与Win32 C应用程序一样普遍。 Apple会大声疾呼，让iOS Safari保持落后，并在可能的情况下阻止PWA进度。 (即使他们最近对iOS Safari 11.1中的PWA的“支持” 实际上削弱了PWA 。)

My suggestion to mobile app platforms is embrace the inevitable and either automatically add quality PWAs to your app store, or allow developers to easily (e.g. free, and with 3 clicks or less) submit a PWA to your store.

我对移动应用程序平台的建议是不可避免的，它会自动向您的应用程序商店添加高质量的PWA，或者允许开发人员轻松地(例如，免费且只需点击3次或更少)向您的商店提交PWA。

Readers, I hope this has been helpful glance at PWAs in App Stores in 2018.

读者，我希望这对2018年App Store中的PWA有帮助。

Have you submitted a PWA to an app store? I’d love to hear your experience in the comments section. And you can read more of my blog posts on my blog.

您是否已向应用商店提交了PWA？ 我很想听听您在评论部分的经验。 您可以在我的博客上我的博客文章。

翻译自: https://www.freecodecamp.org/news/i-built-a-pwa-and-published-it-in-3-app-stores-heres-what-i-learned-7cb3f56daf9b/

构建meteor应用程序