Open datacloudconsulting opened 4 years ago
Hello datacloudconsulting, thank you for opening an issue with us!
I have automatically added a "needs triage" label to help get things started. Our team will investigate the issue and help solve it ASAP. Other community members may also look into the issue and provide feedback π
pwabuilder-lib/lib/manifestTools/assets/web-manifest.json has a comma near the end that should not be there.
Thank you, I could correct that... But now I have another problem:
pwabuilder https://mask-diy.datacloud.today -p ios -f w3c -l debug
[info ] pwabuilder : Scanning https://mask-diy.datacloud.today for manifest...
[warn ] pwabuilder : No manifest found. A new manifest will be created.
Error: response code for https://mask-diy.datacloud.today/favicon.ico was 404
at Request._callback (C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\pwabuilder-lib\lib\manifestTools\manifestCreator\scrapers\icons.js:55:33)
at Request.self.callback (C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\request\request.js:185:22)
at Request.emit (events.js:311:20)
at Request.
How can I specify to use a lower cordova-ios version ?
I need an answer for that as well :) I tried manually lowering the version but that is not enough.
Unfortunately, we're no longer supporting iOS through PWABuilder because of Apple's new app store policy.
We're in talks with Apple to clarify their policy. If they reopen PWAs in their app store, we'll support iOS builds again.
In the meantime, as a workaround, we suggest you use Cordova directly: https://github.com/apache/cordova-ios
But beware the Apple's current stance is they will not accept PWAs in the app store.
@JudahGabriel the probleme is UiWebView or really policy ?
Policy. See Apple's Updates for HTML5 Apps.
This issue has been marked as "needs attention π" due to no activity for 15 days. Please triage the issue so the fix can be established.
Not trying to complain, but it's weird because some apps like "LinkedIn Learning" are basically this... And it makes sense for this kind of features.
Is anyone aware of a previous version which was able to finish this process ?
Yeah, Apple hasn't removed existing apps, but as we understand it, they may not approve new apps.
We just spoke with Apple's WebKit team this week about this. We're meeting with their App Store team this month, and hopefully they'll clear up the issue. If they come back and say, "We won't automatically reject apps built with web technologies", then we'll re-enable (and refresh the code) for iOS platform.
This issue has been marked as "needs attention π" due to no activity for 15 days. Please triage the issue so the fix can be established.
We're meeting with their App Store team this month, and hopefully they'll clear up the issue
Any updates re iOS @JudahGabriel ?
Yeah, Apple hasn't removed existing apps, but as we understand it, they may not approve new apps.
We just spoke with Apple's WebKit team this week about this. We're meeting with their App Store team this month, and hopefully they'll clear up the issue. If they come back and say, "We won't automatically reject apps built with web technologies", then we'll re-enable (and refresh the code) for iOS platform.
Please share the updates on this.
@MrVibe , then ? PWABuilder re-enable IOS ?
The update: we spoke with a guy from Apple's webkit team. He couldn't give us an answer as to the App Store's policy about HTML5 apps. He told us he would reach out to the App Store team and get back to us. That was a few weeks ago. We haven't yet heard from him. We may need to poke him again. @davrous
@JudahGabriel : So, can we modify the generated IPK from the PWABuilder and customize it to include some pages which are contained in the App. So app becomes a stand alone module as well and it would pass the Apple store's policy that app should work standalone container. Any guides on above can be really helpful.
@nseb The PWAbuilder can reenable iOS but the Apple will not approve the app into their appstore. I think that is the only reason PWABuilder stopped creating iOS apps.
can we modify the generated IPK from the PWABuilder and customize it to include some pages which are contained in the App. So app becomes a stand alone module
That's one option we could take if Apple comes back and says, "No, we will not accept any PWA to the store."
We first want to hear those words from Apple before we start investigating other options.
Hi. I find PWABuilder great. I am interested in publishing on AppStore. doing research. I found it interesting what this article published on Apple's page for developers says. in which it explains that it will no longer accept applications with the UIWebView and WebView frameworks. and that only accept this framework WKWebView to work with web technology.
Yep, if we decide to pursue iOS as a platform target, we'll likely use WKWebView-based solution.
Have there been any updates to this situation? The rumor was that "app-bound domains" in iOS14 were supposed to spell the way forward for SW (and thus PWAs)... did anything like that materialize?
Yes. We are actively investigating adding iOS and Mac back as platform options.
Our main concern is that Apple's broad and ambiguous policy seems to suggest they will not approve PWAs in their Store simply because they use dynamic resources (e.g. HTML, JS, CSS fetched from the web).
We have attempted to clarify this with Apple several dozen times through official channels. We never got a straight answer.
We have received reports of some users getting their PWAs in the Store. Whether that's Apple's oversight or legit allowance is unknown.
So, we're planning on building an iOS and Mac template, publishing to the Stores and seeing if we get resistance. If we don't get resistance, we'll likely re-enable these platforms on PWABuilder with a "buyer beware" caveat of Apple's policy against HTML5 apps.
Do you think that there's some way for us to package the PWA in such a way where all the resources are included but the service worker is disabled, so the app never makes network requests to get updates? I was imagining something like that might help a PWA be more "friendly" to Apple.
Or, maybe PWAB could replace your PWA's service worker with a stub one that never updates, and is wired to only ever serve the resources from cache?
Sort of? You could build a service worker that only serves from the cache. But that removes some of the benefits of the web, doesn't it? One of the awesome things about the web is you can publish without anyone's permission; if a service worker only serves from the cache, there's no updating your PWA without going through Apple.
Another benefit of the web is that your app runs on all platforms; you don't need to build separate apps for each platform. Going down the "has all the files packaged inside it" route disables this advantage of the web.
Bottom line: if we did something like, "Here's a PWA that only works on iOS, and all its files are packaged with it", well, we're losing something special about the web, IMO. And, at that point, you might as well just build a native app for iOS.
As a side note, there are some proposed standards in the works that package web apps into a single file. But it's intended to solve a different problem. And I'm not sure this is the best path forward for PWAs on iOS.
I think our best bet right now is build a template that works well on iOS and Mac, enable that through PWABuilder with a warning about Apple's ambiguous store policies regarding PWAs.
Here's how I see it:
I have been a web technologies developer for over 20 years. It's my goto toolbox for any "app" I want to build. Sometimes that app lives on the web, sometimes it lives entirely in the CLI (node.js app), etc. My latest push here is to take some of my "apps" and actually put them on mobile devices (phones, tablets). I love that PWAB helps me do that without having to learn a whole new set of technologies, like Java, Swift, Objective-C, etc.
That's the primary benefit I see and prioritize for writing PWAs: write once, deploy everywhere (almost).
Obviously, "always updating" is a nice feature of that strategy, as that's built into the DNA of the web. But it's not, arguably, built into the DNA of the app store driven app ecosystem. At least, not yet.
Of all the parts of what makes PWA great, "always updated" is, I think, the least "app-store compatible" of those features. I wish all apps were "always updated", but I sympathize with the concerns of curated app approvals not really allowing that to happen.
My sense of reading the Apple tea leaves is that this aspect of "web apps" is their biggest concern (or one of their biggest). I don't get the sense that they feel HTML/CSS/JS are inferior or cannot create suitable or great app experiences for users. I don't think they feel Safari is inherently an under-performing app delivery renderer. I sense that what they're worried about is apps that can update and change themselves without ever getting any further review beyond the initial review.
I still like to build for the "always updating" web, but if there's something I had to compromise to get my apps in front of the eyeballs of a billion iOS users worldwide, it would be sacrificing the "always updating" part, for sure.
Just because I take a PWA and freeze a snapshot of it for a release on the app store doesn't mean that I've gutted most, or even all, of what makes a PWA a PWA. It's still built with all the W technologies, it's still built to be responsive to the screen size and orientation of the user's device, it's still built to run great offline, it can still make great use of all the web's inherently powerful accessibility capabilities, etc. These are all huge wins over writing a dedicated native app, IMO.
IOW, 90% or more of what makes a PWA great is still achievable even if the last 10% (always updating) isn't. Right now, I get almost no visibility on the iOS device ecosystem, because the only tools I know how to use effectively are web technology tools, and there's no good strategy for taking my code and packaging it like Apple wants to see it.
So, it's a question of about 0% (TBF, a little more than that, since those who find the website can "install" the PWA via "add to home screen") as the current status quo for me reaching iOS world, versus a much wider potential audience if I can "turn off" the seemingly most offensive part of the PWA equation ("always updating") and keep everything else the same.
It's not an option, nor pragmatic, for me, a single developer building stuff on my free time, to just go learn Swift or Objective-C, and completely rebuild a 5k-10k line application just for that one market. I would like to be able to use PWAB to target iOS, even in that compromise scenario, as opposed to going at it on my own and almost certainly coming up short.
I don't think what I'm suggesting invalidates or blocks what you're suggesting, btw. It would make complete sense to try an always-updating full PWA on the app store, as a canary in the coal mine, and see how Apple reacts (since they won't just tell us directly). Call that Option A.
But in addition to that, and as a fallback, it would be nice if for Option B, there was a 90% compromise step being contemplated and planned for, as opposed to just being forever stuck at 0% like I currently am.
And as far as I can tell, Option B would basically use almost all of what you'd build for Option A, but include a little bit of difference in there for shutting down the auto-updating part somehow. I think Option A and Option B apps would be mostly identical except for that one point. You could even let users choose between those two options, letting them gamble the odds of Apple's opaque app review processes.
For example:
"Option A apps are the most web like, and are always as updated as you keep your code on your server. But they run more of a risk of being rejected by App Store review. Option B apps are safer and more likely to get approval, but they require you to manually push out App Store updates, just like traditional native apps do."
Hope that helps explain my perspective.
Thanks for the feedback, @getify! Eloquently stated.
If it turns out the "always updating" part is the big no-no in Big Brother Apple's eyes, we'll work around that, possibly via service worker or possibly via the web bundle standard.
First steps first: we'll finish our experiment with publishing a PWA in the iOS store using modern iOS stack (WKWebView, etc), and if things go well, we'll run with that until we're told no. :-)
Hello everyone.
I think 6 months would be enough for Apple to reject the PWABuilder application.
If after 6 months it is still published in the AppStore, it means that it is already 90% sure that it will continue to be long.
I'm so glad that the PWABuilder team is so kind and helpful to the web community.
Greetings.
Carlos
I would really hope to not have to wait that long to be able to submit my app.
In fact, could I be so bold as to offer: let's use my app (free, educational) as a test app for this purpose.
You could obviously also do the template app in parallel, but we could start testing Apple's feelings on this issue earlier. I'm certainly happy to be the guinea pig.
What do you think?
@getify thank you for offering. With your Flash Math Cards app, what's the status now -- have you built the iOS app? Submitted it to the iOS Store?
I've built and submitted it to Android and Windows app stores, and (apparently) to Samsung store.
I don't know how to build it for iOS myself. But I would love to collaborate with you all to use my app as the test app for your iOS bundling feature -- basically, since mine is stable and ready to go, it means we could test out what Apple thinks of it earlier than waiting to get your template app ready. If Apple rejects it, it won't hurt my feelings... we can just tweak how the bundling works and try again.
Happy to pitch in with whatever steps would be useful to you.
Do you have an Apple Developer account? We could send you the iOS template we're planning on using. You'd need a Mac with Xcode to build it for now.
Do you have an Apple Developer account?
Not yet, but was obviously planning on signing up for one as soon as was necessary. Can do so right away if we're ready to try this out.
We could send you the iOS template we're planning on using.
Great. Any help you can provide in how to "use" that with my stuff would be appreciated. Like, is it just setting a start URL somewhere, or is it more involved? I've never done any native iOS/Mac app development before.
You'd need a Mac with Xcode to build it for now.
I have a spare macbook air that I can install Xcode on and am happy to do so.
Hello, any updates? did you publish youre app?
@getify I've attached the template we've been planning to use. It's by a member of our community who successfully got his app into the iOS Store. From here, it's a matter of changing the app name, URL, swapping the icons, then building it in XCode.
If you publish your app, let us know the results. We're doing the same. If we all get approved, that will be a good signal for adding this to PWABuilder.
@getify I've attached the template we've been planning to use. It's by a member of our community who successfully got his app into the iOS Store. From here, it's a matter of changing the app name, URL, swapping the icons, then building it in XCode.
If you publish your app, let us know the results. We're doing the same. If we all get approved, that will be a good signal for adding this to PWABuilder.
Has anyone tried this template?
Has anyone tried this template?
@SkyAgency I found this topic because we are looking to implement our PWA to the AppStore and we will also be trying to use this template to publish our app as soon as we can. I'll keep you updated.
Thank you for sharing the template @JudahGabriel !
After two long weeks of answering questions and getting refused for multiple reasons (none concerning the use of a web view), I can finally say that our PWA got accepted and is on now the App Store !
@GabrielViallon Great ! packaging with PWABuilder ? ServiceWorker works in webview Safari ?
Yes, service worker works in the template above.
Hi,
I can't manage to use pwabuilder to build my app.
Here's the exact command I run and output : `C:\Users\maxim\Documents\DataCloud\GitHub\PWABuilder>pwabuilder https://mask-diy.datacloud.today/en/home/ -p ios -l debug
[info ] pwabuilder : Scanning https://mask-diy.datacloud.today/en/home/ for manifest...
[error] pwabuilder : SyntaxError: Unexpected token } in JSON at position 7427 at JSON.parse ()
at Object.matchFormat (C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\pwabuilder-lib\lib\manifestTools\transformations\w3c.js:24:21)
at Object.detect (C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\pwabuilder-lib\lib\manifestTools\manifestTypeDetector.js:10:39)
at processManifestContents (C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\pwabuilder-lib\lib\manifestTools\manifestLoader.js:70:45)
at Promise.apply (C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\q\q.js:1185:26)
at Promise.promise.promiseDispatch (C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\q\q.js:808:41)
at C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\q\q.js:1411:14
at runSingle (C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\q\q.js:137:13)
at flush (C:\Users\maxim\AppData\Roaming\npm\node_modules\pwabuilder\node_modules\q\q.js:125:13)
at processTicksAndRejections (internal/process/task_queues.js:79:11)`
I tried to understand but there's not much information available. Can you confirm if this is issue is on my side, on the website, or in pwabuilder ?
Thank you :)