App Wrapper Steps for NON-MAS packaging?

This is directed at @Sam Rowlands, but I thought everyone could learn from the answer.

Do you have an App Wrapper 3 guide for those of us wishing to create a PKG/DMG that is NOT destined for the MAS? There are so many options that are aimed at MAS, and I don’t know which I need to worry about for non-MAS wrapping.

Thanks,
Tim

In the General tab, in the code signature box, click on the box and turn OFF “Show All certificates” Now you should have, if your certs are correct, a GateKeeper and App Store. Select the GateKeeper. Under the capabilities tab, turn OFF Sandboxing. Now everything else on this tab is not apropos. The info and Other tabs you should fill out as appropriate for your app. In the signing process, App Wrapper will let you know if the signed app passes GateKeeper

Ah - my non-MAS cert is not showing up. This is why I keep seeing the MAS submission options. Looks as if my call with Apple sorted the MAS certs, but did nothing to return my non-MAS certs…

More digging :S

I just spent 2 months working out problems with my Apple certs. With Sam’s help I finally got them fixed about a week ago. I will be glad to pay forward the favor if I can be of assistance.

Just a note, you don’t have to disable sandboxing for non-mas apps.
If you’re distributing in both locations (mas and outside) you can leave all your settings the same, just sign with the correct certificate for your distribution method.

FWIW, all I ever change between MAS and non MAS is the certificate. App Wrapper takes care of the rest.

Same here: I only switch certificates and AppWrapper does its job.
But I’m still using El Capitan. Scared to move to Sierra by what I read on the forum (about certificates).

Good news is no news, so I did not participate in the chorus. For me, Sierra did not break anything, and App Wrapper faithfully works as ever under Sierra 10.12.4.

It turns out that my non-MAS cert didn’t get restored. I’m working on sorting that out this weekend.

Another question - does anyone know how to get codesign to tell you WHICH files contain the unallowed “resource fork, Finder information, or similar detritus”?

App Wrapper removes these for you. Maybe it is in the wrapping logs.

Thanks, Michel,

It appears to be related to the fact that some of my helpers use a hook into the QuickTime stuff. I’m looking into that since I don’t use any audio or movie players in the particular app.

If the helpers have been built with Xojo prior to 2014R1, they do contain Quicktime stuff.

Yep - all of the command line bits are done with 2007r1 so that they can share a Libs folder rather than needing to have 11 copies of the same libraries. Glad I’m not interested in selling these on the MAS.

[quote=316443:@Tim Jones]Ah - my non-MAS cert is not showing up. This is why I keep seeing the MAS submission options. Looks as if my call with Apple sorted the MAS certs, but did nothing to return my non-MAS certs…
More digging :S[/quote]
A newer version of App Wrapper will use a different identity selector that will make it more obvious when the certs are missing.

Currently there isn’t.

Code sign simply fails stating that some files have this crap (which in some cases Finder magics ads for you).

App Wrapper doesn’t bother checking in it’s main function, it simply blasts everything that it’s aware of. In a secondary function, it does check each and every single file (which is why it’s a little slow at the moment), but this is carried out after the main function, as in some situations (DropBox) there is still meta data after App Wrapper has removed it. A future version will refuse to wrap to a DropBox folder.

Older versions of Xojo link to Quicktime or QTKit in the Xojo.framework, these are strictly prohibited on the Mac App Store now. Yet apps that use Quicktime continue to work fine.

After my experience, I’ve been seeing articles from various sites reflecting pretty much the same thing. Apple’s lack of interest in the App Store and crippling requirements have not only pushed developers away from the App Store, but even consumers (especially pro-sumers) have given up and now using Google to find apps that they need.

Amazingly enough, I have a significant number of users who visit the web site, but purchase on the MAS. I also have a couple apps that do not sell at all direct (like zero sales in six month), and have a nice little life in the MAS.

I always appreciate your input Michel, in this case it helps provide some perspective.

I’ve done some digging and can find that apps such as our Card making app and Iconographer do better on the App Store, while our latest Photography application is doing better on our own site. The photography application is the most expensive of these 3.

I accredit the photo apps success on our site to several factors:

  1. Trial version, so people can try before buying.
  2. Upgrade pricing, so previous customers of the application can get the newer version at a discounted price.

I think it would be a fair test if both of these options were available on the Mac App Store.

Is there a simple test for such a folder?

[quote]1. Trial version, so people can try before buying.
2. Upgrade pricing, so previous customers of the application can get the newer version at a discounted price.

I think it would be a fair test if both of these options were available on the Mac App Store.[/quote]

+1

All my apps have trial versions, and I try to give them the largest exposure through hundreds of shareware repos.

It is very difficult to know the exact impact of the evaluation version, but I am fairly sure it plays a big role in improving the product recognition.

Hoping to find one this week :slight_smile:

Currently the only way I know about this is via the rather slow checking of each file after it’s already torched the meta data.

Almost all of the people who continued to have the failure due to meta data, were wrapping to a DropBox folder, once they wrapped elsewhere, the problem went away.

I would start by checking if there is no “Dropbox” folder along the path. That probably accounts for a vast majority of the cases.

About evaluation, all mine have in app purchase links that are different to the direct sale. Amazingly enough, sales within the app are anecdotal.