Publishing a node-webkit application on the Mac App Store

[rich...@gmail.com]

Hi there,

Loving node-webkit! I make HTML5 games and I've had a lot of luck with getting .app and .exe files for my games.

I'm at the point right now where I'd like to publish one of my node-webkit games in the Mac App Store. This can be done via an OS X application called Application Uploader, but it will not accept .app files. (I've also tried .dmg, and compressing and renaming to .iap as some forums have suggested. Neither of these attempts have worked.)

I noticed that Reditr uses node-webkit and is published on the Mac App Store, so I believe it's possible. But after a few hours of investigating online, I'm at a loss! Any ideas?

Thanks!

-Matt

[Chris Price]

I don't believe node-webkit or any Chromium-based project can be placed on the Mac App Store (somebody please correct me if I'm wrong). Reditr may still be using node-webkit for Windows and Linux, but the App Store product page lists a file size of 0.3MB for the app, which is (or should be) impossible for a full node-webkit package. For that file size, I would imagine they are using a native wrapper for WebKit included in the OS (no node) and just loading the app into a web view like PhoneGap does on mobile.

[cont...@nazcasistemas.com]

I have installed reditr and checked the about reditr option. They credit macgap:
https://github.com/maccman/macgap
A wrapper similar to phonegap for mac.

It would be nice to have node-webkit api compatible with phonegap, isn't it?

[Matt Hackett]

Thanks for the responses! I have an update…

So it turns out Application Loader wanted a .pkg (installer) file. This can be created from the node-webkit .app file via the productionbuild Xcode command-line tool. In order for the App Store to accept the application, they require any executables inside the bundle to also be signed using the codesign command-line tool.

After many failed attempts to upload I finally got all the signatures in place and it's all certified and whatnot. Now I'm just waiting for Apple to reject the application ;)

Cheers,

-Matt

[Patrick Klug]

I thought Apple only allows native ObjectiveC apps into the App Store? Will be interesting what their response is.

-Matt

--
You received this message because you are subscribed to the Google Groups "node-webkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-webkit...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael Latta]

They backed down on that one.  But, they do not allow an interpreter that takes code from any outside source other than their js interpreter in webkit, so the nw app would need to use the native webkit not one it bundled itself.

Michael

[Patrick Klug]

interesting.

[Chris Turnbull]

Just wondering - is there any chance their native webkit allows things like three.js and WebGL?

(If not: I didn't think so :( )

--
You received this message because you are subscribed to a topic in the Google Groups "node-webkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-webkit/qP_x9Z0lEO4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to node-webkit...@googlegroups.com.

[prophecy...@gmail.com]

Update?

[Matt Hackett]

Just got an update a few minutes ago (Apple's review process is very slow). It appears Apple does not allow the use of non-public APIs, which node-webkit is apparently using in a few places (full message below).

This looks like a showstopper for getting a node-webkit app into the Mac App Store. Can any node-webkit developers chime in on whether there might be a fix or not? Thanks!

For those interested, here's the complete message I received:

---

Apps that use non-public APIs will be rejected

2.5

The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The following non-public APIs are included in your application:

private spi symbol(s) in framework: '/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit'
: NSAccessibilityCreateAXUIElementRef
: NSAccessibilityHandleFocusChanged
: NSAccessibilityUnregisterUniqueIdForUIElement
: NSTextInputReplacementRangeAttributeName
: _NSAppendToKillRing
: _NSDrawCarbonThemeBezel
: _NSDrawCarbonThemeListBox
: _NSInitializeKillRing
: _NSNewKillRingSequence
: _NSPrependToKillRing
: _NSSetKillRingToYankedState
: _NSYankFromKillRing

private spi symbol(s) in framework: '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices'
: AXTextMarkerCreate
: AXTextMarkerGetBytePtr
: AXTextMarkerGetLength
: AXTextMarkerGetTypeID
: AXTextMarkerRangeCopyEndMarker
: AXTextMarkerRangeCopyStartMarker
: AXTextMarkerRangeCreate
: AXTextMarkerRangeGetTypeID
: CGContextResetClip
: CGPatternCreateWithImage2
: CTLineCreateWithUniCharProvider
: CoreDragGetCurrentDrag
: CoreDragSetImage

private spi symbol(s) in framework: '/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation'
: CFLog
: CFReadStreamSignalEvent

private spi symbol(s) in framework: '/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices'
: CFHTTPCookieStorageCopyCookiesForURL
: CFHTTPCookieStorageDeleteCookie
: CFHTTPCookieStorageGetCookieAcceptPolicy
: CFHTTPCookieStorageSetCookieAcceptPolicy
: CFHTTPCookieStorageSetCookies
: CFURLCacheSetDiskCapacity
: CFURLCacheSetMemoryCapacity
: CFURLRequestCreateMutableCopy
: CFURLResponseCopySuggestedFilename
: CFURLResponseGetHTTPResponse
: CFURLResponseGetMIMEType
: CFURLResponseGetURL
: CFURLResponseSetMIMEType
: kCFStreamPropertyCONNECTAdditionalHeaders
: kCFStreamPropertyCONNECTProxy
: kCFStreamPropertyCONNECTProxyHost
: kCFStreamPropertyCONNECTProxyPort
: kCFStreamPropertyCONNECTResponse

If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions.

Additionally, one or more of the above-mentioned APIs may reside in a library included with your application. If you do not have access to the library's source, you may be able to search the compiled binary using "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides.

If you are unable to reproduce this issue, ensure you are testing the exact version of the app that you submitted for review, and that you're doing so in a minimally privileged environment. See Technical Q&A QA1778: How to reproduce bugs reported against Mac App Store submissions.

For discrete code-level questions, you may wish to consult with Apple Developer Technical Support. Please be sure to:

- include the complete details of your rejection issues
- prepare any symbolicated crash logs, screenshots, or steps to reproduce the issues for when the DTS engineer follows up. 

For information on how to symbolicate and read a crash log, please see Technical Note TN2123 - CrashReporter.

[mac...@gmail.com]

Developer of Reditr here-- we use node-webkit for Linux and Windows, however for OS X in order to get accepted into the Mac App Store we went with MacGap:

https://github.com/maccman/macgap

Good luck!

David Zorychta

[Tom Moor]

Matt, if you fancied doing some sort of tutorial or example on getting the signatures in place for node-webkit that would be *amazing*. This information isn't in the wiki or anywhere else I can find at the minute...

[Matt Hackett]

David, thanks for posting about Reditr, MacGap looks interesting. I've actually wrapped up an HTML5 game with a WebView in Xcode and managed to get that on the Mac App Store; I wonder if MacGap is even easier than that?

Tom, I thought the purpose of signing an application was to work with the Mac App Store. If node-webkit apps can't be uploaded there anyway, what's the value of signing? I'm happy to share information either way, just wondering what your use-case is :)

Cheers,

-Matt

--

[Tom Moor]

Hey Matt,

On the latest versions of MacOS there is gatekeeper, so without changing security settings you can't even install an unsigned application. There are basically three settings:

- Only allow installations from App Store

- Only allow signed installations

- Allow any installations

The default is the middle setting, so signing apps is still definitely very important for distribution =)

[Matt Hackett]

Tom, gotcha! Thanks for the info. I will write a quick tutorial as soon as I can :)

[Tom Moor]

That would be really great, I've got an issue on the tracker here for such a guide: 

https://github.com/rogerwang/node-webkit/issues/616

Perhaps it could go in the official Wiki?

[Trevor Linton]

Thought I would bump this thread to say 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 and submitting it to apple to see if they find issues.

[Jorgen Skogmo]

Looking forward to hear about their response - thanks for checking this out!

[Benjamin Dobler]

That would be a huge milestone for node-webkit!

--

You received this message because you are subscribed to the Google Groups "node-webkit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to node-webkit...@googlegroups.com.

[al...@mrgray.com]

Any news on this?

[tim....@gmail.com]

Hi

Did you every create tutorial on how to do this ?

I've managed to get to the point of

codesign -s <key> -fv --deep apllication.app

It even verifies but no luck in people being able to run it.

I've tried with both and app store cert and a developer cert.

[gary...@gmail.com]

@Trevor:

Was your app approved? Can a node-webkit app now get into the App Store?

[Matt Hackett]

Hi, no sorry I haven't yet, I've been crunching on A Wizard's Lizard. We're launching next month, at which point I'll be able to revisit the tutorial. I will email here again when I finally get to it :)

[bushi...@gmail.com]

bump

Any luck @Trevor?

[esha...@gmail.com]

Trevor posted here - https://github.com/rogerwang/node-webkit/issues/936 - 5 months ago the result of his submission. Chromium 29 went through, wasn't rejected from the Mac App Store. 

Here's his update in that thread: "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." 

Hope that helps you guys. I've spent the past couple days looking everywhere to see if I could compile webkit 2 (i.e., from nightly.webkit.org) and embed it in a mac app store app without being rejected by Apple. It seems it includes three libraries from Apple, for webkit, which are the source of most (or all?) of what apple winds up rejecting: 

libWebKitSystemInterfaceLion.a

libWebKitSystemInterfaceMountainLion.a

libWebKitSystemInterfaceMavericks.a

That seems like kind of a nail in the coffin for anyone trying to embed webkit in a Mac OS X app and have it get through the mac app store. Some have had problems with Webkit 1, others with Qt Webkit (like this guy - http://qt-project.org/forums/viewthread/35721), you guys with Node-Webkit -- I think it might all boil down to those webkit APIs that are *from* Apple, *included* in the core webkit that's used in any of these branches, and Apple's rejecting it. I think because it has private API calls inside those files that it picks up in its scanner, even if they're not being used, which is ironic. 

Not hopeful. 

Hopes that helps you guys. Please someone chime in if you think I've got this wrong. 

[Trevor Linton]

Just an update, i've had several people who have worked with us and submitted Mac App Store apps with node-webkit. We're currently working with a company who is in the process of working through the review process.  There are a few "new" things since the Chromium 32 rebase:

1. You'll need to watch out for entitlements, this was introduced with Lion and made more "effective" in Mavericks.  Entitlements must include: 

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>com.apple.security.app-sandbox</key>

<true/>

<key>com.apple.security.application-groups</key>

<true/>

<key>com.apple.security.network.client</key>

<true/>

<key>com.apple.security.network.server</key>

<true/>

<key>com.apple.security.inherit</key>

<true/>

</dict>

</plist>

2. The basic node-webkit still uses 32-bit QTKit/QuickTime API's in Chromium 32, these need to be commented out (mostly in WebRTC Video capture and libjingle, fairly easy to remove from the build).

3. Finally, make sure to rename the "SocketSingleton" to "S" in process_singleton_mac (and chrome_constants).  Sockets have a limit of 104 characters in the file path, these fail when entitlements force them into a sandbox with a very long file path name.

[Trevor Linton]

If anyone would like Chromium to make this a "bit easier" feel free to file a bug about removing 32-bit QuickTime/QTKit API's from chromium.  In addition you can find the socket length issue here:

https://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=&id=33097

This isn't chromiums fault to be clear, this is plain ole' apple being quite zealous.  To make matters worse, 10.9.3 will begin to reject non-64bit apps.

[Trevor Linton]

I help run Tint, a commercial version of node-webkit that also does consulting work on node-webkit. I've been helping Ralf Schwoebel, a German developer who works on www.secryptor.com submit their app to the Mac App Store, they were kind enough to give me permission to share out the findings with the rest of the community.

First there are several changes to chromium that are necessary to support the Mac App Store, QTKit/QuickTime API's must be removed, this disables text-to-speech functionality in addition to WebRTC Video capture.  The other changes include working around Chrome's IPC implementation to make it compatible with the Container systems that the Mac App Store requires. Finally, entitlements are very tricky to configure with chrome's multiprocess architecture.  However we were able to resolve the issues. 

You can find a complete guide to submitting your app to the Mac App Store at: 

www.trueinteractions.com/node-webkit-093-mac-appstore.zip

The file contains a 0.93-pre (It is actually probably closer to 0.92 than 3), it also contains two signing scripts macstore_sign.sh signs it with entitlements, sign.sh does a default signing without taking into account the Mac App Store requirements.  There's also a RTF file in there that's a complete guide to submitting your node-webkit or Tint application to the Mac App Store. It covers everything from product builds, submission requirements and iTunes Connect and is specific to node-webkit. 

I will also be posting a diff of node-webkit's chromium sources later today if someone wants to make an official push up to node-webkit's repo. If you need help submitting your application to the mac app store we're happy to help out, just contact a representative at sup...@trueinteractions.com (shameless plug).  Our licensing is fairly reasonable. 

[Trevor Linton]

Following up on my previous post you can find the diff below to get Chromium (and Tint, and Node-Webkit) to pass the binary inspection and submission process for the Mac App Store. 

https://github.com/trevorlinton/chromium/blob/node/MacAppStoreSupport.diff

[trad...@gmail.com]

To round it up: the App is now "Waiting for review", which means it passed the binary first hurdles, you would probably run into. We will get more details out on an extra domain, where I will also show the Windows 8 catalog submission with node/webkit... that was a little bit easier :-)

[trad...@gmail.com]

I have gathered my experience on this forum:

http://www.enablejs.org/forum/categories/tools-and-frameworks

together with Windows and OS X - step by step postings. It was such a complicated process that I hope this helps the fellow node-webkit warriors!

[rip...@gmail.com]

@Trevor did you run into any issues when sandboxing the app?

After signing and adding entitlements to my nw app, I had it crash on startup every time, whereas it wouldn't crash if I didn't sandbox it or if I didn't add my own bundle identifier.

It seems that after sandboxing the resource path is

/Users/username/Library/Containers/com.domain.name/Data/Library/Application Support/Your App Name/...

rather than

/Users/username/Library/Application Support/Your App Name/... 

which caused node-webkit to crash with this error:

So it looks like the path gets too long? Is there a way to work around this?

[trad...@gmail.com]

So, with the great help of Trevor, we are finally live on the App Store: http://secryptor.com/

The OS X app was officially accepted last week and we (or better Trevor) had to patch node-webkit to binary safe for Apple.

The entitlements also have been a pain, especially selecting a file for writing... that is all solved and done.

We are already deep into the professional version, now that we know that node-webkit can be the binary playground! All looks very promising!

[Shaine Gordon]

I have the exact same issue.

if I sign with sandbox enabled, the app crashes.

did you ever get this sorted?

[trad...@gmail.com]

We had the exact same issue and it helped to track every action with the console. You might be using a different binary distribution. We had to go with the 32bit release that Trevor provided.

[leons...@gmail.com]

You need to create pkg-installer. Here you could find detailed instruction.

воскресенье, 31 марта 2013 г., 4:26:43 UTC+3 пользователь Matt Hackett написал: