-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Node-webkit cannot be submitted to MacOSX App Store #936
Comments
+1 |
Node-webkit uses CEF. CEF cannot be submitted to the Max OSX App Store. The "chromium" project includes private Apple API's on the Mac that do not allow submission into the App Store. Kind of funny that Apple doesn't allow it's own private API's, but they don't. The only option would be to use "webkit" on mac. As Chromium moves away from WebKit and onto Blink I suspect some of those if not all of those private API's will eventually be replaced. But for now there isn't much that can be done. |
@dubcanada node-webkit from my understanding does not use CEF, I believe it started out trying to use CEF but then decided to just branch from the shell example in chromium. The private API's generally just mean deprecated API's or debug API's. Its best practice not to use these but sometimes going through and updating code to remove harmless debug code or update your code base when Apple issues a new SDK is a pain. So I get why it might contain private API's. I don't think the Mac App Store requires using the native Apple WebView, I know they require it on iPhones, but I can't find any documentation online the mac app store that requires using Apple's WebView/WebKit. Do you have any information on this? After reviewing the response from Apple concerning someones mac app store submission one of the complaints was the use of CFLog which is a deprecated debugging tool. Removing or changing these to more-up-to-date code such as NSLog that's backwards compatible shouldn't be too hard. It could easily be wrapped in a MACRO and set on compile time to prevent nasty merge issues and help make rebasing easy. At any rate. Hopefully if I get two free seconds in the next week i'll be able to take a look at this. Cheers. |
You are indeed right, it doesn't use CEF anymore. It used Chromium though, all CEF is, is a wrapper for Chromium. Same with Node-webkit. The problem is Chromium. The problem is people are not using Apple WebKit, which is what WebViews are based off of. For example QTWebKit and Adobe Air WebKit are also not allowed in the Mac App Store. But then again it depends how they are compiled. Most of the issue lies with video/audio. I think Roger can comment more. |
I'm not familiar with Apple's policy, but node-webkit is based on Chromium, which uses private APIs. I came across those part in the code and it seems that some tricky things have to be done with those APIs on OSX. I hope upstream could convert those code to use public APIs at some point, or I would look into it some day. |
As Chromium moves away from WebKit, some of those API's will be replaced. Others will need to be replaced, but it could be something to look at down the road. |
Does anyone know of any tools to check for private-library policy compliance with a MacOS X app? It would be handy to run it past node-webkit and know for sure. |
This is the main thing that keeps me from using Node-webkit (or similar competitors). Deployment to the MAS is a must for us. Solving this somehow, or allowing for Chromium on Windows, and native Webkit on the Mac, would be pretty awesome. (I realize that neither is trivial). |
meanwhile we can do this for mac appstore |
That's true @morgondag. You can also use Macgap: https://github.com/maccman/macgap |
@Taytay great tips! thank you. |
I checked with the recent rebase to Chrome 29, it seems all of the old API symbols have been automagically removed by chromium. Thank the upstream gods?.. I'll try creating a simple JavaScript debugging tool and submitting it to apple to see if they find issues. |
That's great news @trevorlinton! Good luck! |
@trevorlinton keep us updated, nice work! |
Mark, wish the good news |
I've successfully had my app accepted to the MacOSX store without problems. I'll go ahead and close this out unless anyone has any other comments. It seems the Chromium authors decided to remove deprecated API's from the v29 release coincidently fixing all of the submission problems. |
Woah @trevorlinton, that's huge! Thank you for testing this! |
Seriously, @trevorlinton huge for us! Thanks. |
Cool! |
@trevorlinton what's the name of your app? Would like to check it out :) |
@trevorlinton I second that - I'd also like to check out the app you submitted! |
Anyone else have success with this? |
@Leukhin Yes, i've helped a few people get their apps submitted, all of them Tint or node-webkit based. There’s a guide here: https://www.trueinteractions.com/submitting_to_the_mac_app_store.rtf The 0.93 binary for node-webkit that’s compatible with the Mac App Store is here: https://www.trueinteractions.com/nw-macappstore.zip You can also find an automated signing script here: https://www.trueinteractions.com/macstore_sign.sh The diff for the mac app store patch is here: The only caveat is that you'll need to be careful if you're reading, writing to anything outside of the user data directory or creating network connections / accessing devices (such as bluetooth). Entitlements need to be carefully set (see the signing script to change them). |
@trevorlinton Thank you very much. I have no experience with Mac App Store, but think it's will be interesting. UPD: The requested URL /macstore_sigh.sh was not found on this server. |
@trevorlinton Thanks for your comments, I'm now building my app successfully and I'll try to submit it into Mac App Store. |
👍 huzzah |
Did it work, @trevorlinton? Can NWJS be submitted to the app store? |
yep, what's the current status about Mac App store? |
See an update about this here: #3258 (comment). |
Due to private api's being used node-webkit isn't passing Apple's review for their app store. This would require looking into why private api's are being used. Most likely either debug code or possibly older SDK's using deprecating API's.
See:
https://groups.google.com/d/msg/node-webkit/qP_x9Z0lEO4/0Fo7mnT45z0J
For Apple's response.
The text was updated successfully, but these errors were encountered: