Software Development
iPhone SDK Code Signing Insights
Sadly, the code signing continues to be the most frustrating and often time-consuming element of iPhone Development. The 2.1 SDK changed a few things, and force me to clarify a few other. Here’s what I’ve learned this time around.
Code Signing Identify
The way XCode matches your Code Signing Identify is by assuming a wildcard at the end of whatever you type, and matching against Common Name of your certificates. That means you can just leave it as “iPhone Developer:” if you only have a single development certificate. Of course if you have multiple certificates with the same name (or prefix) its ambiguous.
For example I have several companies, and several development certificates, but you can’t really use more than one on the same box unless you make up new names for yourself each time. So, the best solution seems to be just to have one development certificate per box – since it doesn’t really matter which certificate you use for development, just distribution.
Entitlements
The latest instructions say that you must add an Entitlements resource to the project, unchecking the get-task-allow box. You then specify the name of the Entitlements plist file (I use Entitlements.plist) in the build target.
Ok, so I don’t understand what the entitlements do, but I have figured out what is required. Entitlements didn’t seem to be required for 2.0, but starting with 2.1 it appears that they are required for Distribution profiles, but will cause problems if you set them up on development targets. If you specify an Entitlements plist in a development profile it won’t install on the phone. This seems to be new to 2.1
Target Identifier
Also new to 2.1, you need to set your build target’s “Identifier” property (via the Info screen of a target) to match that of your application ID. Assuming you use wildcards, you leave off the randomly generated prefix, and set it to something like: com.example.${PRODUCT_NAME:identifier}. This is a “must have” to create a distribution build that actually works.
| Permalink | Comments[1] |
Making iPhone Distribution Profiles Show Up
I’ve been having lots of trouble getting new or updated iPhone profiles to show up in XCode, and I think I may have finally stumbled on the answer. It appears that XCode does not re-scan the provisioning profiles from your library if you have the simulator as your default target.
After installing and reinstalling, starting and stopping XCode, iTunes, rebooting, etc for hours. I was testing the theory that maybe it doesn’t show the list of profiles if there’s only one by building for the device, and then examining the package. I did this and it did have a profile.
Then when I went back into XCode, my profiles list appeared! I’ll keep testing this theory but I think it’s the key. It feels like it fits with the pattern I’d seen before as things mysteriously appeared.
| Permalink | Comments[3] |
Objective-C static libraries and categories
If you are building iPhone or other Mac apps with the iPhone using static libraries, reading
Technical Q&A QA1490 will help you. I was getting a problem running with FMDB because it uses categories to extend the functionality of one of its classes and failing at runtime with a selector problem.
To resolve this issue, the static library should pass the -ObjC option to the linker. This flag causes the linker to load every object file in the library that defines an Objective-C class or category. While this option will typically result in a larger executable (due to additional object code loaded into the application), it will allow the successful creation of effective Objective-C static libraries that contain categories on existing classes.
In my case I had to put these flags on the primary application target (the one using the library) rather than the library itself, which strikes me as odd.
Update: You also have to add -all_load in some cases
| Permalink | Comments[6] |
Ethereal Network Protocol Analyzer 0.99 Released
Version 0.99.0 of the Ethereal Network Protocol Analyzer has been released. Ethereal has all of the standard features you would expect in a protocol analyzer, and several features not seen in any other product. It runs on all popular computing platforms, including Unix, Linux, and Windows. (No Mac port as of yet unfortunately)
Read More... 
|
Permalink | Comments[0] |
Significant update to FireBug for Firefox
Joe Hewitt has released a significant update to the popular FireBug extension for Firefox.
FireBug lets you explore the far corners of the DOM by keyboard or mouse. All of the tools you need to poke, prod, and monitor your JavaScript, CSS, HTML and Ajax are brought together into one seamless experience, including an error console, command line, and a variety of inspection tools.
One of the really cool new features is the inline editing. Navigate through the content/DOM inspector and modify HTML and attributes and see them updated in real time on the web page.
If you are a web developer of any sort, you need this tool!
|
Read More...
|
Permalink | Comments[0] |
