Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS New Mac Development Team Member

B

Br0kenWheel

macrumors newbie
Original poster
Jul 26, 2012
4
0
Maine, USA
Hi,
I was recently added as a new member of an iOS Development Team (as a Mac developer) for the sole purpose of codesigning their new Mac app (I've never done anything like this before and have no experience with Mac developer teams).

Their Mac App it is a PC app ported to the Mac using wine and will be distributed from their website as well as on discs, not the Mac App Store. The Team Agent knows little to nothing about the Mac and is ignorant about getting the certificates for to sign the app and installer pkg. He's assigned me to research this and to get the job done. Googling has turned up very little so far.

There are a lot docs at Apple's Mac developer center and I've read a lot of it that pertains to codesigning, but Apple doesn't like to spell things out for the totally new beginner, like me. They also presume your are either the Team Agent or a one person team which I am neither. I don't know where to go from here.

Can someone please explain what I need to do to get the ball rolling? Thank you very, very much!
 
If they are running it under WINE , then it is NOT a Mac app, its still a Windows EXE, unless it exists as a standalone APP bundle you would not be able to code-sign it anyways.... And be aware, if YOU sign it, and it turns out to be malware then it is YOUR certificate that Apple will pull...
 
It's not just you. Apple developer documentation frequently delights in being a wonderfully unhelpful PITA.

Anyway, sounds like you want to build and distribute a .pkg file yourself, in which case `pkgbuild` and `productbuild` are your friends. Googling those terms should throw up a bunch of links - e.g. I pretty much figured out it from reading this:

http://stackoverflow.com/a/11487658/2298645
 
In my opinion you shouldn't run the application on the Mac using Wine. A really good reason to use the Mac instead of Windows is the Mac GUI. All Mac applications, including the Finder, use a consistent GUI. Mac users expect a Mac-like GUI with Mac interface elements. This makes the Mac much easier to use. Mac users won't like your Windows application running on their Mac. If you really want to sell your product to Mac users you should develop a Mac app using XCode. This will result in a way better Application. The GUI should be developed using XCode / Interface builder and if some parts of your code are in a language that is supported by XCode they can be used on both platforms. Distributing your application from the App Store is actually a good way to go because it does so much for you, but the App Store won't distribute your app unless it has a Mac GUI.

Cocoa has a very robust system for code signing. Writing the required authentication code is beyond the expertise of almost every programmer so most of us use a third-party application to do this like Receigen:

http://receigen.etiemble.com/faq.html

Available from the App Store
 
Last edited:
If you're using wine, you're not making a Mac app.

If you're not going to bother making a proper Mac app, don't try telling Mac users that you're going to. Just validate that it works under the common emulators (wine, Virtual Box, Fusion, and Parallels) and tell users that they can run your app using one of those means if they want.
 
Also I guess I should have mentioned that after you get the correct signing certificates, etc. XCode can automatically build and export your Application as a code-signed Application:

1. Archive your project.

2. Validate it with the Validate button in the Organizer window.

3. Export it as a code signed application with the Export button.
 
Cromulent said:
None of the things you have listed are emulators.
Click to expand...

Please explain how they're not... It's all software that's either emulating hardware so that Windows can run on it, or software that's interpreting a windows executable (which wouldn't be an emulation, I guess.)
 
ArtOfWarfare said:
Please explain how they're not... It's all software that's either emulating hardware so that Windows can run on it, or software that's interpreting a windows executable (which wouldn't be an emulation, I guess.)
Click to expand...

3 of them are vitualisation products which use native CPU instructions (on Intel processors that would be VT-x and on AMD that is AMD-V) to separate guest operating systems from the main host operating. All of them are running natively on the CPU and do not emulate any hardware. Therefore they are not emulators. All operating systems are running bare bones on the CPU though.

You would probably benefit from reading this: http://en.wikipedia.org/wiki/X86_virtualization

If you knew anything about WINE you would know it is a recursive acronym for Wine Is Not an Emulator. WINE works by providing a native implementation of Win32 functions on different operating systems to Windows. Again it doesn't emulate anything and therefore is not an emulator.

Likewise you should probably read this about WINE: http://en.wikipedia.org/wiki/Wine_(software)
 
ArtOfWarfare said:
Please explain how they're not... It's all software that's either emulating hardware so that Windows can run on it, or software that's interpreting a windows executable (which wouldn't be an emulation, I guess.)
Click to expand...

It's a technical distinction, but an important one.

"Emulation" usually refers to the execution of compiled code intended for one processor (such as PowerPC) by interpreting/recompiling software running on a different processor (such as x86). For example, SheepShaver is a piece of software that emulates the Classic Mac hardware based on Motorola 68000 series processors. Using SheepShaver you can run Mac OS 7.5 on Intel-based hardware because SheepShaver emulates the Motorola-based hardware.
Emulation does not provide performance that is comparable to the physical hardware.

wine, Virtual Box, Fusion, and Parallels all require that the code hosted in execution environment match the instruction set of the physical host.

Wine provides an execution environment that matches the MS Windows runtime. Virtual Box, Fusion and Parallels all use hardware virtualization support built into the CPU to allow controlled execution of hosted code at or close to the speed of the physical hardware.
 
Wine Bottler

It looks like Wine Bottler, http://winebottler.kronenberg.org/, will create an installer package. This page also has links to discussion and support pages. These might be a good place to look for info about signing an OS X installer package.

----------
Cromulent said:
...If you knew anything about WINE you would know it is a recursive acronym for Wine Is Not an Emulator....
Click to expand...

So how can an acronym recursive? Isn't recursion when a function calls itself?

The Wikipedia article about Wine says: "Wine also provides a software library, known as Winelib, against which developers can compile Windows applications to help port them to Unix-like systems". Maybe Winelib has some functionality for code signing.
 
Last edited:
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back