PDA

View Full Version : Xcode application (needs help)




siakus
Jun 13, 2006, 01:51 PM
I have built an Xcode application project and i don't want the users to see the package content of my .app file by choosing "show package content" from the contextual menu. Is there any way to hide this menu? or Do you have another solution?
thanks.



caveman_uk
Jun 13, 2006, 02:46 PM
AFAIK there's no way to stop people using 'show package contents'.

What are you trying to hide? ;)

robbieduncan
Jun 13, 2006, 03:02 PM
Create a legacy CFM app with all resources and so on compiled into a single giant file?

Other than that there is no way.

siakus
Jun 13, 2006, 03:30 PM
i am new with the xcode thing.
What is a CFM App? How could i create a CFM app with all ressources? Do you know any related web site?
thanks.

mduser63
Jun 13, 2006, 03:58 PM
Just out of curiosity, why don't you want people to be able to view the contents of your .app folder?

Krevnik
Jun 13, 2006, 04:05 PM
CFM is the old format used since System 7.1 (whenever PPC support was first introduced), and then abandoned in OS X. OS X will still read CFM PPC apps, but you can't produce a Universal Binary using CFM, and Apple's tools can't be used to create a CFM app on OS X.

Oh, and there is the whole issue that you then have to use the old resources stored in the resource fork, meaning you have to call into the Carbon APIs, you can't use Interface Builder, and localization is by and far, MUCH more time-consuming.

Yeah... uhm... I wouldn't use CFM. You essentially will bind the life-span of the app to that of PPC Macs, and forcing Intel systems to run in emulation just to use the app.

Other than that... there is no way to hide the contents of your bundle from the world. The real question is: What the in the world are you attempting to hide from the end user that you would need to do this?

HiRez
Jun 13, 2006, 04:38 PM
Maybe encrypt your resource data, maybe in a zip file format or something, using Java or Python libraries to get it out (or use your own proprietary data file format). Sounds like a major PITA to me though. Another possibility is to perhaps use CoreData and have it store the resources as binary data in a database (not sure if that's actually secure though, or could be made to be). It might help if you at least told us the kind of data you're trying to hide (text, image, password key, etc.).

Krevnik
Jun 15, 2006, 12:44 PM
Agreed, depending on the data being hidden, there is a good chance there is a better way to do it, or a better location for it. Just because you might be able to lock out the UI option, doesn't mean it is a good way to lock data away without encryption (which is a PITA if you want to do that to your nibs or the like).

GeeYouEye
Jun 15, 2006, 01:39 PM
^ Not necessarily... you could put the NIB decryption in main.m before letting NSApplication run. Still, I imagine most users might not be too happy about that if it means a longer startup time.

gnasher729
Jun 25, 2006, 04:53 PM
I have built an Xcode application project and i don't want the users to see the package content of my .app file by choosing "show package content" from the contextual menu. Is there any way to hide this menu? or Do you have another solution?
thanks.

Why would you want to do that?

Since Apple and everyone else ships applications where the user can choose to see the package contents, could you please explain what makes your application so outstandingly different that the user shouldn't be able to do that with your application?

siakus
Jun 25, 2006, 07:17 PM
In fact i just don't want users to check and modify my nib files. And i have an applescript there also that i want to hide. For the script i put it in a objective C code, so that's fine. but i have no solution for the nib files.
And i have seen some applications on the mac where you can't use the "show package" function. Foe example Microsoft Office Applications.

savar
Jun 25, 2006, 09:15 PM
In fact i just don't want users to check and modify my nib files. And i have an applescript there also that i want to hide. For the script i put it in a objective C code, so that's fine. but i have no solution for the nib files.
And i have seen some applications on the mac where you can't use the "show package" function. Foe example Microsoft Office Applications.

Well, I doubt that your nib files are highly-classified trade secrets, so I don't see what's wrong with users modifying them, but there's no reason why you couldn't simply zip up the files, unzip them at runtime, then delete the unzipped files when you're done. It's obnoxious, but if you really want to its possible.

The only apps that can't have their package contents shown are apps that are not packages. These apps are outdated and you shouldn't be developing an app like that.

caveman_uk
Jun 26, 2006, 03:12 AM
In fact i just don't want users to check and modify my nib files.

Why would they want to do that? Does it really matter? Why don't you spend more time worrying about stuff the user really cares about (like features, ease of use etc) than daft obfuscation that just makes your program more complicated than it needs to be for very little real gain.

And i have an applescript there also that i want to hide. For the script i put it in a objective C code, so that's fine.
If I wanted to find your applescript I could find it as a literal string in your binary with a hex editor (or the 'strings' command line program ). What you going to do now? Encrypt it in the binary?:rolleyes:

Trust me, there's very little you can hide in an objective-C program. The class headers can be worked out using class-dump and someone could find all those secret files you access using fseventer. Throw in input managers, class posing and the other delights of the objective-C runtime and you're pretty much wasting your time trying to hide stuff without spending a lot of time doing it properly.

siakus
Jun 26, 2006, 08:37 AM
Ok thanks guys. I think i will drop that case, i understand it doesn't really matter.

Soulstorm
Jun 26, 2006, 08:49 AM
As far as the Applescript file is concerned, you can hide it this way:

Compile it as a run-only application. You will still be able to load it with the "load script" command.