Why no SpecialFolder.TheApplication?

Getting Started
21

As of now it does. I thought I read something about it not working with something signed but not notarized, but I’m not sure of that. For now, Apple is still allowing unsigned apps with user approval. Of course, one should not do this without trusting the source–I am presuming that Mr. Livingston’s stated target audience “does” trust him. :slight_smile:

1 Like
22

You’re right but also wrong here. The app-specific password is just for connecting to your Apple ID. The notarization process does not attach that password to your app or look it up or anything like that. It generates a hash - of what I’m not certain - and stores that on Apple’s servers. The OS asks the server if the hash is ok. The notarization process also “staples” a signed answer to your app.

Other than the mixup with the app-specific password, you’re right.

23

Yes, I have AppWrapper on both my desktop and laptop. Each have a separate app-specific password, which as Thom says is a separate issue from the signing certificate.

Mr. Livingston, in a nutshell, a signed app means that 1) you, the developer, are who you say you are; and 2) the application bundle has not been modified downstream (which would break the signature.) Your intended users know you, so they’ll just have to jump through a little hoop on first-run :slight_smile:

2 Likes
24

Aw Shucks you guys…

And yes, I miss the good 'ole days when all we had to worry about was actually making a good app.

That would imply that I poses magic… But I thought it Tim who was the enchanter…

2 Likes
25

From this point we can hijack the thread with Monty Python references.

1 Like
26

For an app that is only for family and friends notarising is total overkill. When I make a test version of my app I’m too lazy to notarise it every time. “The test version needs to be opened with a right mouse-click” works fine when sending a link. The day this doesn’t work anymore I’m out.

It’s quite simple to make a dmg for distribution. Or copy your picture to the Documents folder when the app first start.

1 Like
27

Thanks BW. I will join you when we are forcibly cast into the wilderness.

28

I think a lot of us Mac people are very soon to be cast into the wilderness…

In the next few months, Mac apps are going to be competing with iPhone apps in the Mac App Store.

1 Like
29

Thanks for that. One PITA I found is that if you change your AppleID password (which I do regularly as I never remember it), then you need all-new app-specific passwords.

30

Just for sake of completeness, there’s an alternative to the right click.
Once one tries to open an app and sees the dialog telling the app cannot be opened (is not signed), you can then go into System Preferences→Security&Privacy→General and there will be a text saying “(app name) was prevented to run…” along with a button “Open anyway”.
I like this approach more, as Option-Open in the Finder also means “open app & hide the Finder” or “open app & close parent folder”; it’s not always practical to release the option key early enough.

1 Like
31

This thread has wandered around a bit, and I learned a lot. But back to the specific original question of how to get the FolderItem that would correspond to a hypothetical SpecialFolder.FolderOfApp.

I had proposed

Var h As FolderItem
h = app.ExecutableFile 

Var folderOfApp As FolderItem
folderOfApp = h.Parent.Parent.Parent.Parent

Var pathFolderOfApp As String
pathFolderOfApp = folderOfApp.NativePath

It seemed to work.

But I have just stumbled across this in the documentation:

If you pass the empty string to FolderItem.Constructor, it returns the FolderItem for the folder that contains the application.

Var f As New FolderItem(“”, FolderItem.PathModes.Native)

This is much cleaner, IMO and in my testing (which is on the Mac only) find it to have the desired result. It seems to be the equivalent of a hypothetical SpecialFolder.FolderOfApp.

2 Likes