macOS Signed Application - please test

[dkulp]

The latest macOS Sierra betas have remove the nice little checkbox in Gatekeeper to allow Apps "Downloaded from Anywhere".   There is a command line utility you can run to turn it on if you google enough, but kind of a pain.    Thus, by default, it won't run xLights.   

I've gone ahead and used some of the money you guys have donated to xLights (major thanks everyone) to register a developer account with Apple and created a Mac app id and such.   I just did a new build of 2016.45 and created a DMG for it and signed it an all that.   My very limited testing with it shows it works OK with El Capitan with Gatekeeper enabled  and set to "App Store and Identified Developers" so I *THINK* it should work.   If folks could give it a test, that would be great.

I have to use a dmg instead of a tar.gz as the archive needs to be signed as well.   Thus, we'll likely be switching to that.  It's a little larger, but not by much.

[ScottyJ]

worked like a champ!

Thanks Dan

Scott

[drlucas]

When I first run the app I am prompted to open, after that it loads up every time. I am running on a MacBook Pro 2011 with beta 5 of Sierra. So far so good.

[kevinp]

Opens fine on my Mac, no different than previous builds, but I do have my security set to allow apps downloaded from anywhere to run.  I get the standard dialog box asking if I want to open it still upon initial startup for the first time after download. 

A lot of times I'll compile the latest code on my own and then I don't get those warnings.

Once I upgrade to the new MacOS when its released I'll test it out again.

[dkulp]

Kevin,

When you get a chance, can you try building the latest code?  I've been adding a lot of stuff for signing the app and enabling the sandbox and such and I'm hoping I didn't break things for the folks that don't have apple developer ID's.

[kevinp]

Kevin,

When you get a chance, can you try building the latest code?  I've been adding a lot of stuff for signing the app and enabling the sandbox and such and I'm hoping I didn't break things for the folks that don't have apple developer ID's.

Dan,

I pulled the latest code as of 10 PM Central time and could compile and build xLights.  I do get a warning though with the following message...

CODE_SIGN_ENTITLEMENTS specified without specifying CODE_SIGN_IDENTITY. It is not possible to add entitlements to a binary without signing it.

Seems to run normally.  Is there anything from xCode (errors) that you want me to send you?

Should I be on the lookout for xLights in the App Store?   

[dkulp]

CODE_SIGN_ENTITLEMENTS specified without specifying CODE_SIGN_IDENTITY. It is not possible to add entitlements to a binary without signing it.

Yea.. that's going to be there now.   It goes away if you turn on signing, but that requires a developer account.

Should I be on the lookout for xLights in the App Store?   

I submitted 2016.45 to Apple today.   It passes all the automatic verifications (after hacking wxWidgets a bit) and is now in the "Waiting for review" phase.   I'm going to doubt it will pass as we don't really follow any of the UI guidelines for Mac apps, but it's worth a shot. 

There will be a few "restrictions" in the App Store version due to the Sandbox.   All the files (images, movies, media, etc....) will HAVE to be in either the Media or Show directories.  No random place on the disk type thing at this point.   

[kevinp]

I submitted 2016.45 to Apple today.   It passes all the automatic verifications (after hacking wxWidgets a bit) and is now in the "Waiting for review" phase.   I'm going to doubt it will pass as we don't really follow any of the UI guidelines for Mac apps, but it's worth a shot. 
 

As quickly as yourself, Gil and Keith make changes and Sean releases them, Apple probably won't be able to keep up.

[uzelessknowledge]

I'm also receiving the same message as drlucas. No issues though.
The build won't be in a folder any more? I kinda like that cause I can easily keep multiple version and know which is which.

[kevinp]

I'm also receiving the same message as drlucas. No issues though.
The build won't be in a folder any more? I kinda like that cause I can easily keep multiple version and know which is which.

You could always create your own folder and name it how you want.

[uzelessknowledge]

You could always create your own folder and name it how you want.

Did just that.

[dkulp]

I'm also receiving the same message as drlucas. No issues though.
The build won't be in a folder any more? I kinda like that cause I can easily keep multiple version and know which is which.

At this point, I do plan on keeping the tar.gz around.   My little build script will build and upload both.   Sierra users will likely need the DMG.

I may actually create a "third" package for a while to test out.   I have a lot of the sandboxing stuff working so I may have a special "Sandbox" build for folks to try .    This is a semi-side project.   I did get the rejection from the AppStore Review for a BUNCH of reasons that will take a while to work through so I'm really not in much of a hurry.

[uzelessknowledge]

I'm also receiving the same message as drlucas. No issues though.
The build won't be in a folder any more? I kinda like that cause I can easily keep multiple version and know which is which.

At this point, I do plan on keeping the tar.gz around.   My little build script will build and upload both.   Sierra users will likely need the DMG.

I may actually create a "third" package for a while to test out.   I have a lot of the sandboxing stuff working so I may have a special "Sandbox" build for folks to try .    This is a semi-side project.   I did get the rejection from the AppStore Review for a BUNCH of reasons that will take a while to work through so I'm really not in much of a hurry.

Thanks Dan for your work.

So, is this moving to an App Store app? If so that seems like great news, but extra work.

[dkulp]

So, is this moving to an App Store app? If so that seems like great news, but extra work.

I really won't say yes or no to this.   Sierra will pretty much require a signed app so I went ahead and did that.   That was the hard part.  Since I did that, I decided to go ahead and try submitting it (submitting an app isn't that hard) just to see what they would say.   There are two parts to getting an app approved:

1) Automated tests - on upload, they have a bunch of automatic things that are run and if it catches something, it refuses the upload.   Things like sandboxing, use of deprecated API's and libraries, etc...   We had a couple of these that I was able to get past.

2) Review - the app is actually reviewed by someone who runs another series of tests on it as well as actually runs the app.   We're failing badly here.     The main things it flagged so far:

a) Use of "Beta" in the title/version.   That's not allowed.   That's an easy fix.

b) Use of an internal API - somewhere down in ffmpeg is a call to a private API.   This is going to require digging through ffmpeg to figure out how to remove it.

c) Too many entitlements (the "Pokemon Go" problem of grabbing all rights).  I pretty much turned on a bunch of things we don't really need.  Easy fix, however they claim we don't need to access USB devices (which we do for DMX controllers) so I'm not really sure how to appeal that.

d) More accurate description for the app store - this should be easy.   Someone needs to write a good paragraph describing what xLights does.  Apparently "xLights is program for sequencing Christmas lights to music." is not enough.

e) Better description or tutorial or something so the reviewer can figure out how to actually use it.   The reviewer could not figure out how to do anything so rejected it.   May just need to collect links to the manual/tutorial videos, etc....

Anyway, it's kind of a side project.   The way we distribute now is fine, but since I'm paying $99/year for a developer account, I thought I'd at least try.

[neil]

Dan, Can you install the dmg file so that it ends up in applications?