App Wrapper wrapped app throws an exception when run.

Hi,

I am messing around with App Wrapper. After the app is wrapped and I try to run it. It throws a Nil Object Exception on startup. The non wrapped app works fine. I was wondering if anyone knows may have caused this?

Do your wrapping settings include sandboxing? This kind of behavior sounds like you’re trying to access a FolderItem next to the app when it’s not allowed to (translocation or some other security means).

My app is trying to access a database file that is stored in the Documents folder and not in the Applications folder.

You can’t assume that will work. System security has gotten tighter, and as you’re experiencing it can cause issues on some systems and not others.

If it’s a document the user needs to handle (like a word doc or psd) ask for it with an OpenDialog. If it’s something they don’t need access to, it should be stored in your subfolder of Application Support.

Thanks Tim

The user needs to be able to easily access the database files in which the app uses, so I did not want to bury it in the Application Support folder which is difficult to locate by our users. The Documents file is easy to get to.

This app is not going to be sold in the App store. I just want it code signed. That’s it. It works find before using App Wrapper, so I still don’t understand what is going on.

You should always do a nil and an exists check when opening a file. What would happen if the user deleted the file?

Hi Beatrix,

If the user deletes a file, they just have to reinstall the app again.

I am just trying to get around the Gate Keeper warning.

You can’t really without respecting the system rules. I know your project is complex, so I can’t really recommend the best route for you without knowing the project better. You’re welcome to reach out to me by email with the project, but I can tell you now my recommendation will include reimplementing access to the database file.

The project just reads and writes to two databases stored in a folder in the Documents Folder. That makes it easy for the customer to access the database file. Trying to explain to a customer how to access files stored in the Application Support folder would be too complicated.

I used to store the databases in the Applications folder, but Apple stopped letting you do that after I think Lion or one of those versions of the OS.

As I said the app works great reading and writing to the Documents folder before app wrapper, so I not sure why it would screw up just by code signing it. Is app wrapper trying to sandbox files?

So the only place you can read and write is the Application Support folder if you code sign an app?

It doesn’t just affect code signed apps, security affects any app. I’m thinking that your App Wrapper settings include either sandboxing or some voluntary security measure which is why you’re seeing it after code signing.

Off the top of my head, the locations you can reliably access are:
SpecialFolder.Temporary
TPSF.AppSupport
(I feel like there’s a third I’m forgetting)

Anything else you have to ask for access to.

If you’re storing the database in Documents simply because the users have trouble finding the database file in Application Support, then you could add a “Reveal Database” or “Export Database” function to help them with it. An import function would do the reverse.

I just don’t know how to turn it off.

I do have functions that allow users to export the data.

I don’t really want to change the location of the databases, so it just may be easier not to sign the apps at all than to rewrite all my code.

I just figured it out. Under capabilities you set the “App Sandbox” to never. Then the app will sign and work correctly.

Thanks for all your help Tim. I really appreciate it.

You are very welcome!

HI James,
Check which code signature you’re using. Make sure the selector says “Web” and not “App Store”. When it’s set to App Store, App Wrapper auto enabled App Sandboxing as it’s a requirement for the App Store. However when selecting “Web” it doesn’t as App Sandboxing is optional (for the time being).

Thanks Sam. I checked that when the App Store side was not working. I have it set for Web and I manually turn off the sandboxing and now it works fine.