Sunday, October 23, 2011

Building and Submitting iOS Apps built using user created static libraries


Here are my notes on getting an iOS app submittable to Apple’s app store, which includes an interesting “welcome back to header files” experience. Resolving all the issues required a fair amount of searching and futzing, so I thought I’d put together a synopsis and share:

Step 1: Compiling a project referencing a static library I created.

Background: I’m building a suite of apps centered on pdf file display, using the vfr pdf reader framework -- the developer, Julius Oklamcak, characterizes it a basic framework, but I found it both robust and easily configurable to fit my needs.

The first task was to build a library consisting of the vfr pdf reader code so that the code would be factored appropriately. Using this approach, any bugs showing up in the pdf reader require only one code change to fix all the books.

I used CarbonFive’s blog post on building and using static libraries to perform the setup.

It took a bit of tweaking to get the library incorporated/recognized by the dependent projects, and, sadly, one of those tweaks came back to bite me later.

The primary change was to put all the projects in a single Xcode workspace so that the library was readily available to the dependent project (apps). Workspace creation, followed putting the library in the frameworks folder, and making the .h files public, made the .h files visible to the dependent project.

After these changes, the dependent project could

compile and run, both on the simulator and on my test device.


Step 2: Archiving the Project

However, when I went to archive the app (a precursor to submission), the necessary .h files suddenly could not be found.

There didn’t seem to be any “build level” way around this -- meaning that I couldn’t find a way to eliminate this error that just entailed changing some configuration files. The only solution I could find was to move copies of (or links to) the actual header files being referenced.

Upon further consideration this appears to be an artifact of the build environment/ObjectiveC language, since even the foundation frameworks are packed with their header files (see below)



Step 3: Validating the Project

At this point the archive could be created without errors, but when I tired to validate and submit I got the following

"[projectname] does not contain a single–bundle application or contains multiple products. Please select another archive, or adjust your scheme to create a single–bundle application."

This was a quick issue to fix -- the answers appearing on stack overflow

Archiving project in XCode incorrectly creates multi-application bundle

The fix required changing the file visibility (back) from public to project. Changing file visibility is most easily accomplished by moving the .h files to the appropriate part of the Copy Headers section of the Build Phases tab for the target -- I will admit that this approach was advocated it the CarbonFive blog, but it didn’t appeal to my (Java tuned) sensibilities.

H file movement

Step 4: Submitting the Project

The fun wasn’t quite over, since an attempt to submit the app resulted in the response

No suitable application records were found.

After setting up the signing appropriately per Apple’s guidelines

-- somewhat obscurely located here

Apple directons

(BTW am I the only  one finding it frustrating that Apple’s documentation hasn’t been fullly refreshed to reflect the Xcode4 UI?)

and reading stack overflow again,

illed out the questionnaire and I was able to submit and upload successfully.

Hope this short walkthrough proves useful.