PureBasic Forums - English

I will take a closer look.

Fred wrote:I will take a closer look.

Thanks Fred!

Hi

I'm having a bit of a problem, I'm getting stuck on the following step: codesign -f -s "3rd Party Mac Developer Application: Marten Jonsson" --entitlements "/Users/User/Desktop/But to Paint a Universe.entitlements" "/Users/User/Desktop/But to Paint a Universe.app"

I'm getting the following error: /Users/User/Desktop/But to Paint a Universe.app: replacing invalid existing signature
/Users/User/Desktop/But to Paint a Universe.app: a required plist file or resource is malformed

Here's my entitlement file, as I've filled it in:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd>">
<plist version="1.0">
<dict>
<key>LSApplicationCategoryType</key>
<string>public.app-category.puzzle-games</string>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>But to Paint a Universe/string>
<key>CFBundleGetInfoString</key>
<string>But to Paint a Universe 1.0, Copyright © 2012 JMJ All rights reserved.</string>
<key>CFBundleIconFile</key>
<string>App.icns</string>
<key>CFBundleIdentifier</key>
<string>com.jm-j.btpau</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>But to Paint a Universe/string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>LSBackgroundOnly</key>
<string>1</string>
<key>CFBundleSignature</key>
<string>PURE</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>LSMinimumSystemVersion</key>
<string>10.6</string>
</dict>
</plist>

What am I missing?

J. Baker wrote:

kenmo wrote:Thanks for this guide!

I may try this out in the future, but first I need to finish some software that could make $100+ in order to justify the $99 fee!

Do you know what % of your sales revenue Apple takes?

No problem!

My app sales for $1.99 USD and I get $1.40 USD off each sale.

Why the Mac apps are su cheap? Its a god business? Did a regular coder get enought sales from make good money?

If i sale Windows app at $40 each one, wityh 3 sales per day im making +3k
Does app developers sell hundreds of apps each day?

Yes, they do.

Xeeko wrote:Yes, they do.

I am not talking about big companies, but small sellers, like everyone here.

Hey J.Baker,

thanks for that new Guide including Sandboxing and Gatekeeper. Just submitted an update for one of my smaller Apps... /crossing fingers now/

I put together a new bash-script to make the process semi-automatic. Save the file below to app-ent.sh, and change YOURNAME accordingly.
Open Terminal.app, drag the app-ent.sh to the Terminal, then your App.app. Remove the last .app, press enter. That's it.
Does anybody know how to get the first part without the extension from e.g. "/my/path/to/app.app"?
The script needs $1 to be /my/path/to/app, not /my/path/to/app.app

jamirokwai wrote:Hey J.Baker,

thanks for that new Guide including Sandboxing and Gatekeeper. Just submitted an update for one of my smaller Apps... /crossing fingers now/

No problem. Hope it goes through.

J. Baker wrote:

jamirokwai wrote:Hey J.Baker,

thanks for that new Guide including Sandboxing and Gatekeeper. Just submitted an update for one of my smaller Apps... /crossing fingers now/

No problem. Hope it goes through.

Hey again,

my App got rejected. Not because of missing Sandbox or such. It's because I added the wish for server-rights, but didn't add server-functionality... D'oh :-O

Will submit again, and get back to here.

If your app is sandboxed, GetHomeDirectory() doesn't return your usual directory. It returns "/Users/jbaker/Library/Containers/com.posemotion.spritemonkey/Data/", the sandboxed containers folder for the app.

But when your sandboxed app first launches, it automatically creates...
"/Users/jbaker/Library/Containers/com.posemotion.spritemonkey/Data/Library/Application Support/"

So you just need to create AppName (Sprite Monkey in my case) directory to store your preference files and so forth.
"/Users/jbaker/Library/Containers/com.posemotion.spritemonkey/Data/Library/Application Support/Sprite Monkey/"

Have you found a way to validate the store receipt in your application? I looked at your tutorial but did not find the code to validate the receipt so it stops
users from copying your application to other machines.

spacebuddy wrote:Have you found a way to validate the store receipt in your application? I looked at your tutorial but did not find the code to validate the receipt so it stops
users from copying your application to other machines.

Is that possible? I think Apple does this in iOS, could be wrong. Would love to see it in OS X, as there is no way to protect a developer that I know of. It seems anyone can purchase an app then get a refund but still use the app. If you've read something that I'm not aware of, post the link.

I just resolved an old issue I was having. Creating 64-bit apps, or more so, packages for Snow Leopard.

The problem was that 64-bit packages don't install on Snow Leopard. This is due to the kernel being 32-bit by default in Snow Leopard for better compatibility for drivers and so forth. This can be seen in System Profiler under Software. The "64-bit Kernel and Extensions" equals no, unless you have changed it yourself through a Terminal option.

Yes, I know. This doesn't make sense if your able to run 64-bit apps without issue. The problem is the 64-bit app itself. It automatically sets the package build to a 64-bit requirement when building your package for distribution. This only happens when double clicking on a package for installation. It appears to check for the kernels setting instead of what the processor is capable of.

Now this doesn't effect Mac App Store builds. As the App Store uses a command line to install your app to the users Mac. Apple must have noticed this and fixed this, so there wouldn't be an issue with the App Store. It also doesn't effect Universal 32/64-bit builds as the build process detects the 32-bit and therefor creates an i386 package.

So here's how to resolve the issue. Create a "def.plist" with the following...

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>arch</key>
<array>
<string>i386</string>
</array>
</dict>
</plist>

Now you have to add "--product def.plist" to the "productbuild" line, like this...

productbuild --product "/Users/Your Name/Desktop/def.plist" --component "/Users/Your Name/Desktop/Your App.app" /Applications --sign "Developer ID Installer: Your Name" yourapp.pkg

Now you can distribute 64-bit packages outside of the Mac App Store for Snow Leopard and up!

Just be sure to use the Developer ID Application: Your Name and Developer ID Installer: Your Name key certificates instead of 3rd Party Mac Developer Application: Your Name and 3rd Party Mac Developer Installer: Your Name for outside the Mac App Store.