eSellerate has Dropped Xojo Support

Just talked with eSellerate (Digital River / and they confirm they are no longer supporting Xojo.

I recommend as a replacement.

For those still using the eSellerate ewsPlugin under Cocoa, you’ll find that you can’t sign your apps. The solution is to sign the ewsPlugin.rbx_0.dylib inside the app’s Frameworks folder first and then sign the app as a whole.

Well that really sucks. While I was never exceptionally happy with eSellerate I really only had few issues with them.

The only problem I had with FastSpring (the last time I investigated them at least) was that they didn’t have a solution that would keep someone from giving out a license code/file and moving the app to another machine. eSellerate had activation counts and that was useful.

Yeah, I understand. They said they are favoring their eWS SDK for Xcode. Not sure if that’s transportable.

Maybe you should contact Fastspring again and ask.

I’ve been looking at rolling our own licensing validation server for that as I don’t like being locked into one commerce platform’s solution.

I’d suppose someone could use the SDK to create a new plugin
Heck the SDK might be something you can just call into using declares

FWIW, if you’re using AppWrapper you can set it to use the Mavericks code sign engine which will force sign components. I just released a Cocoa app using the eSellerate plugin with no issues.

Good to know. Thanks Bob.

Can’t say I’m surprised really, since the DR takeover they really don’t care about the small guys. Mind you, when you power Adobe’s Creative Cloud, you don’t need to give a hoot about your existing customers anyway!

Quite frankly, they caused me hell of grief last year and while I’ve been unable to find a replacement, I’m glad to see them abandon their customers. I hope that once Adobe wise up and drop them, they’ll be gone from the world.

Which is how code signing should be done to begin with. All executable code within the bundle, should be code signed, before code signing the bundle.

The App Wrapper Code Sign engine should take care of the eSellerate plug-in as well. Although there are some other files in the bundle that the Mavericks code sign engine signs. I’ve been trying to get Apple to tell me exactly what files the Mavericks engine code signs so that I can improve the App Wrapper engine, as the Mavericks one is only temporary.

Which I think is where I’m headed too. I’m not going to focus on the actual selling of the products, I’ll let someone else do that for me. However I will manage all my serial numbers thank you very much. Which is my biggest issue with eSellerate at the moment, I let them manage my serial numbers and it’s caused me a world of pain.

Why is it necessary to sign the internals? I’ve always just signed the package which seems to satisfy Mavericks though perhaps not the App Store. Is it that the other plugins (Xojo standard, MBS) are already signed?

@Stephen: because Apple says so. The plugins are not signed and you need to do this yourself. And if the plugins aren’t signed your users will get the message that the app won’t open.

Pretty much. In the beginning it was okay to simply sign the package, then a couple of years ago Apple required all executable code to be signed for the Mac App Store, and now that requirement must be met when code signing on Mavericks for Mavericks.

Apple also used to allow plugins and such to be signed by their various vendors, now however it must all be signed by you, the application vendor. I think this is more for accountability than anything, as by signing it, you’re accepting responsibility for it. If it turns out that a plugin or executable within your application is malicious, it’s your responsibility… Although that’s just my humble opinion.

App Wrapper 2.x has signed like this for a long time. Digging through the application package to find executable code and then code signing all the executable code (that it’s aware of).

So, if I sign the whole package on Mavericks and run on a different Mavericks machine, it will give the unknown vendor warning? And this is true even if the package passes signing verification with codesign -dvvv?

I seem to recall that’s what was happening to me during the Mavericks beta’s with App Wrapper Mini.

I’ll check it out.